September 2026 Summaries

Interactive Application Security Testing (IAST) identifies vulnerabilities in running applications by deploying runtime agents that track data flows from user inputs through code, databases, and outputs, allowing it to detect issues such as SQL injection, cross-site scripting, and insecure deserialization with detailed code-level context. Usually run during QA, functional testing, or staging, IAST complements Static Application Security Testing (SAST), which analyzes code without execution; Software Composition Analysis (SCA), which detects vulnerable dependencies; and Dynamic Application Security Testing (DAST), which probes applications externally. Its real-time visibility can reduce false positives, improve remediation speed, and integrate security checks into existing automated test cycles, but it requires agent installation, supported languages and frameworks, sufficient test coverage, and operational effort to maintain across distributed microservices environments. IAST is therefore most effective as part of a layered application security program, alongside SAST and SCA early in development and DAST for external-facing testing.

Engineers often deprioritize cloud and AI cost optimization because billing information is fragmented, lacks technical context, and arrives too late to influence decisions made during active development, while static budgets and periodic cleanup efforts address waste only temporarily. The post argues that organizations should adopt a FinOps culture by shifting cost feedback into CI/CD pipelines and pull requests, allowing developers to see projected spending changes before infrastructure or model configurations are deployed. It recommends automated, policy-based guardrails for actions such as shutting down non-production environments, identifying anomalous spending, and removing idle or overprovisioned resources, while distinguishing necessary growth-related spending from waste. Harness presents its Cost Management Agent as a tool that integrates cost attribution, anomaly detection, governance, and configurable automated remediation across cloud, AI, and engineering tools, aiming to make financial accountability a continuous part of software delivery rather than a retrospective finance task.

SAST, SCA, DAST, and IAST are complementary application security testing methods that address different risks across the software development lifecycle. SAST analyzes proprietary code before execution to identify risky patterns early but may generate false positives, while SCA examines third-party dependencies and known vulnerabilities but may not determine whether vulnerable components are actually used. DAST probes a running application externally with attacker-like requests, making it useful for identifying exploitable behavior and testing systems without source access, though it often cannot locate the underlying code issue. IAST instruments a running application to track data through code during testing, providing precise findings with fewer false positives but requiring operational effort to deploy and maintain agents. SAST and SCA are generally suited to commits, pull requests, and early CI stages, whereas DAST and IAST are used in QA, staging, or pre-production environments. An effective security program combines the methods according to organizational needs, centralizes results, removes duplicate findings, and prioritizes issues based on real exploitability and available team capacity.

Oracle database DevOps applies version control, automated validation, CI/CD pipelines, and policy enforcement to schema changes that have traditionally relied on manual scripts, DBA approvals, and maintenance windows. Oracle requires engine-specific safeguards because DDL often takes exclusive locks, may block workloads during certain operations, is generally non-transactional with implicit commits, and must account for complex environments such as RAC clusters and Data Guard standbys. The recommended approach emphasizes Git-managed, peer-reviewed migration changelogs, risk-based policies, environment drift detection, realistic pre-flight testing, and tested forward rollback scripts rather than automatic database rollback. For Oracle estates with substantial PL/SQL dependencies, script-based migrations are presented as safer than automatically generated state-based schema diffs because they retain human control over dependent objects. Harness Database DevOps supports Oracle through JDBC connections and Liquibase-compatible changelogs, offering automatic schema baselining, OPA-based policy checks, selective approval workflows, audit records, and network-contained deployment through a Harness Delegate.

Organizations evaluating alternatives to JFrog Artifactory are commonly motivated by costs, operational complexity, or security requirements, particularly because Artifactory pricing can combine storage and transfer consumption and vulnerability scanning requires the separately licensed JFrog Xray product. Selection should focus on the package formats a team actually uses, whether security scanning is integrated, pricing transparency for transfer and egress, operational responsibilities, CI/CD and access-control integration, and available migration support. A migration should begin with an inventory of active repositories and dependent pipelines, determine which artifacts to retain, document integrations and credentials, and validate the replacement using the most demanding pipeline before a broader cutover. Integrated platforms may reduce disconnected tooling, simplify RBAC and audit visibility, and tie scanning directly to artifacts, although consolidation may not suit teams with stable, diverse existing workflows. The recommended choice is therefore based on alignment with a team’s current delivery practices, security needs, and cost model rather than on the largest feature set.

