In April 2026, a developer shipped an agent that had passed every evaluation they ran. Unit tests: green. Task completion rate: 94%. Hallucination rate: below threshold. Then the agent deleted a full production database in nine seconds via an unscoped Railway token. Not a model failure. Not a test gap. A governance gap.
This is the story of CI/CD for AI agents in 2026: teams have built pipelines, added evals, instrumented traces — and are still shipping agents with a missing layer they don't know to check.
The Observability-Eval-Governance Stack (And Where It Breaks)
LangChain's State of AI Agents report, published June 12, 2026 and based on 1,340 survey responses, surfaced a headline gap: 89% of teams have implemented observability for their agents. Only 52.4% have adopted evals.
That gap has been widely discussed. Less discussed is the gap below evals. Almost no teams in the report described anything resembling governance enforcement in their deployment pipeline — checks that would prevent an agent from reaching production with the wrong permissions, an uncapped budget, or unredacted PII flowing through tool calls.
In traditional software engineering, a CI/CD pipeline has three gates: build (does it compile?), test (does it behave correctly?), and deploy (is the environment right?). For AI agents, teams have added a fourth gate — evals — and called it a complete pipeline. It isn't. Evals answer: does the agent produce good outputs? They don't answer: is the agent allowed to do what it will do in production?
That's a different question, and it requires a different gate.
What Quality Evals Check (And What They Miss)
A well-constructed agent eval suite typically checks some combination of: task completion rate, answer correctness, hallucination rate, response latency, and tool call success rate. These are legitimate and useful signals.
What evals don't check:
Scope. Whether the agent has access to resources it doesn't need. An agent scoped to read a user's calendar shouldn't be able to write to their filesystem — but unless you have an enforcement layer that checks what permissions the agent actually carries into production, the eval suite won't surface this. It checks outputs, not authorization boundaries.
PII flow. Whether personal data is being passed into tool calls, stored in memory, or returned in outputs. An eval might measure whether a response contains a phone number — but most eval setups don't instrument the full tool-call chain to check whether PII entered a third-party service mid-execution.
Budget. Whether the agent has a cost ceiling and what happens when it's exceeded. Eval suites measure token usage in test runs. They don't enforce a hard stop at deployment time that prevents an agent from running a 5,000-step loop in production because a test dataset never produced one.
Tool fingerprinting. Whether the tools available to the agent are the same tools it was evaluated against. If an MCP server updates its tool schema after the eval was run but before the deployment completes, the agent might operate against a tool with different behavior than it was tested on. Evals ran against the old schema; the agent ships with the new one.
These aren't hypothetical failure modes. The PocketOS incident (April 2026) and the GitHub Copilot MCP prompt injection chain (CVE-2026-50548) share a common pattern: the agents involved had passed whatever pre-production checks teams ran. What failed wasn't evaluation — it was enforcement.
The Deployment Gate That's Actually Missing
A governance gate is distinct from an eval gate. An eval gate asks: does this agent produce acceptable outputs? A governance gate asks: does this agent have the right to do what it's about to do, with the right limits, in the right environment?
The distinction matters because even sophisticated CI/CD pipelines blur this line. Microsoft Foundry's reference architecture (May 2026) includes "policy violations: 0" as an explicit eval gate metric — but this checks content safety and harmful outputs, not execution-scope governance. It verifies that the agent doesn't produce grounded-response failures. It doesn't verify that the agent's identity carries only the permissions it needs, that there's a hard budget ceiling in the execution environment, or that the tools it will call in production are the same ones it was tested against. Content safety and execution governance are complementary layers — most teams have the first, almost none have the second.
Operationally, that means checking at deployment time:
Permission scope audit. Does the agent's identity carry only the permissions it actually needs for its task? Tools it can call, data it can read, actions it can take — these should be checked against the principle of least privilege before the agent is promoted to production, not after it's been running for three days.
Budget enforcement. Is there a hard cost ceiling that fires in the execution environment, not just in test? A budget cap in a config file that nobody enforced at runtime is not a budget cap — it's a suggestion.
Policy pre-check. Are the governance policies that will govern this agent in production actually applied in the environment it's being promoted to? This is the equivalent of checking that your security groups are actually attached in a cloud deployment — trivial to verify, catastrophic when skipped.
Tool integrity. Are the tools the agent will call in production the same ones it was evaluated against? Tool schema versioning is an unsolved problem for most teams, which means there's a real window between eval and deployment where tool behavior can change without the agent's eval results reflecting it.
How Waxell Handles This
Waxell Runtime is built specifically for the governance gap in agent deployment. When a governed agent is pushed, Waxell runs a risk report before it enters production — mapping the agent's configuration against OWASP LLM Top 10, GDPR, and other frameworks, surfacing findings like "system prompt unset," "unbounded tool loop," and "PII pattern in source" before execution begins.
What this means in practice: the governance gate is native to the deployment step. Policies, budgets, and scope boundaries are declared as part of the agent definition (using @agent, @workflow, and @decision decorators), registered as a versioned artifact, and enforced before the first step runs — not after the first incident.
Waxell Observe covers the runtime side: 50+ policy categories applied across 200+ instrumented frameworks in two lines of code. Execution logs give a durable, ordered record of every model call and tool use — the kind of forensic trace that makes post-incident analysis tractable instead of impossible.
The governance layer runs at 0.045ms p95 latency. It is not the performance bottleneck teams worry it will be.
For teams already operating agent fleets, the migration path is incremental: instrument with Observe first, which requires no rebuilds and no code changes beyond the SDK initialization. Move specific workflows to Runtime when the stakes require it — financial automation, healthcare data, infrastructure operations. The two products work together across the same 200+ libraries.
The Pipeline You Actually Need
A complete agent CI/CD pipeline has five gates, not four:
- Build — does it compile, does the agent definition validate?
- Eval — does it produce acceptable outputs against a maintained test set?
- Governance pre-check — does it have the right permissions, a hard budget cap, and no policy violations at push time?
- Environment promotion — are the policies and budgets from staging actually applied in production?
- Runtime monitoring — are runtime telemetry and policy enforcement active once the agent is live?
Most teams have 1, 2, and a version of 4. Gate 3 is usually missing entirely. Gate 5 often exists in the form of observability dashboards — but observability that records what happened is not the same as governance that prevents it from happening again.
The 89%/52.4% gap in LangChain's State of AI Agents report is real, and closing it matters. But the subtler problem is that even teams with strong eval practices are shipping agents with a missing enforcement layer. Evals tell you whether the agent is good at its job. Governance tells you whether it's safe to let it do that job without a human watching every step.
These are not the same question. Both need answers before the deploy gate opens.
FAQ
What's the difference between an eval gate and a governance gate in an agent CI/CD pipeline?
An eval gate checks whether the agent produces acceptable outputs — task completion, answer quality, hallucination rate. A governance gate checks whether the agent has the right to do what it's about to do: correct permissions, hard budget caps, policy pre-checks, and tool integrity verification. Evals run against test datasets; governance enforcement runs against the execution environment itself.
Why do agents pass all their evals but still cause production incidents?
Evals measure output quality against a fixed test set. They don't enforce execution constraints — they can't prevent an agent from exceeding its token budget, calling a tool it shouldn't have access to, or routing PII through an unaudited third-party service. Those failures emerge from the gap between evaluation (what the agent does in controlled conditions) and governance (what the agent is allowed to do at runtime).
Is CI/CD for AI agents different from CI/CD for regular software?
Yes, in several important ways. Software CI/CD gates check build validity, test pass rates, and environment configuration. Agent CI/CD must additionally handle model versioning and behavioral drift (the same code can produce different outputs as the underlying model changes), eval dataset staleness (test sets that don't reflect current task distributions produce misleading signals), and governance enforcement (permissions, budgets, policy checks) that has no direct equivalent in traditional software pipelines.
How do I add a governance gate to an existing agent deployment pipeline?
The most practical starting point is instrumentation: add Waxell Observe to get a baseline of what your agents are actually doing in production — tool calls, cost per run, policy compliance, PII handling. From that baseline, you can identify which workflows carry enough risk to warrant a Runtime governance layer: hard policy enforcement before each step, durable checkpoints, and a push-time risk scan that catches configuration gaps before they reach production.
What should a governance pre-check at deployment time actually verify?
At minimum: permission scope (does the agent carry only the access it needs?), budget enforcement (is there a hard cost ceiling in the execution environment, not just a config value?), policy application (are governance policies active in the target environment?), and tool integrity (are the tools the agent will call in production the same ones it was evaluated against?). Teams running on MCP infrastructure should add tool fingerprinting — verifying tool schemas haven't drifted between eval and deployment.
Does adding governance enforcement slow down agent execution?
At well-designed latencies, no. Waxell Runtime's governance layer runs at 0.045ms p95. The overhead is negligible for the vast majority of agentic workflows. The relevant performance concern isn't latency — it's the human-in-the-loop holds for genuinely high-risk actions (external sends, destructive writes), which add latency by design because that latency represents a human making a decision.
How does governance gate design change for multi-agent systems?
In multi-agent pipelines, governance enforcement needs to propagate across agent boundaries. An orchestrator agent's policies shouldn't transfer automatically to worker agents it spawns — each agent in the hierarchy should carry its own policy set, its own budget cap, and its own scope. Failing to enforce this is the multi-agent equivalent of not checking whether your microservices have the right IAM roles: technically valid architecturally, operationally dangerous.
Sources
LangChain, State of AI Agents (June 12, 2026), https://www.langchain.com/state-of-agent-engineering — survey of 1,340 professionals. All stats confirmed against primary source via Chrome verification: 89% observability, 52.4% evals, 57.3% in production, 32% quality as top barrier.
Microsoft, CI/CD for AI Agents on Microsoft Foundry (May 22, 2026), https://techcommunity.microsoft.com/blog/educatordeveloperblog/cicd-for-ai-agents-on-microsoft-foundry/4522218 — five-layer reference architecture; confirmed that "policy violations: 0" gate checks content safety (hallucination rate, grounded response rate, policy violation count) not execution-scope governance. Eval gate thresholds confirmed: hallucination <5% CI / <3% prod; task completion >90% CI / >95% prod.
Arize AI, How to Add LLM Evaluations to CI/CD Pipelines, https://arize.com/blog/how-to-add-llm-evaluations-to-ci-cd-pipelines/ — competitor framing of CI/CD gates as quality/safety evaluation.
DeployHQ, AI Agents in CI/CD Pipelines: From GitHub Issue to Production Deploy, https://www.deployhq.com/blog/ai-agents-cicd-pipelines-github-issue-to-production-deploy — evaluation dataset staleness as CI/CD failure mode.
Top comments (0)