When a customer asks why your AI gateway allowed a request
A customer reports that an agent sent a confidential document to an external model. Your gateway shows an allowed request. Its current policy blocks that destination for confidential material.
Which policy was active when the request passed? What classification did the gateway receive? Was the content changed before forwarding? Did the external service receive it?
This is a hypothetical incident, but the review questions are concrete. A screenshot of today’s policy cannot answer them. Neither can a request count or a single “allowed” event with no policy context.
The gateway occupies a useful observation point. The evidence it produces needs to preserve precisely what that point could see and do.
Begin with the policy decision
Gateways are becoming observation points for more of an agent’s work. Cloudflare’s Web Search API announcement on October 2, 2026 describes search requests running through AI Gateway, appearing in its logs, and using its billing flow. That creates another place where an operator can investigate a specific request. A customer reviewing the request still needs evidence with enough context to assess it outside that environment.
Policy systems already produce valuable audit material. Open Policy Agent’s decision logs include information about a policy query, its input and result, and the policy bundles involved. They also support correlation identifiers and masking of sensitive fields.
Those records are a sensible source for investigation. The next step is to make the relevant decision understandable to a customer or reviewer outside the operator’s environment.
For the document incident, the reviewer needs the decision tied to the specific attempt. That includes the policy revision reported at evaluation, the relevant input classification, the destination, and the decision returned. A reference to a policy page that has since changed is insufficient for inspecting the earlier rules.
Preserve the historical policy material needed for the claim, subject to disclosure controls. If the export contains only a revision identifier, say so. Reproducing a decision may also require data and runtime conditions that are absent from the export.
“Allowed” describes one step
A policy engine can return an allow decision while the gateway fails to forward the request. A gateway can apply redaction while the downstream service rejects the changed request. A connection error can leave the gateway uncertain about whether the receiver accepted the content.
The incident review therefore needs three separate questions:
| Question | Relevant observation point |
|---|---|
| What decision did policy evaluation return? | Policy decision point |
| What action did the gateway report taking? | Enforcement point |
| What did the destination report receiving or processing? | Downstream service or receiver |
A deployment may combine the first two components. Their statements still have different meanings.
For redaction, “redaction required” is a decision. “These fields were removed from the forwarded representation” is an enforcement claim. “The receiver observed that representation” is a receiver claim. A record should not slide between them.
If the only available event is a policy query returning allow, it cannot establish that confidential content reached the external service. If the only event is a receiver response, it may not explain why access was allowed. Preserve both when the question needs both.
Identify who actually signed the record
There are several ways to produce portable evidence from a gateway workflow.
The gateway may sign a record at the point where it handles a request. A collector may receive a gateway event and sign a record describing that observation. An export service may later transform a stored log into a signed record.
These approaches offer different evidence.
A collector’s signature protects the collector’s statement. It does not retroactively become the gateway’s signature. A later export does not establish that its contents were committed at the time of the original decision. Preserve source timestamps and collection times as distinct observations, with their provenance.
For an OPA-based example, ordinary decision logs do not become evidence signed by OPA because a PEAC exporter signs a derived record. The signer is the exporter. The underlying event remains native source material evaluated on its own terms.
This precision lets a reviewer understand which part of the account comes from the source, which part comes from a collector, and which transformations occurred afterward.
Disclose enough to review, without exporting the document
Security review does not automatically require handing the customer every prompt, token, header, and payload.
For the hypothetical incident, a scoped export might include the destination, a classification reference, the relevant decision, policy revision, and identifiers connecting the attempt to downstream evidence. The document itself may need a separate disclosure process.
Choose that boundary before signing. Preserve the representation to which each digest refers, and document the transformation used to produce it. A digest of a sanitized document and a digest of the original document establish different bindings.
Redaction also changes what can be evaluated. If the reviewer cannot inspect the material that supplied the classification, they may be able to check the signed classification claim without assessing whether it was correct. The findings should make that distinction visible.
Masking credentials and customer data is necessary. It should not erase the context required to answer the agreed review question.
Include the cases that complicate the timeline
An allow event is only part of a useful gateway audit trail. Denials, review requests, retries, failures, and incomplete observations can explain why an agent took another route or repeated an action.
Keep a logical operation reference for the intended action and separate attempt references for repeated calls. Do not assume adjacent timestamps establish a causal order across machines. Use the workflow’s explicit links where available and state unresolved ordering.
Absence needs equally careful treatment. An export containing no deny event does not establish that no denial occurred. Logging may have been disabled, filtered, delayed, or outside the selected scope. Even a valid chain of supplied records does not establish that every relevant action entered that chain.
The reviewer needs the capture and export scope, alongside any known gaps.
Start with one route a customer already questions
A useful first integration has a named recipient and a narrow question. It might be an enterprise customer assessing whether a tool call used the approved destination, or a security reviewer comparing a requested action with a reported policy decision.
Ask that recipient what they need before designing the export. Preserve the native evidence, add signed records where they help, and provide a verification path under an explicit issuer-and-key policy.
Originary develops this record and handoff workflow using PEAC Protocol. The gateway continues to route and enforce. The evidence helps another party inspect the selected statements without access to the operator’s private systems.
Measure the integration by whether the reviewer can reach a supported finding.
“The gateway reported allow under revision r17; downstream receipt was not supplied” is an actionable finding. “Everything verified” conceals the question that remains open.