AI gateways solved a real problem. Put a proxy in front of your model providers and you get one place to manage keys, route between models, control spend, and see what your applications are actually sending. AgentGateway does this well, and its guardrail webhook is the hook that matters for governance: before a prompt reaches a provider, and before a completion reaches your user, the gateway can ask an external service what to do.
What it asks for is a decision. What most guardrail implementations return is a filter result. Those are not the same thing, and the gap between them is where compliance programs quietly fail.
We built an EVE CoreGuard adapter for AgentGateway. Every request and response flowing through the gateway is evaluated by the same deterministic policy engine that governs the rest of the platform, and every decision produces a signed evidence record bound to the exact content digests and the exact policy version that produced it. It governs message content. It does not claim authority over actions the transport never shows it — and this article is explicit about where that line falls.
What we built
The adapter is a first-class content-governance surface for AgentGateway, not a wrapper around a regex list. It implements the gateway's guardrail webhook contract in both directions — prompts on the way in, completions on the way out — and routes every call through the real CoreGuard policy path rather than a parallel mini-engine built for the occasion.
Compatibility is proven against the real pinned AgentGateway v1.4.1 binary, not a mock of it. The validation matrix runs the actual gateway against a provider that counts its own invocations, so claims about what did and did not reach the model are measured rather than asserted. That matrix currently passes 42 of 42 scenarios.
Pass, mask, reject
Three outcomes, each with a specific meaning.
Pass. The content cleared policy. It continues to the provider unchanged.
Mask. The content contained something the policy says must not cross the boundary. The adapter rewrites it deterministically and the provider receives only the sanitized version. On a request, this happens before the content is delivered to the provider — the original never leaves the governed boundary. On a response, the same applies in reverse: sensitive content in a model completion is masked before it reaches the client.
Reject. The policy blocked the content. The gateway returns an error and the provider is never invoked at all. Not invoked-and-discarded — never called. The validation harness asserts a provider invocation count of exactly zero on every blocked path, because “we filtered the response” and “the request never happened” are different facts with different consequences for cost, for data residency, and for what you have to disclose.
Redaction coverage is an explicitly scoped list, published in the integration documentation: specific secret formats and specific structured identifiers. It is not universal PII or secret detection, and we do not describe it that way. Categories that are low-precision in conversational prose — person names, postal addresses — are deliberately excluded, because masking them corrupts legitimate content more often than it protects anything.
Why wire-level correctness matters
This is the part that surprised us, and it is worth understanding even if you never touch the protocol yourself.
AgentGateway represents the three outcomes as an untagged union. There is no explicit “this is a reject” field. The gateway infers which action you meant from the shape of the payload you return, trying each possibility in a fixed order and taking the first one that fits.
The consequence is sharp: a response that looks correct, and that your own tests accept, can be interpreted by the gateway as a different action entirely. Attach a body to something you intended as a pass, and the shape now matches a mask. Return a structured object where the contract expects a plain string, and a block can be read as a rewrite. Nothing errors. The governance layer believes it blocked; the gateway believes it was told to substitute content.
A decision that is right inside your policy engine and ambiguous on the wire is not enforcement. It is an intention.
So the adapter carries a guard — assert_action_wire_safe() — that runs on every outbound response. It re-derives which action the gateway will actually select from the exact bytes about to be sent, and refuses to emit anything whose interpretation is ambiguous. If the shape does not unambiguously mean what the decision meant, the adapter degrades to a hard reject rather than gambling.
Three consequences follow directly, and they are load-bearing rather than stylistic: a pass carries no response body, a reject body stays a plain string, and signed evidence is correlated out of band rather than embedded in the action. That last one cost us a feature we wanted — it would have been convenient to hand the certificate back inline — but an extra field inside an untagged union is exactly the kind of thing that silently changes which action matches.
Evidence that survives the decision
Every governed decision produces a cryptographically signed certificate. The signature covers the request digest, the digest of whatever content was actually released onward, the policy identity and version that produced the verdict, the tenant context, the direction of travel, and the idempotency scope.
What it does not cover is the content itself. Certificates carry digests, never plaintext. An auditor can prove exactly which bytes were evaluated and exactly which bytes were forwarded, without the evidence record becoming a second copy of the sensitive data it was created to govern. Redactions are recorded as categories, offsets, and counts — never values.
Evidence is written through EVE's existing Postgres authority store, with tenant isolation enforced by row-level security at the database rather than by application code remembering to filter. We deliberately did not invent a parallel evidence store for this adapter; it writes where every other governed decision writes.
And proof gates the pass. If a certificate cannot be produced, or if a required evidence record cannot be durably written, the traffic is rejected. An allow that nobody can later prove is not a governed allow — it is an unlogged allow with better branding.
Failing closed, and staying inside the budget
Governance that fails open is decoration. The adapter rejects when the policy engine is unavailable, when the signer is unavailable, when required evidence cannot be stored, and when the payload violates the protocol contract. There is an explicit opt-out for operators who want availability over enforcement, and when it is engaged the adapter reports itself as non-governing so that traffic cannot later be counted as enforced.
There is also a timing constraint that is easy to get wrong. AgentGateway applies its own webhook timeout — ten seconds. If EVE were slower than that, the gateway would give up first and apply its own failure policy, and EVE would lose both the verdict and the evidence record for that call. So the adapter holds an eight-second deadline, hard-capped below the gateway's, and it cannot be configured above it. Alongside that: bounded concurrency that sheds load with a governed rejection rather than queueing past the cutoff, per-tenant rate limiting, and admission control that runs before authentication so unauthenticated traffic cannot consume policy-engine capacity.
Replay safety, and what happens when policy changes
Gateways retry. Any governance layer that records decisions has to answer what a retried delivery means, and the naive answer — deduplicate on a hash of the content — is wrong in a way that takes a while to notice: two users legitimately asking the identical question would collapse into a single governed decision.
So the adapter separates two things that are usually conflated.
| Role | Inputs | Effect |
|---|---|---|
| Identity | Tenant, integration, direction, caller key | Determines whether two deliveries are “the same delivery” |
| Binding | Request digest, policy set, policy version | Must still match on replay — otherwise the reuse is a conflict |
Reuse a key against the same content under the same policy, and you get the prior decision back with one evidence row, exactly as intended. Reuse it against different content, or after the governing policy set or version has changed, and you get a governed conflict — not a second decision minted quietly, and not a stale approval replayed over new circumstances.
That last case is the one worth dwelling on. A decision made under one policy version is not evidence about a different policy version. Returning it as though it were would turn the evidence record into a liability. The adapter refuses.
Caller-supplied idempotency is off by default, for a reason covered in the next section: the gateway forwards a value the caller controls, and treating caller-controlled input as an identity is only safe behind infrastructure that mints its own.
Content governance is not execution authority
This is the most important section in the article, and the one most vendors would skip.
The AgentGateway guardrail webhook exposes message text. It does not expose complete structured tool calls, provider-execution arguments, or the parameters of whatever the model is about to cause to happen. Those fields are stripped before the webhook is invoked. They are not withheld from EVE specifically — they are simply not part of this transport's contract.
Content masking controls what crosses the model boundary. Execution authority controls whether an action is allowed to occur.
So this adapter governs message content, and says so. It does not authorize MCP operations. It does not authorize tool calls, payments, database mutations, or any other structured action, because it never sees them. An integration configured to require execution authority is rejected by this surface rather than quietly passed, and the readiness endpoint reports content inspection and execution authority as independent capabilities rather than collapsing them into a single reassuring boolean.
EVE does have an execution-authority layer. It requires a transport or connector that exposes the actual executable action and its arguments — which this one, by design, does not. Signed evidence from this adapter attests that content was governed. It does not grant provider-execution authority, and it should never be presented as though it did.
We think the honesty is the product. A governance vendor that manufactures proof for authority it did not possess has produced a more dangerous artifact than no proof at all, because someone downstream will rely on it. The refusal to over-claim is the same discipline that makes the evidence worth anything in the first place.
Where this fits
EVE's position has been consistent: the useful thing an AI control plane does is say no, deterministically, before the consequence lands — and then prove it did. This adapter extends that to the gateway:
- Governance inline at the gateway, in both directions.
- Deterministic pass, modify, or block — the same input under the same policy always produces the same verdict.
- Fail-closed provider protection, with blocked traffic measurably never reaching the model.
- Durable, tenant-isolated evidence in the existing authority store.
- Cryptographically verifiable outcomes, bound to a named policy version.
- Explicit scoping of what was governed and what was not.
If you already run EVE CoreGuard, this is another enforcement point on the same policy and the same evidence chain, not a second governance system to reconcile.
Current status
The adapter is merged and deployed. The feature flags are currently disabled, and general production traffic is not governed through it.
A controlled canary has run against the deployed surface — the real pinned gateway binary pointed at production EVE, with a provider that counts its own invocations. It found two things, and both are worth reporting.
The first is fixed. The adapter read the webhook payload straight from the request stream, but middleware upstream had already consumed it. Every payload therefore parsed as empty and was rejected as malformed. That is the failure mode worth naming: the surface looked healthy, authentication worked, evidence was configured, and with fail-closed set the gateway dutifully rejected every call. Enforcement appeared correct while nothing was being evaluated. The fix ships with a regression test that mounts the routes behind a middleware which deliberately consumes the body first — the condition neither the local harness nor the unit tests had reproduced.
The second is open. With the parse corrected, governed decisions return correctly, but durable evidence writes to the authority store fail intermittently for the canary tenant. The adapter behaves exactly as designed — it refuses to allow traffic it cannot prove it governed — but a refusal is a failed gate, not a passed one. The flags are disabled again until that is resolved, and the canary will be re-run before anything is enabled for real traffic.
We are publishing this rather than waiting for a tidier story. The canary existed to find precisely this class of problem before customer traffic did, and it did. An article about verifiable governance that quietly omitted its own failed gate would be making the argument badly.
EVE CoreGuard evaluates a proposed AI action against your policy pack and returns ALLOWED, BLOCKED, or MODIFIED with a signed, policy-bound evidence record. Inspect a real signed certificate at the verification portal, read the evidence architecture at EVE Proof, see how EVE attaches to an existing stack on the integrations page, or talk to us about a governed pilot.
Frequently asked questions
Does this adapter govern tool calls or MCP operations?
No. The AgentGateway guardrail webhook exposes message text; structured tool calls and provider-execution arguments are stripped before the webhook is invoked. This adapter governs message content. EVE's execution-authority layer is a separate capability that requires a transport or connector exposing the actual executable action and its arguments. An integration configured to require execution authority is rejected by this surface rather than passed.
What happens when a request is blocked — does the provider still see it?
No. A rejection is returned to the gateway before the provider is contacted, and the gateway does not forward the call. The validation matrix asserts a provider invocation count of exactly zero on every blocked path, measured against a provider that counts its own invocations rather than inferred from logs.
Is the evidence verifiable without calling EVE?
Yes. Certificates are signed and verify offline against a published public key. The signature covers the request digest, the digest of the content actually released, the policy identity and version, tenant context, direction, and idempotency scope. Altering any bound field breaks verification. Certificates contain digests only — never the plaintext content that was governed.
What does the adapter do if EVE itself is unavailable?
It fails closed. Governance failures, signing failures, and failures to durably write required evidence all produce a rejection rather than a pass. An operator can explicitly opt into availability over enforcement, and when they do, the adapter reports itself as non-governing so that traffic is not later counted as enforced.
Does it detect all PII and secrets?
No, and we do not claim it does. Coverage is an explicitly scoped list of secret formats and structured identifiers, published in the integration documentation. Low-precision categories in conversational prose, such as person names and postal addresses, are deliberately excluded because masking them damages legitimate content more often than it protects anything.
Is it available in production today?
It is merged and deployed, with the feature flags currently disabled; general production traffic is not governed through it. A controlled canary has run and is not yet green — it surfaced a payload-parsing defect, now fixed, and an open issue with durable evidence writes. The flags stay off until that clears and the canary is re-run. If you are running AgentGateway and want to be involved, get in touch.