Harness Blog

In the fast-paced world of modern software delivery, compliance is often a bottleneck. While our existing OPA-based Policy as Code feature has long empowered teams to encode complex authorization checks and enforce granular governance across their DevOps workflows, we know that starting from a blank page can be daunting. Security and governance teams struggle to keep up with the volume of releases, while developers often find the initial setup of these policies to be time-consuming.

Today, we are thrilled to announce a significant leap forward in automated governance: Policy Packs.

What Are Policy Packs?

Policy Packs are a curated library of pre-written Rego policies designed to align your software delivery lifecycle (SDLC) with the most popular compliance frameworks.

By providing out-of-the-box policies, we are eliminating the primary barrier to automated governance: the need to write and maintain complex Rego code from scratch. With Policy Packs, you can adopt industry-standard guardrails by adapting our out of the box policies from the policy packs with zero to little customization. This will allow your teams to focus on shipping features rather than writing policy.

Comprehensive Framework Coverage

Our Policy Packs initiative covers the frameworks that matter most to your business and your auditors:

• SOC 2: Focuses on trust service criteria like security, availability, and processing integrity. Our policies help enforce peer-reviewed pull requests and automated change management gates.
• NIST: Specifically targeting SP 800-53 and 800-171, these policies cover configuration management, system integrity, and supply chain risk management via automated SBOM generation and SLSA provenance.
• PCI DSS: Designed for organizations handling payment card data, these policies enforce secrets management, network segmentation, and mandatory vulnerability patching.
• HIPAA & HITRUST: For those dealing with protected health information (PHI), these packs provide automated data leakage prevention and secure API monitoring.

Turning Framework Requirements into DevOps Controls

Compliance is no longer just a "point-in-time" audit; it’s a continuous process. Policy Packs map technical events directly to framework controls, providing the evidence your GRC teams and auditors need.

Common Compliance Challenges in DevOps

In our work with industry leaders, like those in highly regulated industries such as healthcare, finance, or insurance, we’ve seen that compliance is often a manual, high-friction process that slows down software delivery. Two of the most common challenges teams face are:

• The "audit readiness" blind spot: Teams often struggle to prove that their pipelines are consistently secure. Without automated guardrails, compliance is only checked during point-in-time audits, leaving gaps that are hard to identify and remediate.
• The manual approval bottleneck: Many organizations rely on manual checkpoints to satisfy framework requirements. This frustrates developers who want to move fast, leading to "compliance fatigue" where processes are bypassed or ignored.

Harness Policy Packs address these challenges by shifting governance left, embedding compliance checks directly into your CI/CD pipelines so that validation happens automatically with every commit.

Example Policy: Enforcing Separation of Duties

A classic requirement for frameworks like SOC 2 and NIST is "Separation of Duties." In a modern DevOps workflow, this means the person who writes and commits the code cannot be the same person who approves the deployment to production.

To enforce this, a compliance policy in your pipeline would verify the identity of the commit author against the identity of the deployment approver. If the system detects that the author and the approver are the same individual, the policy automatically blocks the deployment. This ensures that every production change has been independently peer-reviewed, providing auditors with a tamper-proof guarantee that your internal controls are working as intended without requiring manual intervention from your GRC team.

Why This Matters

1. Shift governance left: Catch violations before they ever reach production by enforcing policies during the save, run, or step phases of your pipeline.
2. Accelerate audit readiness: Move from "preventing risk" to "proving compliance" with a tamper-proof evidence vault that stores all builds, scans, and approvals.
3. Reduce risk: Mitigate legal and audit risks by using policies that are directly mapped to specific framework controls.
4. Universal coverage: Whether you are using CI, CD, Feature Management, or Cloud & AI Cost Management, our one framework provides cross-module coverage across the entire platform.

Get Started Today

The journey to automated compliance doesn't have to start with a blank page. Get access to our policy packs in the repository here to get started. You can leverage our native Git integration for OPA rego policies to fork the policies from the repository linked above and import them into your account.  

Get ready to stop audit delays before they start. 

The open-source landscape has witnessed another highly automated, ecosystem-level subversion. On June 17, 2026, a critical software supply chain attack struck the Mastra AI framework - a popular open-source TypeScript ecosystem used widely to build AI agents, workflows and RAG pipelines. By exploiting a compromised contributor account, threat actors successfully mass-published 144 malicious packages under the official @mastra npm scope.

The packages themselves contained no malicious code within their repositories; instead, they were altered at the registry level to pull in a weaponized transitive dependency called easy-day-js. Any developer workstation, CI/CD runner or cloud environment executing a routine installation during the compromise window was immediately exposed to a sophisticated cross-platform information stealer. This article delivers a comprehensive technical teardown of the attack mechanics and its stealthy execution pipeline.

Preface

Modern application engineering moves at the speed of automated dependency resolution. Rather than writing utility functions from scratch, software teams routinely orchestrate architectures that pull hundreds of third-party open-source components during active builds and deployment pipelines. This reliance sets up a structural trust chain: developers trust the package registry, the registry trusts the maintainer's cryptographic identity and downstream environments trust that updates are safe and authentic.

However, this architecture exposes a massive, interconnected attack surface. When an adversary manages to compromise an upstream account or subvert a single verification step, the entire downstream distribution network turns into an automated malware delivery pipeline. The Mastra incident highlights a growing shift where threat actors stop targeting production firewalls directly and focus heavily on poisoning the automated software supply chain.

Introduction

At its core, the Mastra supply chain compromise was designed to abuse default package installation behavior to execute arbitrary code, bypass standard static scanners, harvest sensitive host credentials and establish long-term persistence across multiple operating systems. 

What makes this attack structurally advanced is its combination of trust exploitation and defensive evasion:

• Provenance Deception - While the Mastra ecosystem typically publishes official releases via automated CI pipelines backed by SLSA provenance attestations, the attacker used a hijacked contributor token to publish directly to the npm registry. By stripping the provenance attestations, the malicious versions bypassed traditional verification layers while remaining structurally identical to legitimate software updates.
• Transitive Infiltration - The core source code within Mastra's public GitHub repository remained entirely clean. The anomaly was introduced solely inside the published registry tarballs by altering the package.json configurations to demand an external, attacker-controlled module.
• Volatile Loading & Self-Deletion - The first-stage payload was engineered as a transient dropper. It disabled local transport security, fetched a secondary backdoor payload into memory, spawned it as an isolated system process and then deleted its own source files from disk to eliminate obvious post-incident footprints.

Deepdive Into The Mastra Exploit

The campaign was executed within an intensive, automated 88-minute window. Rather than engineering a complex repository exploit, the attacker capitalized on a dormant contributor account ehindero whose publishing access to the @mastra npm scope had not been explicitly revoked. Let's break down the exploit lifecycle step-by-step.

Initial Access & The ehindero Account Compromise

Every supply chain attack requires an initial wedge to subvert the trust architecture. In this campaign, the breach did not stem from a flaw in Mastra’s core source code, but rather from an authentication gap on a historical contributor account by the name of ehindero. Security analysis indicated the account takeover occurred through a combination of two common supply chain vulnerabilities as discussed below.

• The contributor account lacked enforced Multi-Factor Authentication on the npm registry. Threat actors cross-referenced public data breaches to match historical password reuse, successfully logging directly into the publisher profile via automated scripting.
• Further forensic tracking suggested that an active personal access token with broad scope write permissions had accidentally been preserved inside an unencrypted local configuration environment on a legacy workstation.

The Transitive Dependency & Caret Range Trick

The attack relied heavily on establishing a convincing upstream dependency. On June 16, 2026, the threat actor published a "bait" version of a typosquatted package named easy-day-js, mimicking the popular dayjs library. This initial version, v1.11.21, was completely clean and byte-for-byte identical to legitimate components, designed purely to evade early automated registry profiling.