A Harness benchmark compared GPT-5.5 and Claude Opus 4.8 LLM-based vulnerability scanners with Harness AI SAST across OWASP WebGoat, Juice Shop, and Benchmark for Java, evaluating precision, recall, consistency, speed, and cost using a shared Codex Security prompt workflow. The LLM scanners generally reported high precision, ranging from 85% to 100% on the benchmark applications, but recall was often low and highly variable, with both models missing many known vulnerabilities in WebGoat and Juice Shop; GPT-5.5 achieved 100% recall on Benchmark for Java while Opus 4.8 found very few issues there. The authors caution that the public, intentionally vulnerable applications may favor models trained on their source code, documentation, or embedded answer keys, while their ground-truth construction and LLM-assisted finding matching also shape the results. Repeated Opus scans of unchanged code produced materially different findings and recall rates, underscoring the probabilistic nature of LLM tools, whereas the deterministic AI SAST engine offered tunable precision-recall tradeoffs with faster and more predictable operation. LLM scans took roughly 1.6 to 37 times longer and cost 6 to 39 times more than AI SAST in the tests, though incremental GPT-5.5 scans reduced cost and time substantially for smaller code changes while potentially losing coverage on unusually large changes. Based on these findings, the authors recommend LLM-only scanning primarily for periodic deep assessments or penetration testing, while using deterministic scanners augmented by AI reasoning for continuous pull-request and pipeline security checks.

Harness has introduced a connector for OpenAI that integrates CI/CD delivery context from Harness directly into ChatGPT and Codex CLI, allowing users to investigate pipeline executions, review failures, inspect configurations, and perform supported pipeline actions without switching tools. Through OAuth authentication, the connector operates using each signed-in user’s existing Harness permissions, with no additional access granted by the AI integration and separate approval requirements for requested changes. Users can query recent executions, diagnose failed steps, request proposed pipeline updates, and, where enabled, create, update, delete, or execute resources, subject to licensing, permissions, exposed tools, and client settings. The integration is available through ChatGPT on desktop, web, and mobile as well as through Harness Hosted MCP in Codex CLI, with separate authentication flows for the two environments. Setup requires a Harness SaaS account with OAuth enabled and an OpenAI workspace that permits the integration, while organizations using SAML or OIDC may need additional administrator configuration.

AI-driven development has accelerated code creation, making the central challenge ensuring that the exact artifacts deployed to production remain trustworthy as threats evolve. Drawing on compromises involving TanStack dependencies, SolarWinds build systems, and LiteLLM pipelines, the discussion argues that attackers increasingly target dependencies, build processes, and deployment artifacts rather than source code alone. It advocates attaching security evidence such as SBOMs, provenance, attestations, vulnerability results, and policy evaluations directly to artifacts, enabling registries to continuously reassess and control their promotion through environments. Effective security requires not only detecting newly disclosed risks but also enforcing responses through quarantine, access controls, deployment gates, and automated remediation. Harness presents AI agents for pipeline management, application security, registry threat monitoring, and artifact lifecycle management as examples of how continuous verification could operate, emphasizing that safe software delivery depends on treating CI/CD pipelines and artifact registries as active security boundaries.

AI security solutions protect LLMs, AI applications, agents, models, and associated data from threats such as prompt injection, agent hijacking, model poisoning, sensitive-data disclosure, insecure outputs, and unauthorized tool or API use. Growing AI adoption, limited organizational visibility into LLM usage, and concerns about shadow AI have made these platforms increasingly important, with buyers advised to look beyond vendor marketing claims and verify coverage of OWASP LLM Top 10 risks. Key selection criteria include flexible SaaS, self-hosted, or hybrid deployment; comprehensive traffic and asset visibility; straightforward integration with security, identity, cloud, and software delivery tools; demonstrable detection and prevention performance; DevSecOps support for testing AI systems before deployment; and governance capabilities such as policy enforcement, audit trails, and compliance reporting. Organizations should also assess supported models and frameworks, event investigation workflows, threat-research investment, product roadmaps, data-use practices, licensing, scalability, support, and contract flexibility. Cross-functional involvement from application development, procurement, compliance, risk, and legal teams can help ensure that the chosen platform fits both current technical needs and long-term AI strategy.

Harness’s {unscripted} events in Chicago and Columbus examined how AI-generated code is increasing development output far faster than organizations can safely deploy it, with reported code growth of roughly 180% producing only about 30% more shipped software. Speakers argued that the delivery bottleneck has shifted to reviews, pipelines, governance, security, and change approvals, making automated, risk-based controls more important than simply accelerating code creation. They described a model of graduated agent autonomy, in which agents operate within role-based access, policies, audit trails, and risk thresholds while humans focus on higher-risk decisions. Panels emphasized that security, governance, and compliance teams should provide clear, usable paths to approval rather than act as blockers, treating compliance as an embedded delivery capability that enables speed and safety. Discussions also highlighted security challenges such as rapid vulnerability exploitation, AI agents weakening traditional fraud signals, and stolen API-token markets, alongside the value of reachability analysis for prioritizing fixes. Participants noted the human impact of machine-speed development, including larger pull requests, overburdened senior reviewers, declining confidence in changes, and the need to redesign release processes and team adoption practices rather than merely attach AI to existing workflows.

CI/CD pipelines are high-value security targets because they centralize credentials, signing keys, artifact access, and deployment permissions across multiple environments, meaning a compromise can affect everything they deploy. The checklist emphasizes managed runtime-injected secrets, least-privilege RBAC, isolated runners, pinned and scanned dependencies, SBOM generation, signed and verified artifacts, and centralized audit evidence, while warning that hardcoded credentials, broad IAM roles, mutable third-party action tags, and unreviewed pipeline definitions are common weaknesses. It recommends implementing controls progressively through report-only visibility, warning-mode policy, and narrowly targeted enforcement to avoid unnecessarily disrupting development teams. The article also argues that increased use of AI coding tools and third-party dependencies expands pipeline risk, citing incidents involving compromised action versions as examples of supply-chain exposure. Harness presents its governed pipeline approach, security-testing orchestration, policy-as-code, provenance features, and centralized auditing as tools for applying these practices consistently, with customer examples from Deluxe and Citi illustrating standardized security controls at scale.

Cloud cost optimization requires combining technical waste reduction with ongoing visibility, accountability, and governance to preserve workload performance and reliability. Recommended practices include allocating costs by team and workload, safely rightsizing compute and Kubernetes resources, autoscaling services, shutting down idle nonproduction environments, detecting anomalies, purchasing commitments only after usage stabilizes, using spot capacity for interruption-tolerant jobs, optimizing storage and data transfer, applying budgets and showback or chargeback models, and tracking unit economics and realized savings. For Kubernetes, teams should establish cost and service-level baselines, make conservative changes one workload at a time, and monitor latency, errors, memory failures, and scheduling to enable rapid rollback. The guidance also recommends investigating bill increases by isolating affected providers, services, workloads, recent changes, and ownership, while customer examples cite savings from automated shutdowns and improved cost visibility. It further argues that these FinOps practices should extend to AI spending, where fragmented billing and unclear ownership contribute to reported waste.

AI-assisted attacks are rapidly increasing cybersecurity risks by giving adversaries more powerful and accessible capabilities, disrupting the historically incremental cycle in which attackers and defenders gradually improved their techniques. While some organizations are beginning to use similar technologies to strengthen defenses, many must focus first on core practices such as identity management, vulnerability remediation, and advanced threat detection. The post recommends using AI to accelerate activities like vulnerability triage and prioritization, including through capabilities already available in existing security tools. It also argues that responding effectively requires collaboration across engineering, infrastructure, and security teams rather than treating AI-driven threats as a security-only issue, enabling faster and more visible adaptation to increasingly capable attackers.

Harness Security Test Orchestration (STO) aims to make LLM-based security scanning reliable enough for continuous CI/CD use by constraining models’ otherwise variable reasoning through controlled triggering, scope, phased analysis, and standardized reporting. Built around OpenAI Codex Security with a Mythos agent plugin, it supports both full scans for audits or initial repository reviews and incremental scans for pull requests and protected-branch merges, with optional build blocking based on severity. Incremental scans retain and revalidate prior findings while limiting new vulnerability discovery to changed files, reducing costs by 58–83% and scan times by 67–72% in tests on intentionally vulnerable applications while retaining all findings identified by full scans. The workflow separates threat modeling, candidate discovery, evidence-based validation, and attack-path analysis to reduce false positives and ensure findings are relevant and reachable. Consistent report structures, validation records, format checks, and stable finding identities allow teams to compare results across scans, track fixes and newly introduced issues, and maintain a more dependable security backlog despite the nondeterministic nature of LLMs.

Vulnerability remediation permanently removes a security flaw through actions such as patching, upgrading software, correcting code, or changing configurations, while mitigation temporarily reduces exposure through controls such as network isolation, access restrictions, feature disabling, edge rules, and added monitoring. Mitigation is appropriate when no patch exists, a fix cannot be deployed without unacceptable downtime, or an exploit path is already blocked, but it should be documented as a time-limited exception with a responsible owner and expiry date to avoid becoming an unmanaged permanent risk. Effective vulnerability management extends beyond patching by discovering, prioritizing, acting on, verifying, and reporting findings according to severity, exploit likelihood, asset exposure, and business importance, using signals such as CVSS, EPSS, and CISA’s Known Exploited Vulnerabilities catalog. The article argues that consolidated security workflows, policy-based controls, and automated delivery pipelines can reduce exposure windows by centralizing findings, tracking exemptions, and enabling faster fixes or rollback mechanisms, citing Harness customer examples involving Log4Shell response times and feature-flag-based recovery.