The following day, the attacker published easy-day-js@1.11.22 - this time embedding a malicious postinstall script execution block. Simultaneously, using the hijacked contributor credentials, the attacker mass-republished 144 packages across the @mastra/* scope. In each of these packages, the attacker injected exactly one line given below into the published package.json:

"dependencies": {
  "easy-day-js": "^1.11.21"
}

Because npm interprets the caret ( ^ ) range to mean any minor or patch update up to the next major version, any fresh invocation of npm install for a Mastra package automatically resolved, downloaded and integrated the malicious v1.11.22 payload. 

Bypassing Trusted Publishing Infrastructure

Mastra's legitimate delivery pipeline relies on OIDC-based short-lived publishing tokens. However, the npm registry still allowed manual token authentication paths. By utilizing a long-lived personal token belonging to the compromised account, the adversary circumvented the official GitHub Actions release loop. Although the resulting packages lacked the standard SLSA provenance attestations generated by the framework’s CI runner, consumption policies at the developer level rarely block packages simply due to missing attestations, allowing the unauthorized code to execute freely.

Detached Execution & Stealth Mechanics

When a system triggers the installation of the tainted package, the postinstall lifecycle hook automatically invokes an obfuscated script named setup.cjs. The loader performs the following actions:

• Disables TLS Verification - It overrides the environment configuration with process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0", forcing the Node runtime to accept unverified, self-signed SSL certificates from the attacker's infrastructure.
• Drops Operational Logs - It creates temporary tracking files under the host's temp directory named .pkg_history and .pkg_logs.
• Fetches Stage 2 - The loader initiates an outbound HTTP request to the attacker's Command and Control (C2) endpoint, 23.254.164.92:8000, to retrieve an encrypted secondary payload.
• Detached Spawning - The second stage is written to a randomized 12-hex-character .js file and executed as a detached child process, giving it an independent process group that outlives the parent npm install command.
• Forensic Self-Deletion - The moment the second stage initializes in memory, the loader invokes fs.rmSync(__filename, { force: true }), completely removing the installer script from the local node_modules directory to blind basic static security utilities.

Cross-Platform Info-Stealing & Persistence

The secondary payload operates as a comprehensive cross-platform credential harvester. It systematically searches the host environment for sensitive telemetry:

• Browser Data Extraction - Targets local storage and credentials from Google Chrome, Microsoft Edge and Brave browsers.
• Cryptocurrency Exfiltration - Targets more than 160 browser-based cryptocurrency wallet extensions including MetaMask, Phantom, Coinbase and Binance to drain active sessions.
• Credential Harvesting - Scans local user spaces for cloud configuration tokens like .aws/credentials, environment variables, database keys and SSH profiles.

To ensure long-term control, the malware checks the host OS and installs specific persistence payloads. All harvested data is packaged and exfiltrated to the secondary C2 server located at 23.254.164.123.

Attacker compromises active/former contributor account (ehindero)
↓
Attacker publishes clean bait version easy-day-js@1.11.21
↓
Attacker uploads weaponized version easy-day-js@1.11.22 with postinstall hook
↓
Attacker uses compromised token to mass-publish 144+ @mastra packages
↓
Injected dependency ("easy-day-js": "^1.11.21") added directly to registry tarballs
↓
Developer or CI/CD runner executes npm install for a Mastra package
↓
Registry resolves caret range ^1.11.21 to the malicious v1.11.22
↓
postinstall lifecycle script triggers setup.cjs hook automatically
↓
Loader disables TLS verification and writes local tracking logs
↓
Second-stage payload downloaded from C2 infrastructure (23.254.164.92)
↓
Payload executed as a detached child process to survive parent completion
↓
setup.cjs executes self-deletion routine to erase forensic footprint
↓
Second stage harvests browser data, 160+ crypto wallets and password managers
↓
Cross-platform persistence established via LaunchAgents, systemd or Registry Run keys
↓
Stolen host credentials and secrets exfiltrated to C2 server (23.254.164.123)

Ecosystem Impact: The AI Pipeline Risk Factor

The blast radius of this campaign is significantly amplified by Mastra's core function as an AI development framework. Unlike generic utility libraries, AI orchestration frameworks are explicitly deployed in data-rich environments. They sit at the intersection of production software loops and deep enterprise backends, routinely interacting with proprietary vector databases, LLM clusters and extensive data integration pipelines.

Consequently, a compromise within this specific ecosystem does not just threaten basic web infrastructure but also exposes high-value LLM API tokens, production database credentials and training data connection points. With a weekly download volume exceeding 1.1 million across the framework and the foundational @mastra/core package pulling roughly 918K downloads alone, the potential data exposure across developer endpoints and automated AI build servers represents a systemic risk to enterprise AI security models.

Compromised Packages

The entire compromise in the npm registry stems from the weaponized library easy-day-js, specifically version v1.11.22. This served as the malicious transitive dependency, resulting in the compromised Mastra AI framework outlined in the table below.

‍

Remediations 

Defending against registry-level poisoning requires moving beyond passive perimeter filtering to implement proactive environment isolation and strict runtime controls. Organizations should immediately deploy the following protective protocols:

• Neutralize install-time droppers by globally disabling automatic package script execution. Run npm config set ignore-scripts true across all developer workstations and CI environments.
• Commit strict lockfiles like package-lock.json and pnpm-lock.yaml to version control and utilize deterministic installation flags like npm ci or pnpm install --frozen-lockfile within CI pipelines to prevent automated caret resolutions from pulling unverified upstream releases.
• Configure internal package consumption policies to strictly reject public registry updates that lack verified SLSA provenance attestations or match anomalies where a package shifts from a trusted CI publisher workflow to a manual personal token publish.
• If an infection vector is discovered, treat the host or runner as entirely compromised. Immediately rotate all connected cloud credentials, source control keys, database strings and LLM API keys exposed within that environment.
• Use Software Composition Analysis platforms such as Harness Supply Chain Security (SCS) to continuously inventory dependencies, enforce policy gates, detect malicious packages and block compromised artifacts before they enter build and release pipelines

According to Harness’s analysis of the npm attacks, organizations should treat CI/CD pipelines as critical security infrastructure, combining SBOM visibility, policy enforcement, provenance validation and automated dependency risk analysis to prevent trusted publishing systems from becoming malware distribution channels. Read more about it here.

How Harness Supply Chain Security Helps

Harness SCS helps you quickly detect and contain compromised dependencies like the Mastra AI packages before they impact your pipelines. With real-time visibility into your SBOMs and dependency graph, you can identify affected versions, trace their usage across builds and environments and block them using OPA policies. This ensures malicious packages never propagate through your CI/CD or AI workflows.

Detect Compromised Packages

Harness SCS enables instant search across all repositories and artifacts to quickly identify if compromised package versions exist in your environment. The moment such a malicious package is disclosed, you can pinpoint its presence and assess impact across your entire supply chain in seconds.

Block Compromised Packages

Harness AI streamlines response to incidents like the Mastra AI compromise through simple natural-language prompts. With a single prompt, you can generate OPA policies to block affected versions of Mastra packages, for example, across all pipelines, preventing malicious packages from entering builds or deployments. As new compromised versions emerge, these policies can be quickly updated to maintain strong preventive controls across your SDLC. SCS customers can use this OPA policy to detect and block the affected versions.

Track & Remediate Issues with Developers

Harness SCS automatically detects compromised versions across both production and non-production environments. Teams can track remediation, assign fixes and monitor progress through to deployment, ensuring exposed credentials and vulnerable dependencies are addressed quickly. This end-to-end visibility helps contain the impact and prevents compromised packages from persisting in your supply chain.

Next Steps In The Face Of Supply Chain Attacks

The easy-day-js campaign highlights how quickly a malicious package can expose high-value secrets when embedded deep within registries and CI runners. Given its role in managing dependencies and packages across projects, the impact extends beyond code to API keys, prompt data and downstream systems, often bypassing traditional security checks.

Defending against such attacks requires more than reactive fixes. Teams need real-time visibility into dependencies, the ability to enforce policies to block compromised versions and continuous tracking to ensure remediation is complete across all environments. Harness SCS enables teams to quickly identify where affected package versions are used, prevent them from entering new builds and ensure fixes are consistently rolled out.

With these controls in place, organizations can limit credential exposure, contain threats early and secure their supply chain against attacks like the Mastra packages compromise.

A new report from LeadDev and Harness makes one thing clear: AI coding tools have fundamentally changed how much code organizations are producing. What has not changed nearly fast enough is how that code gets released.

The State of AI-Driven Software Releases 2026 report, based on responses from 500424 engineers across industries and company sizes, puts real numbers behind a problem that engineering leaders have been feeling for a while. AI is accelerating the code creation side of the SDLC. The downstream side, getting that code safely and confidently into production, is struggling to keep pace.

Here are three findings that stand out.

1. Code review is becoming the new bottleneck

57% of organizations still require a manual, human-in-the-loop review for every single line of AI-generated code, regardless of risk level. Among that group, 38% are spending more time on code review than before AI tools arrived. Meanwhile, 32% of respondents saw their release sizes grow after introducing AI-generated code.

The math does not work. AI is producing more code, often in larger pull requests, while review capacity stays flat. The bottleneck that used to sit at the code generation stage has simply moved downstream.

The answer is not to remove humans from the process entirely. It is to be smarter about where human judgment is required. Feature flags change the equation here in a practical way: when AI-generated code ships behind a flag that is off by default, teams can deploy continuously without requiring every line to be perfectly validated before it touches production. The review still happens, but it is no longer a gate on the entire release. Changes can go live in a controlled state, exposed to a limited audience or no one at all, until the team is confident enough to turn them on. That decoupling of deployment from release is what makes it possible to keep pace with AI-generated output without sacrificing oversight.

2. The guardrails gap is real, and it is growing

Only 49% of organizations have specific guardrails in place for AI-generated code. That means roughly half of teams are shipping AI-assisted code with the same review and validation processes they used before AI tools existed. The industry went through a decade of work to build DevOps discipline, continuous delivery, and quality gates into the SDLC. The rush to AI has created pressure to skip that rigor on the release side.

The numbers shift significantly by company size. Vulnerability detection is in use at 44% of large enterprises, but only 16% of smaller companies. Smaller organizations are moving faster with less protection, which compounds as AI-generated output increases and as AI-powered product behavior becomes harder to predict at runtime.

Progressive delivery is the practical guardrail that works at AI speed. Rather than trying to catch every risk before deployment, progressive rollouts expose changes to a small percentage of users first, then expand based on real signals. If something degrades, a feature flag kill switch stops the exposure immediately without requiring a full rollback. Teams that adopt this approach can move faster, not slower, because the blast radius of any individual change is controlled from the start. For AI-powered features specifically, where behavior can drift in ways that are difficult to predict in testing, that kind of runtime control is not optional. It is the safety layer that makes safe shipping possible.

3. More experimentation, less measurement

58% of organizations say they are running more experiments than before, which is genuinely good news. AI coding tools are helping teams build and test more ideas with real users, and that increased experimentation is one of the strongest signals that teams are adapting well to higher code velocity.

The challenge is that 52% of respondents cited a lack of clear metrics as their biggest challenge when working with AI-generated code. Only 29% of organizations are actually measuring the impact of AI tools on their teams at all. Running more experiments without the infrastructure to interpret results and make confident decisions is not a learning system. It is noise.

The teams getting the most value from increased experimentation are the ones connecting feature rollout directly to measurement. That means defining success metrics before a flag turns on, monitoring guardrail metrics during rollout, and having clear criteria for whether to expand, iterate, or stop. Experimentation only compounds in value when teams can close the loop from release to evidence to decision. Without that structure, more exaperiments just means more uncertainty.

What comes next?

The report contains much more data that paints a picture of an industry at a real transition point. AI has changed the pace of software creation, but creating code faster is not the same as releasing better software faster. The teams pulling ahead are treating the release layer with the same discipline they have applied to code generation: progressive delivery, controlled exposure, automated guardrails, and experimentation connected to real decisions.

Feature flags, progressive rollouts, and experimentation are not optional safeguards for AI-driven development. They are the foundational layer that makes AI velocity sustainable.

Want the full picture? Download the State of AI-Driven Software Releases 2026 report for the complete data, including how organizations are adapting their guardrails, what progressive delivery practices the leading teams have adopted, and what the path forward looks like.

When we launched Autonomous Worker Agents, the message we led with was simple: governance is inherited, not integrated. Agents don't get security bolted on after the fact. They inherit the OPA policies, RBAC, and audit trails already running your production pipelines. This post is about the layer underneath that promise: isolation.

We let an Autonomous Worker Agent run shell commands and call APIs inside our pipelines. Then we sat down and asked the uncomfortable question: what happens the moment it goes rogue? This post is about the four walls we put around the agent so that a break-in stays a break-in and never becomes a breach.

‍

OUR STARTING ASSUMPTION

The agent is already compromised. Not might be...already is. Everything below follows from that one sentence.

Key takeaways

• The agent is the threat model. An agent that runs tools based on a model's output is one bad prompt away from doing whatever an attacker wants. We don't try to make that impossible. We assume it's already happened and ask what the agent would still be unable to do.
• Defense comes in layers. A hardened image removes the tools an exploit needs. Isolation keeps the agent away from the secrets. A broker means it never holds a real key. A proxy bounds where data can go. Four layers, each doing one job.
• No single layer is load-bearing. Each layer assumes the one before it already failed. A break-in has to beat all four, one after another, and every one is enforced by the kernel or the network,. never by the model's judgment.
• Proven, not promised. We replayed a real CVSS-9.0 breach against our own image. The step that used to dump 709 live secrets now returns 33 variables and zero usable credentials. Every layer ships with a test that has to pass first.

‍

The old way breaks on contact with the real world

The first wave of agent platforms all looked the same. Take a capable model, hand it some tools, hand it some secrets, and let it run. It's fast to build. It sounds reasonable in a design review. It's also exactly how we built our first internal agent.

Then we actually looked at what that agent does all day. It reads a prompt, makes a plan, and runs tools (a shell, a file editor, an HTTP client) based on the output of a model that is itself reading whatever it's been pointed at: a README, a webpage, the result of the last tool call, a dependency's install script. None of that text is trustworthy by default. And the model is the thing deciding what in it counts as “information” versus what counts as “instructions.” That call is exactly what models are worst at making.

Here's what that looks like in practice. A README that says, as part of setup, run env > .config and continue, doesn't read like an attack on a model. It reads like a setup. The model isn't being careless. It's doing exactly what it was built to do, which is follow the text in front of it. The text just wasn't trustworthy in the first place.

That's not a bug we can patch inside the model. It's a mistake in how we built the system around it. We were treating an agent like trusted code when its actual job is to read untrusted input and act on it. Once we saw it that way, the fix was obvious: stop pretending otherwise.

Same starting point for both columns below: a tool result with text the agent was never supposed to follow. What differs is everything built around the agent.

The naive shape vs. the hardened shape.

The Reframe: Stop asking if the model will behave

Our governing assumption is blunt: the process running the agent is fully under an attacker's control, the same as remote code execution, running as the agent's own user. We don't treat that as a remote possibility we're guarding against. We treat it as the starting condition.

Everything below follows from that one sentence. We stopped asking “Will the model refuse the malicious instruction?” We've already assumed it won't. The question that actually matters is: if the agent turned hostile this exact instant, what would the operating system, the filesystem, and the network physically refuse to do on its behalf?

That question, asked four times, is where the four layers of isolation come from. Isolation is the foundation: the part that has to hold even when everything else fails. It's not the whole story: separately, we control what an agent is allowed to touch, and we read the prompts and responses themselves for injection and sensitive data. Those are their own posts. This one is about the walls.

Here's the bigger picture those three fit into, so you can see where this post sits before we go deep on it:

The bigger picture: isolation is the deterministic foundation; identity/authorization and behavioral controls sit above it.

1. Isolation (this post)

Kernel, OS, network: deterministic. The agent can't reason its way out.

Image hardening

Process isolation

Secret isolation

Network isolation

2. Identity & Authorization

Two levels: who defines the permission surface, and what runs within it.

Operator level - RBAC: who creates the surface

• MCP connectors: creates + tool scope
• Agent creation: creates + tool scope
• Pipeline runs: who can execute

Agent level - authorization: what runs within that surface

• Scoped tokens: short-lived
• Allowed tools: connector-level
• OPA - runtime: pipeline policy

3. Behavioral Controls

Content and call inspection: the only probabilistic layer.

• Injection scan: LLM gateway
• PII + toxicity: LLM gateway
• Call security: MCP gateway
• OPA policies: gateway

Not load-bearing on its own. Designed to fail safely into 01 and 02.

Four threats. Four layers. No overlap in the job.

Working from that one assumption, a concrete list of things a hostile agent would try falls out almost by itself. Each one gets exactly one layer of defense, built to answer it and nothing else. Below is the map, running from the outermost edge of the container inward to the network path out.

Walking the chain, outside in

Each section below stands on its own. If you only care about one threat, say, where your secrets actually live, jump straight to it. Read straight through, and you get the whole chain, from the edge of the container to the only network path out.

Layer 1: Image hardening: An empty toolbox

The threat

Break into a normal container and you'll find a fully stocked workshop waiting. A compiler to build a payload. A package manager to pull one down. Setuid binaries to climb privileges. Network tools to probe around and call home. A general-purpose base image hands an attacker all of it, for free, the moment they're inside.

The defense

We strip the image down to the studs at build time and the stripping is permanent, not a setting someone can flip back:

• No compiler. The build toolchain, C compiler, linker, make, is purged. Nothing left to compile a second-stage payload with.
• No package manager. The agent can't install its way to a capability the image doesn't already ship. (Package metadata stays, so vulnerability scanners and SBOM tooling still see exactly what's installed.)
• No setuid binaries. Every setuid and setgid bit in the image is cleared, closing the classic local privilege-escalation path.
• Read-only at runtime. The recommended way to run it locks the root filesystem read-only, with small writable scratch areas mounted separately, turns off privilege escalation, and drops every Linux capability the container doesn't need. The image ships ready for that posture and our published pod spec sets it.

In plain terms

Picture breaking into a workshop and finding the pegboard empty. No tools on the wall, no machine plugged in, nothing to build with. You can be standing right there, inside the room, and still unable to do anything.

Stripped at build time, irreversibly, compiler removed, package metadata only, setuid bits cleared, network utilities removed.

‍

Layer 2: Process isolation: Three users, one container

The threat

Even with no tools to build with, a compromised agent will still look at what's sitting around it: another process's environment variables, its memory, the files holding the keys. If everything inside the container runs as one user, all of that is just… readable.

The defense

Inside the single container, three distinct, unprivileged users run three distinct processes: the agent, the credential broker, and the egress proxy. The container starts as root only long enough to lay down permissions and network rules, then drops each process to its own user and never returns to root again.

The user running the agent is in none of the broker's groups, so the kernel denies it even the ability to traverse into the secret directory: every attempt comes back as a hard permission error, not a polite refusal. The broker's own source code is locked down the same way, so a compromised agent can't even read the logic it's trying to defeat.

In plain terms

Same building, different locks. Three tenants live under one roof, but tenant A's key was never cut to open tenant B's door. The building super hands out keys exactly once, at move-in, then leaves for good. Nobody can get a new key issued later, not even the super.

Kernel-enforced separation: not a convention, a permission error.

Layer 3: Secret isolation: The agent never holds a key

The threat

Credentials are the actual prize here: API keys, cloud tokens, platform tokens, registry passwords. In the naive design, they sit in the agent's own environment, and the agent can reach them the instant it wants to. One env dump, or a config file generated “with values baked in,” and they're gone.

The defense

We take the secrets away from the agent completely. The moment the container starts, before the agent process even exists, a classification pass runs over every environment variable. Anything that looks like a secret, caught by a generic naming convention, so a brand-new connector needs zero custom code, gets swapped, inside the agent's own environment, for a unique, single-use placeholder. The real value moves into a store that only the broker can read.

So the agent boots up and sees something like this, and nothing more:

One placeholder, one destination. Replays against any other host fail.

ANTHROPIC_API_KEY  = hbroker-Up4k…r3Q   # placeholder, not a key

ANTHROPIC_BASE_URL = http://127.0.0.1:8443/proxy/api.anthropic.com

The real key is nowhere in the agent's world, ever. When the agent makes its call, it builds a normal-looking auth header with the placeholder and sends it to the in-container broker. The broker, and only the broker, swaps it for the real key on the way out, and only at that exact moment.

The agent container holds zero cloud-credential bytes: the same model covers credentials that can't ride in a header. Cloud SDK credentials, Google service-account keys, AWS and Azure managed identity, get signed into the request body instead, so the broker stands in as a metadata server and mints short-lived credentials on demand. No key file, no service-account JSON, nothing.

In plain terms

It's the valet-key trick hotels use. The key you hand the valet starts the car and opens the door, but it won't touch the glovebox or the trunk. Even a dishonest valet holding that exact key can't drive off in the car parked next to yours, it simply doesn't turn that ignition.

Layer 4: Network isolation: Traffic can't leave the path

The threat

A compromised agent with open network access is a data-exfiltration tool, full stop. Phone home to an attacker's server. Push data to a public mirror. Tunnel it out over whatever port happens to be open.

The defense

All outbound traffic from the container goes through an in-container proxy running an allow-list. Approved hosts pass. Everything else is denied by default. The agent's traffic and the broker's traffic ride separate listening ports, so the two zones are never confused with each other.

A proxy only matters if the agent can't route around it, so three independent mechanisms keep it on that path:

• Set for the agent: not left to its discretion as a setting it could choose to ignore.
• An always-on guard inspects every command and file write the agent issues, and blocks anything that tries to disable or sidestep the proxy: unsetting proxy variables, a “no-proxy” flag, stripping the environment through a helper, mutating it from inside an interpreter, or even a quiet bypass written into a shell startup file.
• A kernel-level firewall rule pins the agent's user to the proxy and rejects every other destination, off-container hosts, the broker's private port, and cloud metadata endpoints. The capability that installs it is used once by root at startup, then dropped for good. The agent can never get it back, and can't edit, list, or flush the rule that contains it.

Real APIs occasionally echo a request's own credentials back inside an error body, so the broker scrubs responses on the way back too. A stray 401 can't hand the agent the very key the broker just injected.

In plain terms

One exit, and it's guarded. The fire doors are welded shut, the windows don't open, and the guard's own keys get taken away once the building is set up for the day, so nobody , not even the guard, can prop a door open later.

Three independent locks on one gate: not three settings, three different enforcement mechanisms.

Red-teaming our own design: Proof, not promises

None of this means much as an assertion, so we tested it the way an attacker would. We took a real, high-severity breach chain and replayed it against our own image, logged in as the agent.

Every other move in that chain failed the same way: each one stopped cold by a different layer.

Every layer is a release gate

Each isolation layer has its own end-to-end test that runs against the freshly built image, and the full breach-chain pentest above runs on top of all of them. Every check lives in the build pipeline ahead of the publish step, an image that regresses any single layer simply never ships, on either supported CPU architecture.

• Container smoke — Hardened image boots and is intact
• Process-isolation smoke — Three users separated; agent denied on secret files; egress ports pinned
• Secret-isolation test — Agent's environment holds only placeholders, never real secret bytes
• Per-host scoping test — A credential is injected only for its own host; off-target replays denied
• Egress-policy test — The allow-list is enforced and the deny-all default holds
• Credential-routing test — Each connector's traffic is routed and brokered correctly
• Proxy-bypass-guard test — Attempts to disable or route around the egress proxy are blocked
• Containment pentest — The full breach-chain replay above stays contained
• Image vulnerability scan — The published image clears the CVE policy

The proof isn't a slide from one audit done once. It runs on every release, and a single failure blocks the publish.

How it fits together

Security engineers have a name for this shape: the Swiss cheese model. Slice one piece of cheese and hold it to the light, there are holes in it. Every real-world control has gaps somewhere; that's just true, and pretending otherwise is how people get hurt. But stack four slices together, each with holes in different, unrelated places, and there's no longer a straight line through all four at once. None of these “slices” are guesswork, either. Each is enforced by a different mechanism, the build, the kernel, the filesystem, the network, so a gap in one almost never lines up with a gap in the next.

Attempt 1: finds a gap in image hardening, hits a solid wall at process isolation.

Attempt 2: gets three layers deep, still never reaches the prize.

A compromise of any single layer just lands in the next one. A tool that gets past the hardened image still can't read the secrets. An environment dump that gets read finds only placeholders. A placeholder that gets grabbed can't be aimed anywhere useful. And a connection that tries to phone home is pinned to the proxy and denied. That's the entire point of building it as four layers instead of betting everything on one wall.

The secure shape is the default

There's no separate hardening mode to opt into. You write an ordinary Agent step and pass your secrets the way you already do, under their normal names. The container does the rest before your agent process ever starts:

agent:
  step:
    run:
      container:
        image: harness-ai-agent:latest
      env:
        # Pass the real secret under the name the SDK already reads.
        # The engine swaps it for a placeholder before the agent starts;
        # The broker holds the real bytes and injects them only at egress.
        AWS_BEARER_TOKEN_BEDROCK: <+secrets.getValue("bedrock_token")>
        HARNESS_API_KEY: <+secrets.getValue("harness_token")>

That's the whole interface: no proxy wiring, no per-connector code, no placeholder plumbing on your side. The container classifies your secrets, swaps them for placeholders, writes a per-session network policy, drops to the three unprivileged users, and runs your agent, which never sees a single real credential.

Two things live in the platform, not the step: the three-user split and the read-only, capability-dropped runtime are set once in our published pod spec, and the kernel egress pin turns on wherever the runner can grant it. You don't wire any of it up per pipeline. It's how the image is meant to run.

‍

FAQs

Why layers instead of one strong control?

Because any single control can fail, and an agent running tools on untrusted output gives an attacker a lot of chances to find that failure. Layering means a break in one boundary gets caught by the next one. And each layer is enforced by a different mechanism – the build, the kernel, the filesystem, the network – so a gap in one doesn't line up with a gap in the next.

Where do the secret bytes actually live, and who can read them?

With the broker process, in a store owned by the broker's user and readable only by it. The user running the agent is in none of the broker's groups, so the kernel denies it access outright. The agent's own environment only ever holds placeholders.

Is the egress proxy mandatory, or can the agent route around it?

It's set for the agent rather than left to its discretion, and an always-on guard blocks the obvious ways to disable or bypass it. On top of that, a kernel firewall rule pins the agent's traffic to the proxy and rejects everything else – the same control enforced one level down, where the agent can't touch it.

How does a new connector get secured? Do you write code for each one?

No. Secrets are recognized by a generic naming convention, so a new connector's key gets placeholder-swapped and host-scoped automatically, with zero custom wiring required.

What about prompt injection itself – doesn't that defeat all of this?

Isolation doesn't try to stop the injection – it makes a successful one boring. A hijacked agent still can't read a secret, can't reach a host off the allow-list, and can't turn the container into a toolkit. The blast radius is bounded by the system, not by the model's judgment. Catching the injection payload in the content itself is a separate job, handled by the LLM gateway – that's the subject of the next post in this series.

‍

We shipped 62 features in June: roughly one every twelve hours! That pace isn't an accident. It's what happens when AI is writing more of the code, generating more of the tests, and clearing more of the review queue, and the rest of the delivery pipeline has to keep up.

This month's list touches almost every stage of that pipeline: builds that start faster, tests that write themselves, security scanning built for the volume of code AI agents now produce, feature flags that update without a redeploy, and on-call tooling that beats PagerDuty and OpsGenie on setup time alone. And on June 30, the biggest release of the month landed on top of all of it. Here's everything we shipped.

This month's biggest ships

Autonomous Worker Agents: Every step in a Harness pipeline, testing, security, deployment, and remediation, can now run as a reasoning agent instead of a fixed script, with the same governance and audit trails enterprises already trust for human-run deployments. It's the difference between AI helping write a script and AI running the step.

Parallel pipeline execution using a Directed Acyclic Graph: Pipelines can now declare dependencies between stages and run every independent one in parallel automatically, unlocking fan-out, fan-in, and diamond-shaped flows that sequential pipelines couldn't express. A convert-to-DAG API rewrites existing pipelines automatically, so the migration is a button, not a rebuild.

AI Engineering Insights: Measures what most engineering orgs are still guessing at: AI coding agent adoption over time, AI-committed code percentage, spend per developer, and PR cycle time for AI-assisted developers versus everyone else. It's the metric layer for the AI productivity paradox, not another dashboard of vanity stats.

‍

Here are the details:

Every pipeline step can now be an agent

On June 30, Harness introduced Autonomous Worker Agents, a platform for building and safely running AI agents that handle the work between writing code and shipping it to production. Every step in a pipeline, testing, security, deployment, and remediation, can now run as a reasoning agent instead of a fixed script, governed by the same scoped credentials, OPA policy enforcement, approval gates, and audit trails enterprises already use for human-run deployments.

Agents pull context from the Harness Knowledge Graph, connecting services, pipelines, deployments, incidents, and policies, and act through the Harness MCP Server, so a developer working in Cursor, Claude Code, or another editor can hand a task to a Worker Agent and get the result back without leaving their tool. A new Agent Marketplace lets teams find, clone, and customize both Harness-managed and community-built agents, so the agent one team builds to solve a problem becomes the starting point for the next team that hits the same wall. Worker Agents are available now to all Harness customers and work with any LLM provider. Read the full announcement here.

Builds that start faster and cache smarter

Docker Layer Caching and Build Cache now both support Azure Blob Storage as a backend, joining S3 and GCS. Teams running on Azure no longer have to route their caching through a different cloud to get the speed benefit. Find more details in the CI release notes.

CI build initialization on Kubernetes infrastructure now sends only the fields required to start a build, shrinking the initialization payload. Pipelines with a large number of steps start faster and more reliably as a result.

A new Test Management Dashboard lists every test, including flaky and quarantined ones, with health status and last-run results in one place, so no one has to go hunting through build logs to find the test that's been silently failing all week.

Small but real: the lite-engine HTTP client now handles 3XX and 4XX responses from the log service correctly, so a redirect or an error response during log streaming no longer takes the build down with it.

AI writes the tests, coverage tells you if it's enough

AI Test Automation now runs Playwright test suites natively, in beta, as a first-class execution engine. Teams bring their existing Playwright suites and run them on the platform with zero infrastructure to stand up or maintain. Learn more about running Playwright tests on Harness.

Watch the demo:

Existing tests can now be converted into natural language and downloaded, so teammates who don't work in code, PMs, auditors, and new hires can review or document test coverage without reading a test file. More on that in the AI Test Automation release notes.

And Harness Code Repository now shows what percentage of your codebase is actually covered by tests, surfacing untested paths before they turn into incidents.

Deployments that scale without more YAML

Pipelines can now declare dependencies between stages with a dependsOn field. Harness runs every independent stage in parallel the moment its predecessors finish, unlocking fan-out into multiple parallel deployments, fan-in to a single approval gate, and diamond-shaped flows where build, test, and infra stages converge before promotion, patterns a sequential pipeline simply couldn't express. A new convert-to-DAG API rewrites an existing sequential pipeline automatically, so migration doesn't mean a rewrite.

Templates now support custom floating tags, not just the built-in stable pointer. Template owners can create tags like prod, canary, or qa, each pointing at a different template version, and repoint any of them independently without touching a single line of consumer YAML. That means you can promote a new template version to canary, let it bake, then move prod once it's validated, with different environments running different versions at the same time.

A handful of other pipeline and delivery upgrades this month: the Copy command in Command steps can now preserve directory structure so same-named files in different subfolders stop overwriting each other on target hosts; Kubernetes Dry Run steps now accept kubectl flags like --server-side and --force-conflicts, so approval gates reflect what a real deployment will do; the Artifactory connector supports OIDC for credential-free authentication with short-lived JWTs; AWS OIDC connectors now tag sessions with environment identifiers, letting you restrict production secrets to production pipelines even on a shared delegate pool; Istio traffic routing steps support AND/OR match logic across route rules; approval steps can show details to non-approvers without granting them approval rights; and issue-comment webhook triggers now resolve to the latest commit message instead of the PR description, bringing them in line with every other trigger type. Find the full rundown in the continuous delivery release notes.

Security built for how much code AI agents write now

A new AI-powered SAST engine, in beta, validates findings in context to cut triage effort and catch vulnerabilities that traditional static scanners miss, purpose-built for a world where AI-generated code is multiplying the volume of things that need checking. Learn more about AI SAST.

‍

API Security Testing scans that get interrupted by timeouts or infrastructure issues can now resume from the point of failure instead of restarting from scratch. Scans also picked up a real-time validation summary tab, plus the ability to label and rename them so a security team running dozens of scans a week can actually tell them apart. Details are in the scan documentation.

‍

A new API Inspector automatically analyzes OpenAPI specs for security, design, and data validation issues before deployment, catching problems while they're still cheap to fix.

Approvers reviewing exemption requests can now adjust the requested duration instead of only accepting or rejecting it outright, which means fewer rejected requests that just get resubmitted with a smaller ask.

Teams can now bulk onboard Bitbucket repositories and run SBOM and security scans automatically, no manual pipeline setup required, and role-based permissions expanded across more supply chain workflows. Learn more about Bitbucket onboarding.

Harness AI now generates OPA policies directly, trained on OPA and REGO best practices, and can explain existing policies in plain language, so writing policy-as-code no longer requires deep REGO expertise on the team.

Rounding out security: issue detection policies can now scope to specific span attributes to cut noise, API exclusion rules gained span-attribute filtering for the same reason, a new Applications view groups related APIs and AI assets into business-centric categories like payments or order processing so large API inventories stay navigable, the older API Activity dashboard is being retired in favor of these newer views, and Role Assignment API endpoints now validate request payloads up front, returning clear errors instead of failing downstream.

Feature flags that update without a redeploy

Feature flag definitions can now be changed through a pipeline step that applies structured, atomic updates, batching multiple configuration changes into one consistent operation instead of stitching together raw patch calls. Find more details here.

And a new family of thin SDKs, built for browsers, mobile apps, and edge or serverless JavaScript, delegates flag evaluation to a remote evaluator in the cloud instead of computing it on-device. Rollout rules and segment definitions stay server-side; the SDK only gets the result. Learn more in the feature flag release notes.

Finding out what AI is actually doing to your engineering org

A new AI Engineering Insights capability tracks AI coding agent adoption across teams over time, measures output with metrics like AI-committed code percentage and lines generated, and monitors spend per developer and per commit. It also compares AI-assisted and non-AI developer performance head-to-head on PR cycle time and work items delivered, with a leaderboard for drilling into individual patterns. Read more in the AI DLC Insights release notes.

Cloud and AI cost management gets more precise

The Cloud and AI Cost Management overview page got a redesign: new widgets for top spenders, optimization impact, and service breakdown, plus support for AWS and GCP cost adjustments.

You can now connect OpenAI and Anthropic accounts directly through a guided three-step wizard with secure API key storage and live connection testing, currently behind a feature flag. Grouping AI traces by service in Cost Explorer now opens a drawer with run history, a span-level timeline, and cost attribution down to the individual trace. And a new Asset Governance tab lets you set cost preferences separately for AWS, GCP, and Azure, also behind a feature flag.

The rest of this month's cost updates were accuracy and access fixes: anomaly filters no longer silently ignore a perspective that's been deleted, nodepool savings calculations now use the same cost basis as the monthly total instead of overstating savings, overview anomaly counts now include both resource-level and cost-category anomalies, only users with the right permission can edit or delete anomaly alerts, recommendation savings labels are localized to your preferred cost type, repeated commitment renewal events now collapse into a single indicator instead of a wall of icons, and filter messaging and recommendations navigation both got cleaned up. Full details are in the cost management release notes.

The developer portal gets better at knowing what you actually have

New integrations auto-discover and ingest entities from your existing tools, no manual YAML, no custom scripts. Unlike frontend-only plugins, this data feeds into scorecards, workflows, aggregation rules, and the knowledge graph itself.

Bitbucket Cloud entities in the catalog now show pull request history and commit activity right on the entity page, and Dynatrace entities show monitor and SLO data the same way, so developers get observability context without leaving the portal. More on that in the IDP release notes. 

Environment Management now shows a clear, current state for every environment, so platform engineers know what's actually happening without cross-referencing three other tools.

Infrastructure as code, managed like a real registry

Module Registry 2.0, in beta, lets teams publish IaC modules as immutable artifacts, auto-sync new versions on publish, and govern them with Supported, Warning, and Deprecated controls across project, org, and account scopes. Self-service, with guardrails, instead of a spreadsheet tracking who's on which version. Learn more about Module Registry.

Drift detection can now run on any schedule you set, and workspaces can be given a TTL so short-lived infrastructure, PR environments, and feature branches tears itself down automatically instead of quietly running up a cloud bill. Find more details on ephemeral workspaces.

Database changes that ship like code

Database DevOps now supports Harness Code Repository natively as a schema source, so teams no longer need a separate Git connector just to point at their own repo.

And Database DevOps can now authenticate to Amazon RDS and Aurora using AWS IAM through Harness's delegate, currently in beta and behind a feature flag, cutting down on credential management overhead and closing off a class of stored-secret risk.

Artifacts that clean up after themselves

Harness Artifact Registry now supports policy-based lifecycle rules that automatically delete or protect artifacts based on version count, age, or download activity. Administrators set the policy once instead of manually pruning old builds every quarter. Learn more in the Artifact Registry release notes.

Resilience testing before production finds the gap for you

Resilience Testing picked up Linux and Windows chaos experiment templates for the Chaos Step, audit trails with YAML diff visualization for the image registry, better probe timeout and retry handling, and the ability to copy output variables straight from the timeline view. Find the full list in the Chaos Engineering release notes.

Incident response that outpaces PagerDuty and OpsGenie

Escalation policies can now target a single rotation inside a schedule instead of paging every responder across it. If an incident belongs to "IT West Critical," only that rotation gets paged. Rotations, schedules, and users can all be mixed as targets across different levels of the same policy, so each escalation step reaches exactly the right people.

On-call configuration can now be imported by picking the exact services and groups you want, instead of pulling an entire account in one shot, and it works across PagerDuty, OpsGenie, and xMatters. That's a direct answer to the biggest complaint about migrating off those tools: an all-or-nothing import that forces a weekend cutover.

Runbooks can now be duplicated in one click, chain items, action configurations, and metadata all carried over intact, with the copy opening automatically so you can start tailoring it instead of rebuilding from scratch.

The pattern

None of these features exists in isolation. AI is compressing how fast code gets written, which means the pressure shows up everywhere downstream: builds need to start faster, tests need to generate themselves, security scanning needs to handle more volume without more false positives, and incident response needs to route the right alert to the right rotation the first time. Autonomous Worker Agents is the next turn of that same screw: instead of just helping teams keep up with AI-written code, Harness is now putting AI directly into the pipeline steps that ship, secure, and operate it. Sixty-two features in thirty days, plus a new agent platform on top, is what closing the velocity gap looks like in practice. We'll be back next month with more of it.

‍

Harness AI Security provides a unified control plane for AI discovery, risk visibility, and runtime protection, helping organizations operationalize key requirements of the EU AI Act. Instead of relying on manual audits or fragmented tooling, teams get continuous insight into how AI systems are built, exposed, and used, along with the evidence needed to demonstrate compliance.

By combining AI asset discovery, risk classification, data flow visibility, and runtime enforcement, Harness enables customers to proactively identify high-risk systems, prevent unsafe integrations, and continuously monitor AI behavior in production. This approach aligns directly with the EU AI Act's focus on transparency, traceability, and ongoing risk management.

Harness helps in the following areas of the EU AI Act

AI System Inventory

Harness automatically discovers all AI assets—AI APIs, Agents, MCP servers, MCP tools, resources, prompts, and AI backends by analyzing live network traffic. The centralized inventory provides a real-time breakdown of discovered assets by type, call volume trends, and sensitive data exposure across your environment. Security and compliance teams gain a single, continuously updated source of truth for every AI component in use, without requiring manual cataloging or developer-submitted forms.

Risk Identification & Classification (Article 6)

Once assets are discovered, Harness derives a risk score for each based on policy violations, known vulnerabilities, exposure level (internal vs. external), and sensitive data flow. This scoring helps teams prioritize remediation efforts and demonstrate that high-risk AI systems have been identified and assessed, which is a core expectation under the EU AI Act's risk-based framework.

Prohibited Use Cases (Article 5)

Harness detects shadow AI vendors, unapproved MCP servers, and undocumented AI APIs surfacing in your environment. The Third Party view surfaces AI APIs grouped by vendor (e.g., OpenAI, Google, Anthropic) so teams can identify integrations that haven't undergone procurement or security review. This is directly relevant to the EU AI Act's prohibition on certain AI use cases and its requirements around supply chain transparency for AI systems.

Data Governance & Quality (Article 10)

Harness monitors sensitive data flows across all discovered AI assets, identifying where PII and regulated data enters and exits AI systems. The platform classifies data sensitivity automatically by analyzing asset metadata and observed traffic patterns, giving teams a continuous view of which assets handle sensitive information and surfacing misuse risks before they become compliance incidents.

Technical Documentation & Auditability (Articles 11, 16)

Harness automatically generates schemas for AI APIs, MCP tools, resources, and prompts by analyzing real network traffic with no manual documentation effort required. Each asset detail page captures the asset's type, dependencies, call volume, risk posture, and data flows in one place. This detail provides compliance teams with the structured technical records required under Articles 11 and 16 without burdening engineering teams with additional documentation.

Logging & Traceability (Article 12)

Harness captures all AI interactions, including AI API calls, MCP tool invocations, database calls, and non-AI API calls, in a centralized data lake with seven-day standard retention and 30-day retention for threat activity. This complete, queryable record of AI system behavior supports both routine audit needs and forensic investigations, directly satisfying Article 12's requirements for logging and traceability of high-risk AI systems.

Accuracy, Robustness & Security (Article 9)

The AI Firewall (beta) provides runtime enforcement against the most common AI-layer threats: prompt injection attacks, PII leakage in model responses, excessive model usage, and unauthorized model access. Together, these controls address the robustness and security requirements of Article 9, helping organizations demonstrate that their AI systems have active protections in place rather than passive policies.

Post-Market Monitoring (Article 72)

Harness continuously discovers new AI assets, shadow AI usage, and emerging sensitive data risks in production as your environment evolves. Real-time alerts are triggered for new vulnerabilities and compliance violations, with native integrations into SOC/SIEM workflows for rapid response. This ongoing monitoring capability aligns directly with the EU AI Act's post-market surveillance requirements, ensuring compliance doesn't end at deployment.

Bottom line: Harness AI Security provides the visibility, controls, and audit evidence layer required to operationalize EU AI Act compliance at scale and oversee AI system security. (Article 14)

AI is writing more of the code. Software delivery, the work between writing code and running it in production, is where most of the day still goes. Building, testing, scanning, deploying, remediating, and operating still require the same, if not more, effort as before AI. 

Today, we're introducing Autonomous Worker Agents for software delivery: the platform for enterprises to build and safely run AI agents that handle the work between writing code and shipping it to production. 

Autonomous Worker Agents execute as pipeline steps and produce auditable outputs. Their memory is the organization: services, pipelines, deployments, incidents, policies, all connected through the Harness Knowledge Graph, and their capability is powered by the Harness MCP. They operate in production and support the deployment, security, remediation, and validation of your code.

They join Harness Expert Agents, which have been available to customers for some time, to form a complete AI layer across the platform.

Each agent runs as a step inside a Harness pipeline, on customer-controlled infrastructure, with full governance: scoped credentials, OPA policy enforcement, approval gates, and complete audit trails.

Safe to Run in Production

Autonomous Worker Agents are invoked as pipeline steps or independently. They inherit the governance Harness pipelines already provide. Instead of trying to teach an AI agent a massive list of corporate rules, the agent operates entirely within the constraints of your existing software delivery pipelines.

• OPA Policies that gate production deployments gate the agents.
• RBAC that controls who can push to production controls who can trigger an agent.
• Approval Gates apply before an agent's fix ships, just as they do before any release.

Safety is architected in as well. Workloads execute on Harness Delegates, lightweight runtimes installed inside the customer's own Kubernetes cluster or VPC. An agent that "shouldn't be able to merge to main" cannot merge to main, even if its prompt asks it to. The architecture enforces it.

‍

We built RiskSentinel, a Harness Autonomous Worker Agent, to demonstrate that governed AI can move beyond identifying security issues to safely remediate them while maintaining enterprise controls, auditability, and compliance. When building with Harness, what stood out most was how intuitive the experience was — it enabled our team to move from an initial idea to a production-ready agent in just four days, allowing us to focus on solving a real enterprise challenge rather than the underlying platform. That combination of developer experience and enterprise-ready capabilities is what will enable organizations to confidently scale AI across software delivery.
‍- Ratna Devarapalli, Director IT, United Airlines

Six additional controls make Autonomous Worker Agents production-safe.

1. Sandboxing

Agents are run containerized, with non-root execution (UID 65534, "nobody"). Their filesystem is read-only except for the workspace. Network access is configurable per agent: unrestricted, restricted to allowed MCP servers, or fully disabled.

An agent that produces a malicious bash command has nowhere to send the data.

2. Scoped Credentials

When a pipeline triggers, Harness mints an ephemeral scoped token. Its scope is the intersection of the agent's permissions and the triggering user's RBAC.

Token deletes on completion. TTL as a failsafe. MongoDB TTL index as final backstop.

3. Policy Enforcement

OPA policies, the same framework Harness customers use to govern deployments, apply to agents. Policies govern the agent at runtime and during configuration. 

4. Audit Trails

Every execution is captured in the Harness Audit Trail. This includes a full provenance chain: who or what triggered the agent, template version, every action taken, and final outcome.

Prompts and reasoning chains are sanitized before persistence: secrets stripped, and PII is stripped.

5. Cost Tracking

Token consumption and costs are surfaced per execution, per agent, and per pipeline. Running totals are shown live in the step header.

6. Chaining

Agents are architected to run within pipelines and can be naturally composed into multi-step workflows.

• Sequential: Agent B consumes Agent A's output.
• Parallel: agents run simultaneously.
• Conditional: an agent runs only if a previous step meets a condition.
• Matrix: same agent across repos, environments, or services.

Output handoff happens via pipeline expressions and shared workspace files.

Three ways to create an agent

Using YAML

A Worker Agent is defined in a single file. Here's a complete agent that reviews every pull request for security issues:

agent:
   group:
     steps:
       - name: Run Code Coverage Agent
         id: runCodeCoverageAgent
         if: <+Always>
         run:
           container:
             image: pkg.harness.io/vrvdt5ius7uwygso8s0bia/harness-agents/harness-ai-agent:latest
           env:yam
             ANTHROPIC_MODEL: ${{inputs.model_name}}
             PLUGIN_HARNESS_CONNECTOR: ${{inputs.llm_connector.id}}
             PLUGIN_MAX_TURNS: "150"
             PLUGIN_MCP_FORMAT: harness
             PLUGIN_MCP_SERVERS: <+connectorInputs.resolveList(<+inputs.mcp_connectors>)>
             PLUGIN_TASK: |
               Autonomous Harness Code Coverage Agent; no prompts. Resolve branch/repo/clone_url/account/org/project/execution strictly: input -> env -> MCP, never guess; branch must exist via SCM MCP or fail.
               Use /harness first, else $HARNESS_WORKSPACE; if repo missing, clone (SCM MCP preferred, git fallback) and checkout resolved branch.
               Detect language/test/coverage stack, run baseline coverage (overall + per-file), and target >=90% overall and >=80% per-file.
               Add meaningful tests for critical uncovered paths (happy/edge/error/boundary); allow only minimal production testability tweaks.
               Re-run full tests + coverage + lint + build; all must pass before continuing.
               Review full diff (SCM MCP preferred, git diff fallback); allow only tests + minimal testability tweaks (+ COVERAGE.md only if it already exists; never create it).
               Build report with overall before->after, per-file before/after for touched files, and key improvements.
               Stage files one-by-one only; never use git add -A or git add .; verify staged diff is clean and in-scope.
               Create exactly one commit: "Code coverage: automated test additions by Harness AI"; push plain to origin <branch> (no pull/rebase/merge/force).
               If push fails, print rejection, git reset --hard HEAD~1, exit non-zero; never commit unrelated changes, never weaken existing tests, never log secrets.

YAML frontmatter on top. Natural language below ---. The same convention Jekyll, Hugo, and AI agent definitions across the industry use.

Save the file, commit it to the repo, and the agent is live, governed, and in the catalog. Every PR triggers it. Every run is audited. Every action is scoped by RBAC. From a blank file to a live governed agent in minutes.

The Harness pipeline engine handles container runtime, scoped credentials, MCP server integration, audit logging, and cost tracking.

Using the UI

The Harness Agent Builder is a simple form for configuring your Agents. Define your prompts in plain English, referencing Harness constructs through common expressions. This experience makes it easy to see what you need to provide and set up your agent in minutes.

All agent definitions are stored in Harness. Their reference in pipelines can be managed in Git. Approval gates apply. Pipeline Branch-based versions let teams test new agent behavior in feature branches before merging to main.

"We built an agent that handles log analysis directly inside Harness. No tool switching, no context loss. The ability to stay on one platform and have the agent surface what's happening and review it for us was the biggest immediate win. We're planning to use it in production."
- Mandy Pearce, Senior Engineer, Cloud Automation, Verint

Create with MCP

Using your favorite coding agent, you can connect to Harness over the MCP. The MCP bridges the AI Coding agents’ inner-loop context and the outer-loop context and the constructs in Harness. 

Agents as Pipeline Steps

Most software delivery workflows have more than one step. Autonomous Worker Agents compose with shell scripts, plugins, approval gates, and other agents to make full pipelines.

Referencing an Agent in a Pipeline

pipeline:
 stages:
   - steps:
       - name: Feature Agent
         template:
           uses: ca_feature_triage_agent@1.0.2
       - name: Plan Agent
         template:
           uses: ca_work_planning_agent@1.0.2
       - name: Build Feature Agent
         template:
           uses: ca_builder_agent@1.0.2

uses: references a Worker Agent template by name and version. The agent runs as one step alongside everything else a Harness pipeline can run.

Sequential: Output Handoff

Agent B consumes Agent A's output. The pipeline expression ${{ steps.<agent_id>.output }} carries the result forward.

pipeline:
 stages:
   - steps:
       - name: spec design
         parallel:
           steps:
             - name: Feature Agent
               template:
               uses: ca_feature_triage_agent@1.0.2
             - name: PR Body
               template:
                 uses: pr_body_writer
                 with:
                   artifactPath: ${{featureagent.output.artifact}}
                   issueKey: cds-1234

Parallel

Multiple agents run simultaneously:

 parallel:
           steps:
             - name: Feature Agent
               template:
                 uses: ca_feature_triage_agent@1.0.2
             - name: PR Body
               template:
                 uses: pr_body_writer
                 with:
                   artifactPath: ${{featureagent.output.artifact}}
                   issueKey: cds-1234

Step Groups

A Step Group bundles agents and deterministic steps into a single reusable unit:

         group:
           steps:
             - name: feature anaylzer
               template:
                 uses: feature_ingester_agent@1.0.2
             - name: work planner
               template:
                 uses: ca_work_planning_agent@1.0.4

Save the group as a template. Reference it from any pipeline. The PR Autofix workflow ships as a Step Group template.

Conditional and Matrix

An agent runs only when a condition is met:

  - steps:
         group:
           steps:
             - name: feature ingest
               template:
                 uses: feature_ingester_agent
             - name: work planner
               template:
                 uses: ca_work_planning_agent
     name: Spec Driven Development
     if: <+OnPipelineSuccess>

The same agent runs across multiple targets:

             - name: work planner
               template:
                 uses: ca_work_planning_agent
               strategy:
                 fail-fast: true
                 for:
                   iterations: 3

Approval gates, failure strategies, retry policies, and rollback work the same way they do for any other pipeline step.

‍

Introducing the Harness Agent Marketplace

The Harness Agent Marketplace is where teams discover, install, fork, customize, and publish Autonomous Worker Agents.

Three publisher tiers anchor it:

• Harness Managed: Built and maintained by Harness. SLA-backed. Versioned. Pinnable (e.g., harness.autofix@1.2).
• Harness Certified: Partner-built. Reviewed and certified by Harness engineering and security. Examples: dependency vendors with their own scanning agents, cloud providers with cloud-specific deployment agents.
• Community: Published by the broader Harness community. Validated for schema, no secrets in prompt. Enterprise accounts can restrict via OPA policy. Allow only Managed and Certified in production, for instance.

Harness Managed Agents

With today’s launch, Harness has pre-built agents for the most requested use cases. Here are some examples of what’s currently available: 

CI Autofix

Reads build logs from a failed PR build, identifies the root cause, commits a fix to the PR branch, re-triggers the build, and repeats until the build passes or the configured max-turns limit is reached.

Manifest Remediator

Analyzes failed Kubernetes deployments. Identifies whether the issue is the manifest, the cluster, or the workload. Fixes manifest issues. Used by teams managing dozens of services across multiple clusters.

Code Review

Reviews PR diffs across security, quality, and test coverage. Outputs structured findings with severity ratings and concrete remediation. Grounded in the Harness Knowledge Graph, the agent knows which services are production-critical, which have had recent incidents, and which historical anti-patterns have caused outages.

Feature Flag Cleanup

Reads code, config, and flag-system state to identify feature flags that are fully rolled out or fully off. Once it validates removal is safe, the agent generates a cleanup PR. With this agent, the status of your experiments automatically informs you when flags are cleaned up, reducing flag debt and the drudgery of cleaning up old flags.

Code Coverage

Reads coverage reports, identifies untested lines, branches, and functions, and generates tests to close gaps. Used when a team has inherited a codebase with weak coverage and needs to lift it before a release.

IaCM Remediation

Fixes configuration drift, security findings, and cloud cost issues by editing infrastructure configurations.

‍

Bring Your Own Model

Autonomous Worker Agents are model-agnostic. Connect LLM providers through Harness connectors:

• OpenAI: Direct to Provider
• Anthropic: AWS Bedrock, Direct to Provider 

The model can be specified at three levels: in the agent template, at the pipeline step level (overriding the template), or at the account level via environment variable defaults. Switch models per agent, per environment, or per pipeline without changing agent logic.

Three reasons this matters:

1. Cost. Different models have different price points. Routing high-volume work through cheaper models is a common pattern.
2. Compliance. Some teams require AWS-routed Bedrock for billing consolidation, VPC routing, or Bedrock-specific compliance attestations.
3. Future-proofing. Model leaders change. The enterprise decides which model today, which model tomorrow.

Getting Started

Autonomous Worker Agents are available today for all Harness customers. Learn more about Harness Autonomous Worker Agents or request a demo to see them in production.

Visit the in-app Harness Marketplace in app to try out any of the Worker Agents. Add it to your pipeline and watch it run. 

Federal agencies need more than a modernization tool, – they need an “automated” early warning software delivery system. The Canary Partner Program is how Harness and its partners deliver one.

‍

Miners carried canaries underground for one reason: early warning. The moment the canary went silent, you knew something was wrong before it was too late to act. That’s exactly what’s been missing from federal software delivery — and exactly what the Harness Canary Partner Program is built to provide.

Across the Department of Defense, Civilian Agencies, and the Intelligence Community, we keep hearing the same thing: harness AI, harness automation, prioritize governance and security. Agencies aren’t just modernizing,  they’re racing to get ahead of risk before it surfaces in production, before it shows up in an audit, and before it becomes a breach. 

Today, we’re opening the Canary Partner Program to federal-focused partners who can help them do that.

‍

Why federal, and why now

Federal IT modernization is accelerating. Agencies aren't asking whether to modernize their software delivery anymore. They're asking how, and they're asking fast. The Administration's AI and cloud-first directives, RMF framework requirements, zero trust mandates, continuous ATO expectations, are all all of it is landing at once. We intend to be the platform agencies depend on, and the Canary Partner Program is how we scale that across the federal ecosystem.

We're already seeing it firsthand. Harness is deployed across federal civilian and defense agencies, where teams are reducing deployment lead times, increasing release frequency, and enforcing security policies at scale. The demand is growing faster than our direct team can serve alone, and that's exactly why we built this program.

‍

What the Canary Partner Program actually looks like

The Canary Partner Program is built around a co-sell motion that puts Harness resources behind partners from the first opportunity. Unlike traditional tiered partner models with steep upfront certification requirements and a long runway before seeing any return, partners work alongside our federal sales, solutions engineering, and professional services teams from day one, — whether they're a government-focused reseller, systems integrator, or consulting firm looking to grow their federal practice. The engagement model is flexible: co-sell, resell, or managed services, based on what each opportunity calls for.

What partners get access to:

• A self-service partner portal with role-based training for sales, presales, and implementation
• Environments and federal compliance resources aligned to FedRAMP, NIST, RMF, and Zero Trust frameworks
• Deal registration protections and competitive incentives that reward both partner-sourced and partner-influenced pipeline
• Co-marketing resources, federal campaign kits and joint go-to-market support across civilian, defense, and intelligence communities

The enablement is built around the full chain of custody that agencies are increasingly requiring partners to demonstrate: code to artifact to deploy to runtime, with traceability at every step.

‍

Come join us on this mission

The Harness Canary Partner Program is open now, and this is just the start. We have more federal news coming, and the partners who are in early will be best positioned to move with us as the program grows. If you're ready to build something that lasts in the federal market, we'd like to do it together.

Reach out or apply at www.harness.io/partners.

‍

AI coding security risks emerge the moment your assistant suggests `npm install suspicious-package` and your team accepts without question. In production environments, AI-generated code recommendations bypass traditional review workflows, introducing vulnerable dependencies at a pace human oversight cannot match. One accepted suggestion can pull in dozens of transitive dependencies, each a potential supply chain entry point.

This is not about slowing developers down. It is about giving platform and security teams a scalable control point while developers keep moving fast.

‍

How AI Assistants Accelerate Dependency Risk

AI coding tools operate on pattern recognition trained across millions of public repositories. When a developer asks for authentication logic, the assistant suggests popular packages based on usage frequency, not security posture. The tool has no visibility into CVE databases, package maintainer history, or recent compromise patterns. It recommends what worked statistically, not what remains safe operationally.

This creates volume problems traditional security gates cannot address. A team of ten engineers using AI assistance can introduce 50 new external dependencies per sprint. Manual security review of each package, its maintainers, and its transitive tree becomes a bottleneck that development velocity simply routes around. The dependencies enter `package.json`, pass CI checks that only verify build success, and deploy to production before anyone evaluates supply chain risk.

‍

The npm Supply Chain Attack Surface

Recent npm ecosystem compromises demonstrate how attackers exploit this acceleration. Package maintainers get compromised through credential theft or social engineering. Attackers publish malicious updates to widely-used packages. AI assistants continue recommending these packages based on historical popularity metrics. Development teams install them automatically as part of normal workflow.

The May 2026 TanStack supply chain attack illustrates the current threat landscape. Attackers published malicious npm packages impersonating TanStack libraries, targeting developer credentials, secrets, and CI/CD-related access tokens. Because TanStack packages are widely used across React ecosystems, AI coding assistants readily suggested these typosquatted variants based on name similarity and perceived popularity. Teams relying on AI suggestions without registry-level controls had no automated way to prevent these packages from entering their dependency trees. The attack specifically exploited the trust developers place in AI-generated recommendations, harvesting credentials that could enable deeper supply chain compromise.

The older ‘event-stream’ incident followed a similar pattern. A legitimate package with millions of weekly downloads received a malicious update that harvested cryptocurrency wallet credentials. The compromise remained undetected for weeks because the package maintained its reputation score and continued appearing in AI-generated suggestions.

‍

Why Traditional Security Checks Miss AI-Introduced Dependencies

Standard vulnerability scanning happens too late in the development lifecycle. Most teams run security checks after code reaches staging or pre-production environments. By this point, vulnerable dependencies have already integrated into application logic, created transitive dependency chains, and potentially exposed sensitive data in development environments.

SCA Tells You What Risk Exists. Dependency Firewalls Stop It From Entering.

This is the critical distinction. Software Composition Analysis (SCA) tools scan your codebase and report which vulnerable packages you already have. They are reactive: they tell you about risk after it exists in your environment. Dependency firewalls are preventive: they stop risky packages at the registry boundary before they ever reach your codebase, builds, or pipelines.

SCA scanning remains valuable for ongoing visibility. But when AI coding tools introduce dependencies at high velocity, you need a control that operates before installation, not after. The registry boundary is that control point.

Static analysis tools detect known CVEs but miss zero-day vulnerabilities and recently compromised packages. The gap between package compromise and CVE publication creates a window where AI assistants continue recommending dangerous dependencies while security databases report clean status. Teams operating on daily or weekly vulnerability scan schedules remain exposed to supply chain attacks that evolve hourly.

License compliance presents another blind spot. AI coding tools suggest packages based on functionality, not licensing terms. A developer receives a suggestion for an AGPL-licensed package when building a proprietary commercial application. The licensing conflict only surfaces months later during audit preparation, requiring expensive refactoring or license negotiation.

The Speed-Versus-Security Tension

Development teams adopt AI assistance specifically for velocity gains. Asking developers to manually verify every AI-suggested dependency contradicts the efficiency goal that justified the AI tool investment. This creates a cultural pressure where security verification becomes the exception rather than the rule.

‍

Why the Registry Boundary Is the Natural Control Point

The upstream proxy is where external dependencies enter your organization. Every npm install, pip install, or maven dependency resolution that reaches out to a public registry passes through this layer. This makes it the natural enforcement point for open-source governance.

Think of it the same way you think about network firewalls. You do not let arbitrary external traffic into your internal network without evaluation. The same logic applies to software packages. The upstream proxy fetches and caches artifacts from external registries, so placing policy evaluation at this layer means every external package gets assessed before it becomes available to any developer, any build, or any pipeline in your organization.

A dependency firewall at the registry boundary evaluates external packages before they enter your organization's artifact ecosystem. Rather than scanning for vulnerabilities after installation, it blocks retrieval of packages that fail security, compliance, or policy checks. When a developer or AI assistant attempts to install a package, the request routes through the firewall, which evaluates:

- Known vulnerabilities: CVSS severity scores checked against your defined threshold.

- Package age and stability: Newly published packages can be flagged or blocked.

- License compatibility: Alignment with organizational compliance requirements.

- Custom policy rules: Organization-specific policies written in Rego for nuanced control.

- Transitive dependency risk: Security posture of the complete dependency tree.

Packages that fail evaluation are not cached and are not available for download. Developers receive immediate feedback about why the package was blocked. This shifts security decisions from post-integration remediation to pre-installation prevention.

‍

How Harness Artifact Registry Implements Dependency Governance

Harness Artifact Registry implements dependency firewall capabilities as part of its upstream proxy architecture. When configured as your primary package source, it evaluates external dependencies against configurable policies before caching them for internal use.      

The Flow

Here is how it works in practice:

‍

- **Blocked** versions are not cached and are not available for download. The install fails with a clear policy violation message.

- **Warning** versions are cached and available for download, but flagged for visibility. Teams can review warnings on the dashboard and decide whether to tighten policy.

- **Passed** versions are cached normally and available without restriction.

Policy Configuration

The platform supports configurable policy sets that you apply to your upstream proxy registries:

•  CVSS severity threshold: Block packages with known vulnerabilities above your defined severity level (e.g., block all Critical and High CVEs).
• License policy: Block or warn on packages with specific license types (GPL, AGPL, or any license incompatible with your distribution model).
• Package age policy: Flag or block packages published within a configurable window (e.g., packages less than 30 days old receive a warning).
• Custom Rego policies:Write organization-specific rules for nuanced evaluation logic that goes beyond built-in checks.

Policy sets group-related rules and can be applied across multiple registries. This means security rules defined once apply consistently, whether developers are pulling JavaScript packages, Java libraries, or container images. For a deeper look at how this fits into a unified artifact management strategy, Harness AR handles the full lifecycle from ingestion to deployment.

Visibility and Governance

The Dependency Firewall dashboard provides visibility into policy evaluations, showing which packages were blocked, which received warnings, and which passed. This supports both incident response and continuous policy refinement based on actual development patterns.

Integration with CI/CD pipelines ensures build environments use the same controlled package sources as local development. A package that passes firewall evaluation in development remains available in CI without re-fetching from public registries. This consistency eliminates scenarios where local and build environments reference different package versions or bypass controls.

For organizations managing multiple package formats (npm, Maven, Docker, Helm), Harness AR provides unified policy management across registries, reducing policy management overhead while maintaining comprehensive supply chain governance.

Operational Implementation

Initial firewall deployment involves cataloging currently used dependencies and establishing baseline policies. Most organizations start with blocking known high-severity CVEs and expand policy coverage incrementally. This prevents disrupting existing workflows while building the approved package catalog that development teams and AI tools can safely reference.

Learn more about Harness Artifact Registry for more information about implementing these controls.

‍

Building Sustainable AI-Assisted Development Workflows

Dependency firewalls enable rather than restrict AI coding tool adoption. When developers know that package suggestions route through security evaluation, they can accept AI recommendations with appropriate confidence. The firewall handles security verification automatically, removing the burden of manual package vetting from development workflows.

This creates a sustainable balance between velocity and governance. AI assistants continue accelerating development by suggesting relevant packages. The dependency firewall ensures those suggestions meet organizational security standards before integration. Development teams focus on building features while platform teams maintain supply chain integrity through policy rather than through manual review queues.

Organizations implementing dependency firewalls report faster incident response when supply chain compromises occur. Instead of searching codebases for usage of a newly compromised package, firewall logs immediately identify which projects requested it and whether the request was approved. Remediation becomes targeted rather than organization-wide.

The investment in dependency firewall infrastructure pays forward as AI coding tools become more capable. Future assistants generating entire microservices will introduce even more dependencies even faster. The control point established now scales to handle that acceleration without requiring fundamental workflow changes or security architecture redesign.

If AI is accelerating how your teams write code, Harness Artifact Registry helps ensure the dependencies entering that code are governed before they reach builds, pipelines, or production. The registry boundary is where supply chain security starts.

Key takeaway: The Harness MCP Server now connects directly inside Google Antigravity. Developers can link Harness in under two minutes and give the agent structured, real-time access to their pipelines, execution history, services, environments, and policies, without leaving the editor. What makes it reliable isn't the connection itself. It's the Harness Software Delivery Knowledge Graph underneath, which gives the agent the context to act accurately, fast, and within your guardrails.

‍

AI has made the inner loop faster than ever. Inside Antigravity, you can write, refactor, and test code in seconds. But the moment a change needs to be built, deployed, or debugged in production, you leave the editor entirely, back to juggling pipelines, approvals, scan results, and failed runs across a half-dozen browser tabs. That gap between fast code and slow delivery is the part AI hasn't fixed yet.

The Harness MCP integration closes that gap. Connect once, and Antigravity gains direct access to your Harness delivery environment. The agent now understands your delivery system the same way it understands your codebase. So you can ask it to list pipelines, explain a failure, or trigger a deployment, and it acts on live Harness context instead of generic knowledge.

Connect Antigravity to Harness in a Few Steps

There's no YAML to write and no manual server config. You generate a Personal Access Token in Harness, open Antigravity's Customizations panel, add the Harness MCP server, and paste the token. That's the entire setup.

1. Generate a PAT. In Harness, go to Account Settings → Personal Access Tokens and scope the token to the org, project, and pipelines you want the agent to reach.
2. Open Customizations. In Antigravity, go to Settings → Customizations to configure default behaviors, skills, and MCP server connections.
3. Add the Harness MCP server. Click + MCP Servers, search Harness, select it, and paste your PAT.
4. Start building. The agent now operates with your Harness account, org, and project context. Describe what you need and it acts on real pipeline and execution data.

Settings → Customizations → Add MCP Servers, search “Harness,” connect, done.

All The Software Delivery Use Cases Within Antigravity

Once Harness is connected, you interact with your delivery system the same way you interact with your code, in plain language, from the same window.

Ask it what's in your delivery environment

Start simple: "Can you list pipelines in <Your Project> project in the default org in my Harness account?" The agent resolves the project identifier, pages through every pipeline, and returns a structured report (names, identifiers, creation times, descriptions, and tags) with links straight back to the Harness UI.

‍

Drill into execution history

From there, ask about recent activity: "List out my recent executions in this project." The agent reads the execution history, converts raw timestamps and durations into something readable, and lays out every run, including the one that came back ApprovalRejected, so you can see exactly what happened and when.

‍

Triggering a deployment, with a human in the loop

This is where most "AI in delivery" stories get nervous, and where the design matters most. When you ask the agent to run something, it doesn't just act. It shows you the exact tool it wants to call and the arguments it will send, then waits for your approval.

‍

Approve it, and the run goes through. The agent triggers the pipeline using the Harness run action and returns the live execution (pipeline ID, status, trigger type, and a link to the execution in Harness), so you can follow it from the same chat.

‍

This Is Not AI Without Guardrails

The natural question, once an agent can trigger pipelines, what stops it from doing something it shouldn't? The same controls that govern everything else in Harness.

Why Context Beats Raw API Access

MCP lets a model call external tools by reading API descriptions and deciding which to invoke. That flexibility is useful, but when an agent needs to reason across an entire delivery lifecycle (CI, CD, security scans, approvals, environments, cost signals), raw API access creates a reliability problem. The agent has to discover which endpoints exist, call them in the right order, paginate correctly, and infer how fields relate across systems. Every inferred join is a place to guess. Guessing is where hallucinations happen.

The Harness Software Delivery Knowledge Graph removes the guesswork. It's a purpose-built model of everything that happens after code is written (builds, test runs, deployments, approvals, scans, environment states, feature flags, infrastructure changes, cost signals, and rollbacks) represented as a connected, typed, semantically annotated graph. Every field carries metadata telling the agent how to use it, and relationships between entities are explicitly declared, not inferred.

This is the difference between an agent that can access your delivery system and one that understands it.

When Antigravity connects to Harness via MCP, it isn't handed a list of endpoints. It gets a structured model of your delivery organization, where relationships are known, data types are enforced, and the agent can construct precise queries rather than guessing at field semantics. The same controls apply structurally, too: an approval gate isn't an optional step the agent might skip; it's a typed relationship with state. The agent can't promote past a gate that hasn't cleared, because the graph reflects that clearly. Speed and governance aren't a tradeoff; they coexist by design.

Software Delivery Context At Your Fingertips

If you're already a Harness customer, you're a couple of minutes away from having the software delivery control in Antigravity. New to Harness? Sign up for free and connect from day one. For enterprise onboarding and design-partner access, contact your Harness account team.

The Harness connection gives the agent the ability to act in your delivery system. The Knowledge Graph gives it the understanding to act well. Together, that's what reliable AI in software delivery actually looks like, now available wherever you build, including inside Antigravity.

‍

When a CI pipeline runs on cloud infrastructure, the build machine is ephemeral. It spins up, executes your build, and disappears. During that window, you have zero visibility into how much CPU and memory your pipeline actually consumes.

This blind spot creates real problems. Teams over-provision VMs "just in case," wasting compute spend. Others under-provision and deal with silent OOM-kills or CPU throttling — the only clue being a cryptic exit code 137. Without historical resource profiles, there's no data-driven way to right-size pipelines or catch regressions introduced by dependency upgrades.

We built CPU and Memory Insights to solve this. It gives you real-time and historical visibility into resource consumption during every Harness CI Cloud build — with zero configuration and zero impact on build performance.

Why Resource Visibility Matters

Consider a typical scenario: your build takes 12 minutes on a Large machine (4 vCPU, 8GB RAM). Is it CPU-bound during compilation? Memory-bound during docker build? Or is it I/O-bound pulling dependencies? Without metrics, you're guessing.

With CPU and Memory Insights, you can:

• Right-size your machines — see that a "Large" build peaks at 30% CPU and safely downgrade to "Medium," cutting your cloud spend.
• Debug failures faster — watch the memory ramp leading to an OOM kill and pinpoint which step caused it.
• Detect regressions — compare P90 CPU across builds to catch when a dependency update made things worse.

How It Works

The system collects resource metrics from inside the ephemeral VM, streams them in real-time to the Harness platform, and renders interactive charts in the execution view.

Architecture

Harness CI Cloud uses a multi-layered architecture for pipeline execution. The metrics flow is overlaid on the same path used for build orchestration:

The key insight: lite-engine is the only component running inside the VM — it's the only one with access to actual resource utilization. But it has no persistent storage. Everything must be streamed out before the VM is destroyed.

Data Collection

When a VM is provisioned for your build, lite-engine starts a background process that samples system metrics every second:

• CPU utilization — aggregate percentage across all cores
• Memory usage — total and available, in GB
• Disk I/O — read and write throughput in bytes/sec

Each sample is written as a single JSON line (NDJSON format) to the Harness Log Service using a dedicated stream key. This is the same battle-tested infrastructure that powers step-level log streaming — we reuse its real-time SSE transport, blob storage, and access control. No new infrastructure needed.

Real-Time Streaming

The metrics stream opens during VM setup and closes during VM destroy, giving continuous coverage regardless of how many steps run or fail in between. The stream is independent of step execution — there are no gaps between steps.

During execution, the UI connects via Server-Sent Events (SSE) to receive metrics as they're collected. For completed builds, the same data is available from blob storage. The UI handles both transparently — same visualization whether you're watching a live build or reviewing a historical one.

Summary Statistics

When the VM is destroyed, lite-engine computes a final summary before closing the stream:

• Peak CPU — maximum utilization observed
• Average CPU — mean utilization across the entire stage
• P90 CPU — 90th percentile utilization (useful for right-sizing decisions)
• Total Disk I/O — cumulative bytes read and written

The frontend also computes P50, P90, P95, and P99 percentiles client-side, which means you get full statistics even for in-progress executions.

What You See in the UI

Click the resource indicator button in the execution view (it shows your platform and size, e.g., "Linux (Large)"). A drawer opens with three charts:

CPU Usage

An area chart showing utilization percentage over time, with a P90 reference line. The stats bar shows total cores, peak utilization, average, and percentiles (P50/P90/P95/P99).

Memory Usage

An area chart with dual Y-axes: percentage on the left, GB on the right. Helps you understand both relative and absolute consumption at a glance.

Disk I/O

A line chart showing read and write throughput in MB/s. Useful for identifying I/O-bound steps like image pulls or large file operations.

A stage selector dropdown at the top lets you switch between stages in multi-stage pipelines.

Cross-Platform Support

CPU and Memory Insights works across all Harness Cloud infrastructure:

layer normalizes platform-specific differences. Whether the underlying OS reports per-core or aggregate CPU, or uses different disk I/O naming conventions, the metrics are always presented consistently: aggregate CPU as a single percentage, memory in GB, and disk throughput as a delta rate.

Performance Impact

Resource collection runs with negligible overhead:

For long-running builds, the frontend intelligently downsamples to 120 data points for chart rendering while preserving visual accuracy — peaks and valleys are maintained using the LTTB (Largest-Triangle-Three-Buckets) algorithm.

Reliability

Builds can end in many ways: graceful completion, timeout, infrastructure failure, or force-kill. We handle all of them:

• Happy path: lite-engine writes the summary and closes the stream on VM destroy.
• Crash path: The platform-level cleanup phase independently closes the metrics stream if lite-engine didn't. This runs regardless of how the VM terminated.

This dual-closure approach ensures metrics data is never orphaned — you always get at least the raw timeline, even if the summary couldn't be computed.

What's Next

We're continuing to invest in resource intelligence for CI builds:

• Step-level attribution — correlating resource spikes with specific pipeline steps to pinpoint exactly which step is expensive.
• Automated right-sizing recommendations — using historical P90 data to suggest optimal machine sizes for your pipelines.
• Resource threshold alerts — notifying you when builds consistently approach memory limits, before they OOM-kill.
• Build-over-build comparison — overlaying metrics from the current build against previous runs to visualize the resource impact of code changes.

Get Started

CPU and Memory Insights is enabled by default for all pipelines running on Harness CI Cloud no setup required.

To explore the feature:

• Open any pipeline execution running on a Harness Cloud machine.
• Click the resource indicator in the stage execution header (for example, Linux (Large)).
• Open the insights drawer to view real-time and historical CPU and memory usage for your build.

No YAML changes. No additional agents. No configuration needed.

Use this visibility to quickly identify resource bottlenecks, right-size your build infrastructure, and improve overall CI efficiency.

Ready to optimize your builds? Try it in your next pipeline run or learn more in the Harness CI documentation.

Your Harness pipelines, logs, and deployment approvals are now a sidebar panel away inside VS Code.

The Harness VS Code Extension is live on the VS Code Marketplace today, no .vsix download, no manual install. Search "Harness" in the Extensions view, and you're a click away from real-time CI/CD visibility without leaving your editor.

Everything Software Delivery in One Panel

Ask Your AI. It Already Has the Context.

When a pipeline fails, the default loop is: open Harness UI, find the execution, read the logs, copy the relevant output, open your AI assistant, paste, and ask. That's four context switches before you've started fixing anything.

The extension collapses that into one step. An input sits at the bottom of the Harness panel. Type your question, select Claude Code, GitHub Copilot, or Cursor from the dropdown, and the extension packages the current execution context automatically before sending.

‍

‍

What makes the context useful, not just present, is the Harness Software Delivery Knowledge Graph. The Knowledge Graph is a structured data model that connects every entity across your SDLC: pipelines, services, deployments, environments, artifacts, policy results, and more. When the extension sends your AI tool the execution context for a failing pipeline, it's pulling from that graph. So Claude Code, Copilot, or Cursor isn't just reading a raw log dump. It's receiving structured, relationship-aware data about what ran, what it depends on, and where it broke. That's the difference between an AI that can technically answer a question about your pipeline and one that can accurately answer it.

‍Claude Code responses appear directly in the Harness sidebar (CLI mode) or open the Claude Code panel with the prompt pre-loaded (extension mode). Click Configure MCP in the AI footer to wire up your Harness credentials: project scope or global, your choice.

‍GitHub Copilot is auto-detected when the extension is installed. Context and prompt open in Copilot Chat, ready to go.

‍Cursor is auto-detected when you're running inside Cursor. For the simplest setup, install the Harness plugin from the Cursor marketplace. OAuth authentication, no manual configuration.

Install in Two Minutes

Install:

Open the Extensions view (Ctrl+Shift+X), search "Harness", and click Install. Or from the terminal:

code --install-extension harness-inc.harness-vscode

Connect your account:

Click the Harness icon in the Activity Bar → run Harness: Configure API Key → enter your instance URL and Personal Access Token. Your Account ID is extracted from the PAT automatically.

Select your org and project. Pipelines load immediately.

‍Requirements: VS Code 1.85.0+, active Harness account.

Watch it in action

Watch the walkthrough from our very own Luis Redda.

Stay in VS Code. Your Pipelines Will Follow.

The context-switching loop (open Harness, find the execution, copy the log, switch to your AI tool, paste, and ask) doesn't have to be part of how you work. Pipeline status, logs, approvals, and AI-assisted debugging all live in the same panel as your code. Install the extension, connect your account, and the next time something breaks, you'll already be where you need to be.‍

For more information, checkout the docs.

• Modern Azure deployment goes beyond basic pipelines. Teams that combine CI/CD automation with progressive delivery and feature flags ship faster and with far fewer incidents.
• Choosing the right deployment strategy for each workload type dramatically reduces blast radius and makes rollbacks a matter of seconds, not hours.
• Embedding feature management and experimentation directly into Azure deployments lets teams decouple deployment from release before full rollout.

‍

Learn how to master Azure deployment with CI/CD pipelines, progressive delivery, and feature flags. See how Harness helps engineering teams ship faster and safer on Azure.

Azure deployment sounds straightforward. Push code, it runs in the cloud. But if you've managed a 2 a.m. production incident because a deployment went sideways on AKS, you know the gap between "it deploys" and "it deploys safely at scale" is significant.

This guide covers the deployment strategies, pipeline structures, and operational patterns that close that gap -- from how to sequence a canary rollout to how Harness Continuous Delivery makes the whole operation measurably safer.

What Is Azure Deployment?

Azure deployment is the process of releasing application code, configuration, or infrastructure changes to Microsoft Azure. That can target VMs, AKS clusters, Azure App Service, Azure Functions, Azure Container Instances -- whatever your workload runs on.

At the artifact level, a deployment pushes a container image, a build package, or a Terraform plan into an Azure environment. What distinguishes a mature deployment workflow from a basic one is the control layer around that push:

• CI gates every commit. No artifact reaches Azure without passing build, test, and static analysis stages.
• CD automates the path from staging to production. Humans approve; pipelines execute.
• Deployment strategy determines blast radius. Canary, blue-green, and rolling deployments each make a different tradeoff between speed, safety, and cost.
• IaC keeps environments consistent. If a resource change isn't in code, it doesn't happen.
• Observability triggers rollback. Post-deployment verification watches metrics automatically. If error rates cross the threshold, the pipeline acts -- no engineer needs to catch it first.

Azure Deployment Strategies: Pick the Right Tradeoff

The strategy you choose determines how much of your user base absorbs a bad release before you can respond. The tradeoffs are clear.

Blue-Green Deployment

Blue-green keeps two identical environments live: blue handles production traffic; green runs the new version. When green passes validation, traffic cuts over instantly.

What this means in practice on Azure:

• You're running double the infrastructure during every deployment window -- parallel App Service slots, duplicate AKS node pools, or mirrored Container Apps environments.
• Rollback is instant: flip traffic back to blue.
• Validation happens before any user sees the new version.

Use blue-green when: rollback speed matters more than infrastructure cost, and you need zero-downtime cutover with the option to abort completely.

Skip blue-green when: your workload has stateful dependencies or database schema changes that make running parallel environments operationally complex.

Canary Deployment

Canary deployments send a defined percentage of traffic to the new version while the rest stays on stable. Start small, watch metrics, and expand only when data supports it.

A standard canary ramp on a high-traffic Azure workload:

1. 1% of traffic to canary. Watch p95 latency and error rate for 15-30 minutes.
2. 5% if metrics hold. Watch for another 30 minutes.
3. 25% if metrics hold.
4. 100% once you're confident.

At each stage, define a specific rollback trigger before the deployment starts -- not while you're watching dashboards. For example: if error rate rises more than 0.2% above baseline, or p95 latency increases more than 50ms, auto-roll back and alert.

The blast radius of a bad release tops out at whatever percentage is currently on canary. Catch a problem at 1%, and one in a hundred users hits it -- not all of them.

Rolling Deployment

Rolling deployments replace instances of the old version in batches. No double infrastructure -- each batch of pods gets updated and validated before the next batch rolls.

This is resource-efficient, but old and new versions run simultaneously during the rollout. That creates two constraints:

1. API calls from old instances can reach new instances. If your API contract changed, backward compatibility is required.
2. Database schema changes need to be backward-compatible before the rollout starts. Migrate first, then deploy.

Use rolling when: your workload is stateless, API changes are backward-compatible, and infrastructure cost is a constraint.

Building a CI/CD Pipeline for Azure

A reliable Azure deployment pipeline runs the same automated process on every commit. Here's how the stages flow using Harness-powered pipelines.

Stage 1: Source Trigger

A commit or PR kicks off the pipeline. Every change -- bug fixes, config updates, dependency bumps -- goes through the same stages. No exceptions for "small" changes; that's where incidents come from.

Stage 2: Build and Unit Test

Code compiles. Container images build. Unit tests run. If anything fails here, the pipeline stops. Don't let a broken build consume downstream compute.

Tag images with the pipeline sequence ID or commit SHA -- never "latest" in production. You need to be able to redeploy any version from six months ago without guessing which image it was:

yaml

- step:
    type: BuildAndPushDockerRegistry
    name: Build and Push
    spec:
      connectorRef: azure_container_registry
      repo: myapp
      tags:
        - <+pipeline.sequenceId>
        - <+trigger.commitSha>

Stage 3: Static Analysis and Security Scanning

Run SAST on every PR. DAST is often run asynchronously (e.g., nightly or pre-release) due to runtime and environment requirements -- it's slower and will add minutes to every commit if you run it inline. Container scanning happens before the image lands in Azure Container Registry. Block the push if critical vulnerabilities are found; don't flag and continue.

Stage 4: Artifact Publishing

Validated images push to Azure Container Registry. Deployment packages go to your artifact store. Nothing reaches Azure environments without passing stages 2 and 3.

Stage 5: Infrastructure Provisioning

IaC definitions -- Bicep, ARM, or Terraform -- apply any environment changes before application artifacts deploy. Infrastructure and application deployments should be independent pipelines where possible. Coupling them couples their blast radii.

Stage 6: Staging Deployment and Integration Tests

Deploy to staging first. Run smoke tests and integration tests against real infrastructure. Review testing methodologies for CD pipelines to validate the release before production. This is where environment-specific bugs surface: network policies, service mesh configs, secrets management -- things unit tests don't catch.

Stage 7: Production Deployment with Progressive Delivery

Deploy to production using your chosen strategy. For canary: configure traffic weights in Azure Front Door, Application Gateway, or your AKS ingress controller. Automate the traffic ramp -- don't rely on manual weight adjustments at each stage.

Stage 8: Post-Deployment Verification

Harness AI-assisted deployment verification watches error rates, p95 latency, pod restart counts, and relevant business metrics (conversion rate, checkout completion) for at least 30 minutes post-deployment. If a threshold is breached, the pipeline rolls back without waiting for a human to notice.

Example rollback trigger thresholds:

• Error rate increases more than 0.2% over baseline → auto rollback
• p95 latency increases more than 50ms over baseline → auto rollback
• Pod restart count increases more than 3x → halt rollout, alert on-call

Infrastructure as Code for Azure: Keep Environments Consistent

Manual Azure resource changes create configuration drift. When production diverges from what your IaC defines, incidents become harder to diagnose because you can't be certain what state the environment is actually in.

The rule: if a change isn't in code, it doesn't happen in production. That applies to VM sizes, network security groups, Key Vault access policies, AKS node pool configs -- everything.

What IaC actually gives you:

• Version control for infrastructure. Every change is in a PR, reviewable, and revertible.
• Reproducible environments. Spin up a staging environment that mirrors production exactly, run your tests, tear it down.
• Drift detection. Automated checks compare the live Azure environment against your IaC definitions. If they diverge, you get an alert or auto-remediation.
• Audit trails. Compliance teams can see what changed, when, and who approved it -- without digging through Azure activity logs.

Harness Infrastructure as Code Management adds drift detection, cost visibility, and policy enforcement directly in the pipeline. A Terraform plan that would provision resources over budget threshold fails the policy check before apply runs.

Progressive Delivery in Azure

Traditional deployments push everything to everyone at once. If something is broken, every user hits it simultaneously. Progressive delivery replaces that with a controlled ramp.

The technical mechanics depend on your Azure service:

• AKS: Weighted ingress routing using NGINX ingress or Azure Application Gateway Ingress Controller.
• Azure App Service: Deployment slots with traffic splitting configured via Azure CLI or portal.
• Multi-region: Weighted routing rules in Azure Front Door.

The operational pattern is the same regardless: start at 1-5% of traffic, define automated rollback triggers before the deployment starts, measure for at least 15-30 minutes per stage, and expand only when metrics confirm the release is healthy.

What makes this work at scale is automated deployment verification. Instead of an engineer watching dashboards at every ramp stage, the system watches metrics and halts or rolls back if guardrails are breached.

Feature Flags in Azure Deployments: Separate Deployment from Release

Deploying code and releasing features to users are two different pipeline stages. Feature flags are how you keep them separate.

When you ship behind flags, code deploys to Azure in an off state. The flag controls which users see it, when, and at what percentage. No high-stakes launch moment -- you ramp exposure the same way you'd ramp a canary.

This matters most in complex Azure architectures where services deploy independently. A new API version can deploy across your AKS cluster while the flag gates user-facing exposure until every downstream service is ready. No coordinated rollout timing. No deployment freeze while other services catch up.

How Flags Integrate with the Azure CI/CD Pipeline

The flag lives in application code. The pipeline deploys the code; Harness Feature Management controls flag state. Those are independent systems.

javascript

// Feature flag check in application code
const isNewCheckoutEnabled = await featureFlags.isEnabled('new-checkout', {
  userId: user.id,
  region: user.region
});

if (isNewCheckoutEnabled) {
  return newCheckoutFlow(cart);
} else {
  return legacyCheckoutFlow(cart);
}

Patterns That Work Well for Azure Deployments

Ship dark, release progressively. Deploy to all Azure regions behind a flag. Enable for internal users first. Validate against real infrastructure without external exposure. Then ramp: 1%, 5%, 25%, 100% -- each step gated by metrics.

Region-by-region rollouts. Target Azure regions sequentially using flag targeting rules. East US first; if error rates hold for 24 hours, enable in West Europe. No new deployment required to expand.

A/B test infrastructure changes. Testing a new AKS node type or a different caching layer? Harness Experimentation lets you route a percentage of workloads to the new configuration and compare against guardrail metrics with statistical validity -- not gut feel.

Release monitoring at the feature level. System-level monitoring tells you error rate is up 0.3%. Harness Release Monitoring tells you the new checkout variant is adding 40ms of p95 latency. The second tells you what to fix.

Warehouse-Native Experimentation

For teams running Azure Synapse Analytics or Azure Databricks, warehouse-native experimentation computes experiment results directly in your data warehouse -- no ETL pipelines, no data export, no additional latency in your analysis.

GitOps for Azure: Git as the Source of Truth

GitOps applies the same version-control workflow you use for application code to your Azure infrastructure and deployment configuration. Desired state lives in the repo. The live Azure environment is continuously reconciled against it.

For AKS workloads, the GitOps loop runs like this:

1. Engineer opens a PR with a Kubernetes manifest change.
2. PR is reviewed, approved, and merged to main.
3. GitOps controller detects the diff between desired state (repo) and live state (cluster).
4. Controller applies the change to the AKS cluster automatically.
5. If the live state drifts from the repo at any point -- manual kubectl change, failed sync -- the controller flags it or auto-remediates.

Every infrastructure change goes through code review. Every rollback is a revert commit. Audit trail is automatic.

Harness GitOps provides enterprise-grade GitOps with the audit trails, RBAC, and governance controls that Azure production environments demand -- without the operational overhead of managing Argo CD clusters yourself. The same discipline applies beyond Kubernetes: GitOps principles on ARM definitions, Bicep modules, or Terraform workspaces mean every Azure environment change follows the same review-approve-apply workflow as application code.

Governance and Policy in Azure Deployments

At enterprise scale, governance needs to be pipeline-native -- not a checklist that runs after deployment. Policy as Code applies compliance rules directly inside your Azure deployment pipelines, replacing manual approval checklists with automated checks that run before anything reaches production.

Harness DevOps Pipeline Governance enforces this at every stage:

• Required security gates. SAST, SCA, and container scanning run automatically on every PR and build. Critical findings block promotion to production. Policy enforcement is in the pipeline -- no human bottleneck.
• Immutable audit logs. Every deployment, approval, flag change, and rollback is timestamped and attributed. Required for SOX, HIPAA, or ISO 27001 compliance in Azure environments.
• Environment-specific approvals. Staging promotes automatically; production requires sign-off. The approval workflow lives in the pipeline definition, not in someone's email inbox.
• Cost guardrails. Policy checks block Terraform plans that would provision Azure resources over budget thresholds. Catch infrastructure cost overruns before apply runs, not after the invoice arrives.

Azure Deployment Best Practices

These are the patterns that separate teams shipping confidently on Azure from teams that dread release day.

• Never deploy directly to production. Even for "tiny" changes. Every change goes through at least one pre-production environment with automated testing.
• Make every deployment artifact immutable. Tag container images with commit SHAs. You should be able to redeploy any version from six months ago in under five minutes, without digging through Slack to figure out which image tag it was.
• Decouple infrastructure and application deployments. Changing Azure resources and changing application code should be separate pipelines. Coupling them couples their blast radii.
• Define rollback before you deploy. Every deployment needs a rollback plan -- and ideally, an automated one. If rollback requires more than a button click, simplify the pipeline.
• Monitor at the feature level, not just the system level. "Error rate is up 0.3%" tells you something is wrong. "The new checkout variant is causing a 12% increase in cart abandonment," tells you what to fix.
• Treat configuration as code. Azure App Configuration values, Key Vault references, and environment variables belong in version control and deploy through the same pipeline as application code.
• Ship continuously, not on a schedule. The longer the gap between deployments, the more changes are bundled, the harder it is to isolate what broke. Continuous delivery with small, frequent deploys reduces the cost of every individual change.

How Harness Powers Azure Deployment at Scale

Teams shipping to Azure need CI, CD, feature management, infrastructure automation, and observability connected into a single workflow -- with the governance controls that enterprise Azure environments require.

Harness gives Azure teams:

• Continuous Integration with intelligent test selection, incremental builds and pipeline caching, and pipeline analytics that eliminate build bottlenecks.
• Continuous Delivery with canary, blue-green, and rolling strategies built in -- including AI-assisted deployment verification that watches metrics and rolls back without human intervention.
• Infrastructure as Code Management for Terraform and Bicep workflows with drift detection, cost visibility, and policy enforcement.
• Feature Management & Experimentation to decouple deployment from release, run A/B tests against real Azure traffic, and monitor at the feature level.
• CD data visualization to track deployment frequency, lead time, and change failure rate across your Azure environments.

The result: Azure deployments that are faster, safer, and measurably better -- with the data to prove it.

Azure Deployment: Frequently Asked Questions

What is the difference between Azure deployment and Azure DevOps?

Azure deployment is the process of releasing application code or infrastructure changes to Azure cloud resources. Azure DevOps is Microsoft's platform for managing source control, CI/CD pipelines, work items, and artifact management. You can use Azure DevOps to orchestrate deployments, but it's one of several tools that can do so. Harness provides Azure deployment capabilities with enterprise-grade progressive delivery, feature management, and governance that extend beyond native Azure Pipelines.

What Azure deployment strategy should I use for a high-traffic application?

For high-traffic Azure applications, canary deployments offer the best balance of safety and speed. Start at 1% of traffic, watch error rates and p95 latency closely, and ramp to 5%, 25%, and 100% as metrics confirm health. Define automated rollback triggers at each stage before the deployment starts.

Blue-green deployments work well when you need instant rollback capability and can absorb double the infrastructure cost during deployment windows. Rolling deployments suit stateless workloads where brief mixed-version operation is acceptable, as long as API and schema changes are backward-compatible.

How do feature flags fit into an Azure CI/CD pipeline?

Feature flags integrate at the application code level, not the pipeline level. Code deploys to Azure with new features disabled behind flag checks. The deployment pipeline handles getting code to Azure; the feature flag controls which users see the new functionality and when. This lets your pipeline run continuously -- shipping every commit -- while you control feature exposure independently through feature management.

How do I prevent configuration drift in Azure?

Define all Azure resources in Infrastructure as Code -- Bicep, ARM templates, or Terraform -- and enforce a policy that no manual changes are made to production environments directly. Automated drift detection continuously compares the live Azure environment against the desired state in your IaC definitions and alerts (or auto-remediates) when they diverge.

What metrics should I watch during an Azure deployment?

At minimum: HTTP error rates (watch for increases above 0.2% over baseline), p95 and p99 latency (degradation shows here before average latency moves), pod restart counts for AKS workloads, and relevant business metrics like conversion rate or checkout completion.

Monitor at the feature or deployment level, not just at the infrastructure level. "Error rate is up" tells you something is wrong. "Feature X caused a 15% increase in checkout errors" tells you what to fix.

Can I run A/B tests on Azure infrastructure changes, not just product features?

Yes. Experimentation works for engineering validation as well as product changes. Route a percentage of AKS workloads to a new node type, compare caching strategies, or test a new database configuration -- all with the same statistical guardrails you'd apply to a UI experiment. For teams with Azure Synapse Analytics, warehouse-native experimentation computes results directly in your data warehouse without additional ETL overhead.

Human review, and AI review, can only get you so far

Let's be frank: the last few years in software engineering have been earth-shattering. The foundations of the discipline have changed. Code can be written, rewritten, tested, and shipped faster than ever before. Agents are burning through trillions of tokens, and every month they get better at turning vague intent into working software.

That is exciting. It is also destabilizing.

Many teams are still built around the assumption that every meaningful change can be understood by a human before it merges. A developer opens a pull request, a reviewer reads it, a test suite runs, and the team decides whether the change is safe enough to deploy.

That model was already under pressure before AI, but now it is breaking.

LLMs can produce code far faster than any team can review it. The volume problem is obvious: if one engineer with an agent can generate several times more change than before, the review queue grows faster than the organization can absorb. The harder problem is trust. Even when a change looks reasonable, and even when another model reviews it, the system still cannot guarantee the behavior of that change in production.

AI review does not eliminate this problem. You can ask a different model, use a different prompt, or build an entire agentic code-review workflow. That can catch real issues. It can improve consistency. It can reduce the burden on humans. But it is still a non-deterministic system evaluating the output of another non-deterministic system. It can tell you what looks wrong. It cannot prove that a change will not degrade production.

Even staging and QA only get you so far. A non-production environment is not, and cannot be, exactly the same as production. It will not have the same traffic shape, data distribution, customer behavior, integrations, timing, scale, noisy neighbors, or failure modes. The closer you make it, the more useful it becomes, but it is still a model of production. It is not production.

So the question is not, "How do we review everything perfectly?"

The better question is, "How do we release in a way that assumes review is imperfect?"

The Old Idea That Suddenly Matters Again

Would you believe that one of the best answers to this problem has existed for a long time?

In December 2009, Flickr published an unassuming engineering post called Flipping Out. The idea was simple: release new features without deploying new code for every feature launch. Flickr described a model where code was merged continuously, deployed from the main branch, and gated behind small runtime switches. A feature could exist in production but remain unavailable until a configuration value flipped it on.

At first, that may not seem directly related to AI-generated code. But follow the thread.

What Flickr was describing is what we now call feature flagging. Combined with trunk-based development, feature flags let teams deploy code continuously without releasing every behavior immediately. The key distinction is simple but profound: deployment and release are not the same thing.

Deployment is getting code into an environment.

Release is exposing behavior to users.

Those two actions are often treated as one event, but they do not have to be. Feature flags are a way to choose between code paths at runtime and explicitly decouple deployment from release. With AI-accelerated engineering, that separation becomes a basic safety requirement.

If AI can generate more changes than humans can manually reason through, then the release system has to become more empirical. It has to answer: what is this feature actually doing to real users, real systems, and real business metrics?

The Game Is Production Feedback

Hiding unfinished work behind if statements is only the beginning. The real value is controlled exposure. A feature can be deployed to production, then released first to internal testers. Then to one percent of users. Then five. Then ten. At every step, you observe the impact before deciding whether to continue.

Production is where the unknowns live. Your tests can tell you whether the code behaves as expected in known scenarios. Your reviewers can tell you whether the change looks reasonable. Your static analysis tools can tell you whether it violates known rules. But only production can show you whether the change behaves well under the messy reality of actual usage.

Why APM Is Not Enough

Most teams already have observability. They have dashboards, logs, traces, alerts, and APM tools. You still need all of that, but aggregate system health is a blunt instrument when the risk is tied to one feature in a partial rollout.

APM tools are usually excellent at telling you something changed in the system. They are much less reliable at telling you which feature caused the change, especially during progressive delivery.

Imagine an AI-generated change increases crash rate by 10 percent for users who receive it. If that feature is only enabled for five percent of traffic, the total crash rate across the whole application may move by only half a percent. That can look like noise. It may not page anyone. It may not even be visible until the rollout expands to 20, 30, or 50 percent of traffic.

Harness FME Release Monitoring is designed around that gap. Rather than looking only at aggregate platform health, Release Monitoring measures the impact of feature flags and experiments on performance and behavioral metrics. If multiple features are rolling out at once, you do not want to know only that the application got worse. You want to know which feature is responsible, which users saw it, and which metric moved.

Metrics Become the Review Layer

Code review does not go away. Human review still matters. AI review still helps. Tests still matter. Security scanning still matters. Production metrics add the control those systems cannot provide on their own: measured impact.

In Harness FME, metrics evaluate the impact of feature flags and experiments on user behavior and system performance. They can measure errors, conversions, page load performance, interactions, satisfaction, sessions, shopping cart behavior, and any other event stream that matters to the product.

"Safe" is not a purely technical word. Depending on the feature, safety might mean error rates stay flat, page loads do not slow down, conversion does not drop, support tickets do not spike, or customers do not start rage clicking their way through a broken flow.

The right guardrails depend on the feature. Engineering leadership may care about latency and error rate. Product leadership may care about adoption and retention. Support may care about ticket volume. The power of a metric-driven release process is that all of those concerns can be defined before the rollout, measured during the rollout, and used to decide whether the feature keeps moving forward.

That changes the AI conversation. Reviewers are no longer being asked to predict every possible effect of a change from the diff alone. The release system is responsible for measuring the effects that actually matter.

Alert, Kill, Learn, Continue

Once metrics are attached to a rollout, the next step is automation.

Harness FME alerts and monitoring can notify teams when metrics cross critical thresholds or when statistically significant impact is detected on key or guardrail metrics. If the impact is negative, the team can stop the rollout, kill the flag, and investigate with a much narrower blast radius than a traditional deploy-and-pray release.

The operational model starts to look different:

1. AI helps generate the change.
2. Humans and AI review the change where review adds value.
3. The change merges behind a feature flag.
4. The code deploys to production without immediately releasing to everyone.
5. The feature ramps through controlled production exposure.
6. Metrics determine whether the rollout continues, pauses, rolls back, or gets killed.

That loop is much more realistic for the AI era than pretending review can scale linearly with code generation.

With FME pipelines, this can also become part of the delivery workflow itself. Harness pipelines can include FME steps for operations like creating or updating feature flags, changing rollout behavior, modifying targets, setting default allocations, and killing a flag. Feature release can move from an ad hoc manual process to an auditable automation path.

AI velocity does not need chaos with better dashboards. It needs disciplined automation with measurable gates.

Production Is the Proof

Software engineering has changed permanently. The amount of code that can be produced by a small team is going up. The number of ideas that can be prototyped is going up. The number of changes waiting to be reviewed, validated, merged, and released is also going up.

But some things have not changed.

Production is still the only environment that is truly production. Users still behave in ways you did not predict. Distributed systems still fail in ways your test plan did not imagine. Business metrics still matter more than whether the diff looked elegant.

So yes, keep reviewing code. Use AI reviewers where they help. Keep improving tests. Keep scanning for vulnerabilities. Keep investing in non-production environments.

None of that is proof by itself.

When features are being written faster than humans can comprehensively review them, the release process has to become empirical. Put the code behind a flag. Release it progressively. Measure the impact per feature. Alert on guardrails. Kill the feature when the data says it is hurting users.

In the age of the LLM, the proof is in production.

• Infrastructure failures increasingly happen after provisioning through drift, unmanaged changes, and fragmented workflows.
• Traditional IaC pipelines validate infrastructure at a single point in time, but modern cloud environments require continuous governance.
• Effective infrastructure control planes unify provisioning, configuration, policy enforcement, drift detection, and self-service workflows.
• Platform engineering teams scale faster when governance is embedded directly into developer workflows instead of layered on afterward.
• Internal developer portals only succeed when backed by standardized templates, policy guardrails, and centralized infrastructure controls.

Infrastructure provisioning is no longer the hard part.

Most engineering organizations have already standardized on Infrastructure as Code (IaC), GitOps workflows, Terraform or OpenTofu, and CI/CD pipelines. Provisioning cloud infrastructure has become relatively repeatable.

But operating infrastructure at scale remains deeply fragmented.

That’s the tension platform engineering teams are now dealing with: infrastructure doesn’t typically fail during provisioning anymore because it fails after deployment through drift, inconsistent runtime configuration, policy violations, and unmanaged operational changes.

As cloud environments become more dynamic, traditional infrastructure automation models are showing their limits.

During the recent Harness webinar Designing a Control Plane for Cloud Infrastructure, Rohit, Product Manager for ICM at Harness, and Mrinalini Sugosh, Product Marketing Manager at Harness, outlined why platform teams are shifting from static provisioning workflows toward continuous infrastructure control. That shift fundamentally changes how platform engineering teams need to think about governance, self-service, and infrastructure operations.

Provisioning Isn’t the Hard Part Anymore

The industry has spent the last decade solving infrastructure provisioning.

Terraform, OpenTofu, GitOps workflows, CI/CD automation, and cloud-native APIs dramatically improved infrastructure consistency and repeatability. Most teams can now provision infrastructure reliably through declarative workflows.

But provisioning is only one moment in the infrastructure lifecycle.

Modern environments continuously change:

• Auto-scaling modifies infrastructure dynamically
• Managed cloud services evolve underneath applications
• Teams introduce manual changes during incidents
• Runtime tooling drifts independently from IaC definitions
• Multiple infrastructure systems operate without shared governance

That distinction matters because most IaC pipelines still operate like transactional systems:

1. Run plan
2. Validate configuration
3. Apply changes
4. Exit

The problem is that cloud infrastructure does not remain static after deployment.

Traditional infrastructure workflows validate infrastructure at a single point in time. Modern infrastructure requires continuous observation and enforcement.

Infrastructure Drift Is the Real Operational Problem

Infrastructure drift is no longer an edge case.

It’s the default operating condition for most large-scale cloud environments.

A developer updates a security group directly in AWS during an incident. An engineer modifies a Kubernetes runtime configuration outside GitOps. A platform team upgrades infrastructure dependencies manually to unblock production.

The infrastructure technically “works,” but the declared state and actual state no longer match.

Over time, that creates:

• Governance gaps
• Security inconsistencies
• Audit failures
• Cost overruns
• Broken deployment assumptions
• Operational fragility

Rohit described this reality during the webinar as the “glass break” problem:

“In incident scenarios, the instinct is to fix things with ClickOps is the easiest way possible, which leads to drift. If not remediated, after the incident.”

Most organizations attempt to solve this operationally through:

• Manual reviews
• Separate policy engines
• Ticketing workflows
• Ad hoc approvals
• Disconnected scanning tools

But fragmented tooling compounds the problem.

Infrastructure provisioning, runtime configuration, deployment workflows, security scanning, and self-service portals often evolve independently. Each layer introduces its own operational logic, approval models, and governance controls.

Eventually, the platform itself becomes the source of complexity.

What a Modern Infrastructure Control Plane Actually Does

A control plane changes the operating model.

Instead of treating infrastructure governance as a one-time validation step, platform teams move toward continuous governance:

• Desired state is continuously observed
• Actual state is continuously measured
• Drift is continuously identified
• Policy violations are continuously enforced
• Remediation becomes operationalized

This is the difference between infrastructure automation and infrastructure operations.

According to the webinar speakers, modern control planes are designed to unify several traditionally disconnected functions into a single operational layer, including infrastructure provisioning, runtime configuration management, policy enforcement, cost governance, drift detection, security scanning, self-service infrastructure workflows, and deployment orchestration. The major architectural shift is that governance is no longer treated as a separate overlay added after deployment, but instead becomes embedded directly into the system itself, including at the design stage. 

This approach enables organizations to enforce controls such as blocking unsupported OpenTofu versions, preventing GPU provisioning in development environments, enforcing tagging standards, validating security posture before provisioning, and surfacing projected infrastructure cost changes during approval workflows. As Rohit explained, “You want these gates as part of the release process rather than as an afterthought in production.” This philosophy aligns closely with modern platform engineering models, where governance is automated, centralized, and reusable across teams and environments.

The 4 Core Capabilities of an Effective Infrastructure Control Plane

1. Unified Provisioning and Configuration Workflows

Most enterprises still manage infrastructure provisioning and runtime configuration through separate operational systems. Infrastructure is commonly provisioned with Terraform, runtime environments are configured with Ansible, deployments are managed through CI/CD pipelines, and security tooling operates independently from the rest of the delivery process. This fragmented approach creates operational silos, duplicate governance workflows, policy inconsistencies, fragile integrations, and significant platform maintenance overhead.

Modern control planes address this problem by consolidating these functions into a unified operational model. During the webinar, Harness demonstrated how OpenTofu and Terraform provisioning, Ansible configuration management, CI/CD orchestration, security scanning, approval workflows, cost visibility, and drift monitoring can all operate within a single system. By reducing the amount of platform “wiring” required between tools, organizations can establish more consistent governance patterns across the entire software delivery lifecycle while simplifying operational management.

This approach also aligns with broader trends in continuous testing in CI/CD, AI-driven software delivery, and GitOps deployment automation, where operational consistency and automation become foundational platform capabilities.

2. Embedded Policy and Security Controls

Governance at scale cannot rely on tribal knowledge or manual review processes. High-performing platform engineering teams operationalize governance through reusable policies, standardized templates, and inheritance-based control models that can be applied consistently across environments and teams.

The webinar highlighted several examples of this model in practice, including OPA policy enforcement at the account, organization, and project levels, design-time validation before provisioning, embedded security scanning with tools such as Checkov, approval gates enriched with cost and compliance data, and reusable “golden provisioning pipelines.” These capabilities demonstrate how governance can be integrated directly into platform workflows instead of being treated as a separate operational layer.

Manual governance processes do not scale effectively in modern infrastructure environments. Policy-as-code approaches allow platform teams to standardize controls globally while still preserving flexibility for individual development teams. This reduces approval bottlenecks, accelerates compliance workflows, and increases developer autonomy without compromising security or operational consistency.

Well-designed guardrails often improve delivery speed rather than slowing it down because developers can operate within predefined safe boundaries. This principle has become central to modern platform engineering, where governance is designed to be automated, centralized, and reusable across the organization.

3. Drift Detection and Remediation

Many infrastructure as code systems still approach drift detection reactively, and in some environments, drift may go undetected entirely. Modern control planes instead provide continuous monitoring of infrastructure state and compare deployed resources against declared configurations in real time.

Harness demonstrated several capabilities designed to improve operational visibility and auditability, including full infrastructure state version history, attribute-level drift visibility, continuous monitoring for external configuration changes, and historical comparisons across versions. These features help platform teams identify configuration deviations earlier while also improving traceability during incident investigations and operational reviews.

More importantly, continuous drift monitoring enables organizations to move toward proactive remediation models rather than depending entirely on manual operational intervention. As infrastructure environments continue to scale, automated drift detection and remediation are becoming increasingly important because manual review processes cannot keep pace with the volume and complexity of modern cloud infrastructure.

4. Self-Service With Guardrails

Self-service infrastructure without governance often leads to uncontrolled infrastructure sprawl, which is one reason many Internal Developer Portal initiatives struggle after initial adoption. Exposing powerful infrastructure capabilities without consistent operational guardrails can create additional complexity instead of improving developer productivity.

Modern platform engineering requires organizations to balance several competing priorities simultaneously, including developer autonomy, operational consistency, security requirements, cost governance, and compliance enforcement. The most effective platform teams solve this challenge through standardized operational patterns such as golden templates, centralized policy inheritance, reusable provisioning pipelines, embedded approval workflows, standardized workflows, and carefully controlled abstractions.

This model allows developers to provision and manage infrastructure independently while still operating within safe and compliant boundaries. By embedding governance directly into self-service workflows, organizations can improve developer experience without requiring every engineering team to develop deep expertise in the underlying complexity of cloud infrastructure and platform operations.

The Shift From Infrastructure Automation to Infrastructure Operations

Infrastructure automation solved provisioning.

Platform engineering now needs to solve operations.

That requires shifting from:

• Static validation → continuous governance
• Tool-centric workflows → system-centric workflows
• Manual reviews → embedded controls
• Infrastructure provisioning → infrastructure lifecycle management

The control plane model reflects that evolution.

It’s not simply another IaC orchestration layer.

It’s an operational framework for continuously governing infrastructure delivery across provisioning, configuration, deployment, security, and self-service systems.

As infrastructure complexity grows, this architectural shift is becoming less optional.

It’s becoming foundational to how modern platform engineering organizations operate at scale.

FAQ

What is an infrastructure control plane?

An infrastructure control plane is a centralized operational system that continuously manages provisioning, governance, policy enforcement, drift detection, and infrastructure lifecycle workflows across cloud environments.

How is a control plane different from Infrastructure as Code?

Infrastructure as Code defines desired infrastructure state. A control plane continuously observes, governs, validates, and operationalizes infrastructure after deployment.

Why is infrastructure drift a major problem?

Drift creates inconsistencies between declared infrastructure and actual runtime environments, increasing security risk, operational instability, audit failures, and troubleshooting complexity.

What role does platform engineering play in infrastructure governance?

Platform engineering teams create standardized workflows, templates, guardrails, and self-service systems that allow developers to provision infrastructure safely and consistently.

How do control planes improve developer self-service?

Control planes provide reusable templates, embedded governance, and policy enforcement that allow developers to self-service infrastructure without introducing operational risk.

What are “golden paths” in platform engineering?

Golden paths are standardized workflows, templates, and operational patterns that simplify software delivery while enforcing security, governance, and operational best practices.

Why do Internal Developer Portals need governance?

Without governance, self-service platforms can increase infrastructure sprawl, security gaps, and operational inconsistency by exposing powerful infrastructure workflows without guardrails.

How does Harness support infrastructure control planes?

Harness combines Infrastructure as Code Management (IaCM), Internal Developer Portals (IDP), CI/CD, governance, security scanning, and drift detection into a unified software delivery platform.

Conclusion

Cloud infrastructure has evolved far beyond static provisioning workflows, making infrastructure deployment alone insufficient for maintaining governance, operational consistency, security, and reliability at scale. Modern platform engineering teams require systems that continuously observe infrastructure state, enforce policies, validate configurations, detect drift, and operationalize governance throughout the entire infrastructure lifecycle rather than only during deployment events. This shift is driving the emergence of infrastructure control planes as a foundational operating model for modern platform teams. By embedding governance, automation, visibility, and self-service capabilities directly into infrastructure workflows, organizations can improve developer autonomy while maintaining centralized operational control. Solutions such as Harness Infrastructure as Code Management and Internal Developer Portal capabilities are designed to help platform teams operationalize continuous governance, proactive drift detection, and scalable self-service infrastructure delivery across increasingly complex cloud environments.