AWS cost optimization involves reducing unnecessary cloud spending while maintaining workload performance, availability, and reliability through a combination of resource management, pricing strategies, storage and network optimization, and continuous cost visibility. The 15 recommended tactics include rightsizing EC2 instances before purchasing Savings Plans or Reserved Instances, using Spot Instances for interruption-tolerant work, scheduling non-production environments, matching S3 storage classes and lifecycle policies to access needs, removing unused EBS volumes, migrating eligible gp2 volumes to gp3, and reducing NAT Gateway and cross-Availability Zone transfer charges. AWS tools such as Compute Optimizer, Cost Explorer, Cost and Usage Report 2.0 data exports, cost-allocation tags, budgets, and Cost Anomaly Detection support investigation, accountability, and early detection of unexpected spending. Savings Plans offer greater flexibility for predictable compute demand that may change over time, while Reserved Instances can suit stable workloads with specific configurations. The piece emphasizes that savings vary by workload and that continuous governance is needed, presenting Harness Cost Management Agent as a complementary platform for cross-environment visibility, automated remediation, and policy-based cost controls, with customer examples reporting significant annualized savings.

Harness announced an integration with Amazon Bedrock AgentCore Gateway that extends its AI posture management and runtime firewall capabilities to AWS agent interactions. The integration continuously discovers AI assets such as agents, tools, MCP servers, prompts, APIs, and resources, while monitoring multi-step agent-to-tool activity for threats including prompt injection and sensitive-data leakage. Harness argues that traditional controls such as authentication, authorization, and API validation remain necessary but may not detect harmful sequences in which authorized agents are manipulated into taking unsafe actions. By analyzing complete agent journeys, including the initiating client, selected tools, accessed resources, and data flows, the platform aims to give security teams trace-level context for investigation and response. The offering builds on Harness’s existing API security and behavioral analysis capabilities, reflecting the view that agent interactions are dynamic extensions of API journeys and require sequence-aware protection as enterprises deploy increasingly autonomous AI systems.

Cloud cost optimization often fails because engineers receive delayed, aggregated billing data that lacks connection to the code changes, deployments, Kubernetes workloads, or infrastructure configurations that caused spending changes. The post argues that centralized governance and periodic finance-led audits create friction, while over-provisioned container resource requests, idle resources, and inefficient infrastructure-as-code changes can quietly increase costs without clear workload-level attribution. It recommends shifting cost feedback left into pull requests and CI/CD pipelines, where developers can see estimated cost impacts before changes reach production, alongside automated policy-based guardrails that flag or block inefficient configurations without relying on manual approvals. Harness presents its Cost Management Agent as a platform for attributing spend to teams and workloads, detecting anomalies, offering or automating optimization actions, enforcing Open Policy Agent policies, and allowing users to query cloud spending in plain language across AWS, Azure, and GCP.

Harness describes TypeSafe’s Jev as a decision-focused AI model that returns typed Choices, Scores, or yes/no probabilities rather than prose or JSON that software must interpret, making agent judgments visible, storable, thresholdable, and auditable. Trained for calibrated decisions, Jev is intended to expose key forks in agent loops, such as selecting tools, deciding whether evidence is sufficient, routing work to a cheaper or stronger model, and assessing action risk, while policy code enforces how those decisions are used. Harness tested the approach in evaluation metrics, model routing, and safeguards for destructive actions, finding substantially lower latency than an LLM judge but mixed accuracy results, and showing that routing decisions can improve outcomes yet still raise total costs when longer agent loops offset cheaper model choices. The article emphasizes measuring decision quality separately from task outcomes, cost, and latency, and recommends retaining hard controls such as RBAC, policy enforcement, approval gates, and freeze windows while using probabilistic judgments to adjust autonomy and friction within those limits.

AI DevSecOps applies machine learning throughout the secure software development lifecycle to automate tasks such as security scanning, finding deduplication, risk-based triage, code review, remediation, and release decisions, while also addressing risks created by AI-enabled development. The approach expands traditional DevSecOps asset coverage beyond code and dependencies to include AI models, prompts, and training or retrieval data, which can introduce threats such as model supply-chain tampering, data poisoning, and prompt injection. The article argues that AI can reduce the backlog of duplicate or low-priority findings, but human review, governance, provenance, policy enforcement, and auditability remain necessary because AI-generated code and automated decisions can create new vulnerabilities or errors. It describes maturity as progressing from ad hoc AI use to governed and verified autonomous workflows, with models and related assets inventoried, versioned, monitored, and subject to policy as code. Harness positions its platform as supporting this model through scanner orchestration, AI-assisted triage and remediation, secure AI coding integrations, SBOM and AI-BOM generation, provenance verification, and pipeline-based security controls.

Managing infrastructure as code across multiple cloud providers and accounts can lead to fragmented state files, inconsistent modules, duplicated configurations, unclear ownership, configuration drift, and uneven policy enforcement as organizations grow beyond a single cloud environment. The post argues that traditional Terraform-centered workflows often lack centralized operational visibility when teams independently manage repositories, workspaces, credentials, and deployment processes. It presents Harness Infrastructure as Code Management as a platform intended to centralize workspace visibility, automate drift detection, enforce policies before deployments, standardize pipelines, and support OpenTofu, Terraform, and Terragrunt without requiring teams to replace existing code. Features such as centralized module and provider registries, shared variable sets, workspace templates, audit trails, and Open Policy Agent integration are described as ways to maintain team autonomy while applying organization-wide governance across AWS, Google Cloud, and Azure environments.

Kubernetes cost optimization focuses on aligning reserved CPU and memory resources with actual workload usage, since inflated pod requests are billed even when capacity is unused and can be multiplied across many replicas. The main approaches are right-sizing requests and limits using observed demand, applying horizontal, vertical, and cluster-level autoscaling, using spot or preemptible instances for fault-tolerant workloads, and allocating shared-cluster costs by namespace through consistent labels. Common sources of waste include overprovisioned requests, idle non-production environments, orphaned storage volumes, unused node capacity, and abandoned workloads, while useful measures include cost per namespace and workload, idle and unallocated spending, and cost per unit of work. The discussion notes that Kubernetes scheduling and cloud billing each lack complete cost context, making attribution and actionable visibility important, and presents Harness Cost Management as a platform that combines cost data, optimization recommendations, idle-environment suspension, node packing, spot placement, and anomaly detection near deployment workflows. It also cites examples of ConsumerTrack reducing Kubernetes service onboarding effort through automation and Tyler Technologies achieving annualized savings by suspending inactive non-production infrastructure on demand.

Organizations increasingly have AI spending policies, but many still face unexpected bills because governance rules are not matched by real-time cost visibility and enforcement. The article cites a 2026 FinOps report finding that while 73% of organizations have AI cost policies, only 47% fully enforce them and just 13% have basic visibility into AI costs. Rapidly growing AI investment, projected to reach $2.67 trillion globally in 2026 and $5.95 trillion by 2030, has turned AI spending into a capital-level concern, yet responsibility is often fragmented among engineering, finance, IT, and FinOps teams. Surprise expenses can result from oversized models, inefficient retry loops, and usage-focused cultures that encourage “tokenmaxxing” without measuring business value, while identifying the cause of cost spikes often takes days or weeks. The piece argues that policies remain necessary but cannot independently monitor spending, verify compliance, or prevent overspending, making operational visibility and clear accountability essential next steps.

Internal developer portals can improve security, compliance, and engineering productivity by embedding governance controls into self-service development workflows rather than relying on fragmented scripts, broad permissions, and manual review processes. As organizations scale, scattered infrastructure templates and pipelines can create workflow sprawl, infrastructure drift, unclear service ownership, and vulnerabilities such as outdated modules, hardcoded credentials, or excessive cloud access. Recommended practices include maintaining a centralized software catalog, enforcing granular role-based and temporary access controls, providing pre-approved “golden paths” with built-in security scans and compliant templates, and creating immutable audit logs for every portal action to support standards such as SOC 2 and ISO 27001. Harness positions its Internal Developer Portal as a platform for combining service catalogs, self-service templates, policy guardrails using Open Policy Agent, CI/CD scaffolding, dependency visibility, and integrations, aiming to help teams enforce security standards without slowing software delivery.

A LeadDev panel involving leaders from Yelp, Platformable, and Harness argued that the increasing autonomy of AI agents requires governance to shift from static policies and post-incident reviews to continuously automated controls embedded in engineering platforms. Participants emphasized that governance designed for human contributors is insufficient for agents, which need dedicated audit trails, inter-agent access controls, role-based data permissions, experiment tracking, model evaluation test sets, monitoring, and rollback mechanisms. Internal developer platforms were identified as the practical enforcement layer for authentication, authorization, impersonation rules, Policy as Code, and observability throughout deployment pipelines. The discussion also highlighted that effective AI governance requires involvement from security, legal, and finance, while its measurements should connect to business outcomes such as churn and budget priorities.

Harness argues that organizations should manage AI prompts, model selections, and settings as governed runtime “AI Configs” rather than hard-coded application changes requiring full redeployments. Citing growing enterprise adoption of agentic AI, the webinar-based post describes how configurable AI behavior can support progressive rollouts, live experiments, and immediate kill switches, enabling teams to test prompt or model changes on limited traffic before broader release. It emphasizes governance mechanisms such as policy checks, role-based access controls, lower-environment validation requirements, and audit logs to prevent untested or unauthorized production changes. The post also stresses connecting configuration exposure to real-world outcome measures, such as customer satisfaction and support resolution rates, so cost or performance improvements can be evaluated against potential quality declines.

A Harness blog post based on an InfoQ panel with contributors from Harness, DKB, and Shine examines how platform engineering is adapting as AI becomes both a development aid and an active consumer of platform services. It highlights a reported finding that 94% of engineering leaders lack the AI metrics they consider most important, particularly measures connecting AI-generated code, agent activity, token spending, productivity, infrastructure costs, and business outcomes. Panelists describe a growing need for platform teams to determine which AI tools and controls should be standardized centrally versus selected by individual teams, while also redesigning internal developer platforms and APIs for AI agents that may autonomously request infrastructure or deploy software. Although AI has accelerated coding, slower stages of the software development lifecycle, including governance, testing, and deployment, can become bottlenecks or introduce production risks when bypassed. The post argues that platform engineering is not being replaced but is taking on expanded responsibilities for governing AI tooling, enabling secure agent self-service, and demonstrating the value of AI investments.

Argo CD is presented as an effective Kubernetes GitOps tool for synchronizing declarative manifests from Git to clusters, but the post argues that it does not by itself address enterprise software delivery needs such as multi-stage release orchestration, approval workflows, centralized governance, policy enforcement, auditing, secrets management, and automated deployment verification. As organizations operate many clusters and Argo instances, the authors describe “Argo Sprawl” as increasing operational toil and security complexity, often leading teams to create custom integrations and scripts around the platform. They propose an enterprise control plane that retains Argo for manifest synchronization while adding centralized RBAC, policy-as-code, workflow integrations, audit trails, dynamic release inputs, and AI-driven analysis of observability data to detect anomalies and trigger rollbacks. The post positions Harness as such a control plane, arguing that it can help teams scale GitOps without replacing Argo CD.

Harness describes a three-stage CI/CD pipeline that uses Terraform within Harness Pipelines to create a uniquely named Harness Artifact Registry virtual Docker registry and a Docker Hub upstream proxy, link the two, build and push a container image, and deploy it to Kubernetes. The workflow uses randomly generated suffixes and Harness output variables and expressions to avoid naming conflicts and pass registry identifiers between stages without hardcoding values. It requires a Harness account with Artifact Registry, CI, and CD enabled, a securely stored API key with registry and secret permissions, a source repository containing a Dockerfile, and a connected Kubernetes environment. The guide details inline Terraform configuration, ephemeral local Terraform state and the need to import an existing registry before updating it, native Harness image-building steps, Kubernetes rolling deployment with rollback, verification and cleanup options, troubleshooting for provider, permissions, registry-resolution, and image-pull issues, and possible extensions including remote state, approval gates, triggers, notifications, and support for other package types.

Kubernetes cost management tools translate cloud provider billing, which is typically charged per node, into costs attributable to Kubernetes clusters, namespaces, workloads, pods, labels, teams, or customers, helping organizations identify idle and unallocated capacity and support rightsizing, shutdowns, and spot-instance use. The comparison groups offerings into open-source collectors such as OpenCost, dedicated products including Kubecost and CloudZero, native cloud billing tools, observability products such as Datadog, and delivery platforms such as Harness, with key evaluation factors including allocation granularity, multi-cluster and multi-cloud support, showback or chargeback reporting, and pricing structure. It notes that provider-native tools accurately report billed resources but may have limited visibility into how shared Kubernetes infrastructure is consumed, while open-source options provide foundational allocation data but often require users to build reporting and operational workflows. The article recommends matching tools to organizational maturity, from OpenCost for smaller deployments to broader platforms for multi-cloud governance and enforcement, and highlights growing Kubernetes use for AI inference as a source of cost-management urgency. It also describes Harness features such as workload-level attribution, automated idle shutdowns, node-pool rightsizing, spot placement, anomaly detection, and budget alerts, alongside customer examples reporting lower Kubernetes and AWS costs after improving visibility and optimization.

AI security governance is presented as a structured approach for keeping AI models, agents, and assistants within an organization’s security and compliance boundaries through four connected pillars: clear policies, repeatable risk assessments, monitoring and audit records, and named accountability. The framework responds to growing regulatory requirements, including EU AI Act transparency and high-risk obligations, as well as the rapid adoption of AI tools in software development, where shadow AI, unowned systems, and incomplete activity records can create security and compliance gaps. Its central artifact is an AI risk register that inventories AI systems and use cases, assigns risk tiers based on data sensitivity, autonomy, and potential impact, identifies an accountable individual owner, and establishes review schedules. The approach aligns with the NIST AI Risk Management Framework and ISO/IEC 42001, emphasizing that governance should be continuously maintained rather than treated as a one-time approval process. Harness advocates embedding these controls into development pipelines through policy as code, service scorecards, observability, audit trails, and role-based access controls, citing customer examples involving consolidated deployment records and faster, more standardized feature-flag releases.

At {unscripted} San Francisco 2026, panels on AI in software delivery emphasized that trust depends less on agents themselves than on governance, contextual knowledge, and guardrails calibrated to the reversibility of their actions, particularly in regulated industries such as medical devices. Speakers argued that security must be embedded directly into pull-request workflows because attackers can weaponize disclosed vulnerabilities in about a day while organizations still take roughly seven days to patch, and current AI models remain stronger at validating vulnerabilities than comprehensively finding them. Organization-wide adoption of AI coding tools is also rapidly increasing code volume and shifting the primary constraint from generation to code review, specification writing, and recovery capacity, requiring review processes and teams to scale alongside automated output. The event’s roadshow continues through several U.S. and European cities before concluding with a virtual session on September 30.

Policy as Code (PaC) has become central to automated security and compliance governance by making rules version-controlled, testable, machine-readable artifacts separate from application logic, but policy authoring complexity remains a major adoption challenge. Open Policy Agent (OPA) is the leading general-purpose framework because it can govern infrastructure, CI/CD pipelines, Kubernetes, and other systems using Rego, though its declarative syntax, evolving data schemas, and specialized knowledge requirements create a “Rego Tax” for platform teams. In Kubernetes, Kyverno has gained adoption by using familiar YAML-based policies, while Kubernetes’ native Common Expression Language support increasingly handles simple validations and pushes external engines toward more complex functions. For application authorization, AWS Cedar emphasizes typed schemas, performance, and formal verification, while its Dogwood extension adds temporal reasoning intended to govern sequences of AI agent actions; however, Cedar remains more limited than OPA for broad infrastructure use. The article predicts that organizations will increasingly use multiple policy engines for different contexts and presents Harness’s natural-language-to-Rego generation, testing tools, and policy libraries as ways to reduce the effort of implementing OPA-based governance.

Harness reports that SecureIQLab’s August 2026 Cloud WAAP v5.0 CyberRisk Validation Comparative Report named its Web Application and API Protection platform a Leader among 12 tested vendors, with six vendors receiving that designation and five meeting both “Secure by Design” and “Secure by Default” criteria. According to the report, Harness scored 99.8% in security efficacy and 98.2% in operational efficiency, including reported 100% results for OWASP API Top 10 protection, advanced-threat coverage, deployment and management ease, false-positive avoidance, and GenAI and LLM operational efficiency. SecureIQLab’s methodology assessed both defensive effectiveness and operational usability, while AI-focused testing covered selected OWASP LLM risks and was scored separately from overall WAAP operational efficiency. Harness frames the results as support for its approach to securing applications, APIs, and AI systems amid growing use of agents, LLMs, tool calls, and AI-assisted attacks.

Engineers often overlook cloud and AI costs because spending data is delayed, aggregated, and separated from the code, infrastructure, and model decisions that create it, rather than because of indifference. The piece argues that traditional FinOps dashboards and periodic cleanup efforts are reactive and ineffective, especially as AI workloads introduce rapidly growing costs from token usage, inference, GPUs, and inefficient model configurations. It advocates AI cost management agents that provide real-time, contextual cost feedback within engineering workflows, such as pull requests, CI/CD pipelines, and service-level operations, while automatically enforcing policies, identifying anomalies, right-sizing resources, stopping idle environments, and routing workloads to more efficient models. Harness positions its Cost Management Agent as a tool for integrating visibility, allocation, root-cause analysis, governance, and automated action across AWS, Azure, GCP, Kubernetes, and AI workloads, with the goal of making cost optimization a routine engineering metric alongside performance and reliability.

A Harness survey of 700 organizations deploying AI agents found that 74% to 77% report confidence in their testing, security, inventory, cost, and rollback capabilities, yet many lack controls capable of verifying those claims. While 75% believe their agents are secure end to end, only 23% use dedicated agent-security tools in production, and although 77% believe they maintain complete inventories of agents, MCP servers, and LLMs, just 44% use active discovery tooling. Testing and release practices show similar gaps, with only 19% having automated gates that block every faulty release and many organizations making production-promotion decisions case by case. The report argues that conventional code-management and security tools often do not address agent-specific risks, especially because agent behavior can vary between runs, and notes that 58% of respondents have experienced more production incidents per 100 changes since adopting agents. It recommends organizations verify their security monitoring, inventory discovery, testing gates, and promotion standards with concrete evidence rather than relying on confidence, particularly as 76% expect to invest in agent lifecycle tooling within six months.

Harness CLI 3.0 is presented as a terminal-native interface for Harness Code and related platform services, combining pull request management, CI/CD visibility, AI code reviews, secrets, GitOps, and other workflows through a consistent verb-noun command structure. The CLI supports runtime discovery of modules, commands, fields, and output schemas, with human-readable and machine-readable formats intended to serve both developers and autonomous coding agents. Its Harness Code capabilities include cross-repository PR inboxes, PR checkout, threaded conversations, review decisions, comments, merging, AI-generated risk insights and reviewer suggestions, and automated criteria checks. Because it connects code reviews directly to Harness CI/CD executions, users can inspect PR checks and stream logs from failed pipeline stages without leaving the terminal. An optional interactive `--ui` mode provides navigable terminal views for moving among repositories, PRs, checks, and logs, while JSON support, scoped token authentication, RBAC, and audit trails support scripted and agent-driven workflows. The post positions the open-source, Apache 2.0-licensed CLI as a broader alternative to GitHub CLI for organizations seeking unified code-review and delivery operations across the Harness platform.

Harness promotes “contained pen tests” as narrowly defined, security-approved failure experiments that run within CI/CD pipelines rather than granting broad production access for traditional penetration testing. Each experiment targets one service and condition, such as identity-provider outages, credential revocation, expired certificates, tampered tokens, unexpected outbound traffic, privilege drift, abuse-like load, or node failures, to verify whether controls fail closed instead of silently permitting unsafe behavior. The approach emphasizes authoring and approving tests once, then running them automatically on every release while generating immutable audit evidence of results, suppressions, and skipped checks. By predicting and ranking risks before applying the smallest necessary disruption, the model aims to make security validation a repeatable governance and release-gating process suited to regulated environments, with Harness offering limited free monthly runs for its Resilience Testing platform.

Harness argues that traditional Operational Readiness Testing often becomes outdated after launch because it is treated as a one-time checklist rather than an ongoing assessment of changing services, dependencies, and configurations. Its Resilience Testing product integrates AI agents into CI/CD pipelines to continuously identify resilience risks, generate and execute tests, analyze results, and use findings as deployment gates. The platform supports chaos testing for failure resilience, load and composite load testing for behavior under traffic and faults, disaster-recovery testing to provide RTO/RPO evidence, and passive risk detection for configuration weaknesses such as missing health probes or inadequate redundancy. Harness positions these capabilities as technical evidence that can be repeatedly produced across deployments, while noting that they do not replace operational ORT activities such as reviewing runbooks, completing on-call handovers, or performing site checks.

AI coding tools have become widely adopted, shifting engineering leaders’ focus toward demonstrating whether rising spending produces meaningful business value. A Harness panel advised measuring outcomes across the full software delivery lifecycle rather than relying on easily gamed activity metrics such as lines of code, pull requests, or token usage, while combining quantitative indicators like cycle time and defect rates with qualitative evidence from real work. Panelists emphasized granular attribution of AI costs to tickets, features, models, test runs, and workflow stages as essential for identifying waste, improving model selection, and connecting spending to production results. They also noted that reliable pre-AI baselines are difficult because development practices and AI capabilities are changing rapidly, making end-to-end measurement and bottleneck detection especially important. Model prices may decline while total costs rise as usage expands, prompting calls for deliberate budgeting, governance, and visibility tailored to team needs rather than a single universal approach. The discussion further argued that organizations should periodically reconsider whether AI should merely accelerate existing development processes or enable redesign of processes originally created for a more expensive, slower way of building software.

Internal developer portals are most effective when they include native CI/CD capabilities rather than functioning only as service catalogs and documentation hubs. The article argues that tightly connecting portals to pipeline execution enables developers to create services, deploy versions, and roll back changes through one interface, while reducing manual YAML configuration, ticketing, context switching, and inconsistent workflows. It contends that platform teams can scale self-service safely by defining reusable pipeline templates, promotion policies, approval requirements, and observability integrations that are automatically applied and enforced across services. In contrast, loosely coupled integrations based on APIs, webhooks, or custom scripts may create context loss, pipeline drift, governance gaps, and operational complexity as organizations grow. Harness IDP is presented as an example of a portal that natively scaffolds, triggers, governs, and records CI/CD workflows, allowing developers to use standardized delivery processes without needing to manage underlying pipeline details.

Harness AI Evals is presented as a CI/CD quality gate for AI agents, addressing behavioral failures that conventional software tests may miss even when services are available and functioning technically. In an e-commerce support-agent example, 32 golden scenarios were evaluated for answer relevancy, task completion, and toxicity, with deployments blocked unless they met a 70% threshold. An initial 65% result exposed incorrect billing facts, incomplete shipping information, indirect policy answers, and responses to the wrong customer question, leading developers to improve knowledge sources and prompts rather than lower the standard. Subsequent runs achieved 75% and 78%, but differing results across identical evaluations also highlighted AI non-determinism and the need to verify improvements through repeated testing while distinguishing genuine quality failures from broken infrastructure or evaluators. By placing evaluation directly within the delivery pipeline, Harness aims to make AI behavior a release criterion alongside builds, tests, and service health checks.

Harness announced 58 product updates in August 2026 focused on supporting AI-driven software delivery while maintaining security, governance, and operational control. Major releases include an agent-scale code repository capable of handling thousands of pull requests and commits per second, AI Code Review that prioritizes risks using organizational delivery history, and a CLI that recorded more AI-agent actions than human actions shortly after launch. New AI security and infrastructure tools include AI Risks scanning for prompt injection, tool poisoning, and data-exfiltration threats in agent skills; the Blast Radius Agent for Terraform and OpenTofu risk scoring and dependency visualization; and remediation agents that create reviewable pull requests for infrastructure drift and vulnerabilities. Additional updates span database impact analysis, Helm and workload identity support, lower cloud build pricing for several resource types, expanded artifact package formats, runtime API security features, MCP discovery and governance, AI-enabled dashboards and chat integrations, developer portal enhancements, resilience-testing agents, and metric-based safeguards for feature-flag rollouts.