Field note 04
What the gateway writes down.
An MCP tool call that passes through the gateway is not stored as one event. It is stored as seven stages, in order, under a single request ID. This is what each stage contains, what it deliberately leaves out, and which questions the finished record can answer.
Figures from one run against a hosted MCP server. Timings vary; the shape of the record does not.
The stages
A decision per stage, in the order it was made.
A gateway makes several separate decisions before a tool call reaches anything: who is calling, whether policy permits it, which credential applies, and where the request may be sent. Recording them as one "allowed" line collapses all of that into a result. Recording them as ordered stages keeps the reasoning, and keeps the sequence — which matters, because a policy decision that ran before authentication would be a bug you could otherwise never see.
Tool call requested
the request is namedAuthentication
caller identity resolvedPolicy decision
rule and version recordedCredential resolution
which one, not what it isRoute decision
destination and reasonUpstream execution
whether it ran, and how longCompletion
the record is closedEvery stage writes under the same request ID.
That ID is how the seven are read back as one record.
One run, by the clock
Where the time actually goes.
The same seven stages plotted against elapsed time for a single request. Five of the six gateway stages finish before the request leaves the building. Almost all of the wall-clock time belongs to the MCP server doing the work it was asked to do.
- 01tool_call_requested2ms
- 02authentication4ms
- 03policy_decision3ms
- 04credential_resolution4ms
- 05route_decision2ms
- 06upstream_execution214ms
- 07completion3ms
One illustrative run. Absolute timings move with policy complexity, credential mode, and network distance — the ratio between governance work and upstream work is the part that tends to hold.
Field by field
What each stage writes.
Each stage records metadata about a decision — never the content of the request or the value of a secret. These are the fields you can expect to find under a request ID.
| Stage | Recorded |
|---|---|
01tool_call_requestedThe request is named |
request_idclient_surfacesession_idtool |
02authenticationIdentity before authorization |
identity_statusprincipal |
03policy_decisionCedar evaluates |
decision: allowrule: allow_cloudflare_docs_searchpolicy_version: policy_hosted_runtime_proof_v2 |
04credential_resolutionMetadata only |
status: resolvedmode: managed_brokerbinding: registered_credential |
05route_decisionDestination and reason |
route: allowreason: registered_private_endpoint |
06upstream_executionDid it run |
upstream_attempt: truelatency_ms: 214outcome |
07completionThe record is closed |
payload_logged: falsesecret_logged: falseredaction: applied |
Field names and values above are from one run, not a fixed schema. Stage four is the one worth reading twice: it records how a credential was chosen — its mode and its binding — and never the credential.
Receipt or record
A receipt is not an audit trail.
Request, allowed, success. That is the entire chain most gateways keep, and it answers nothing. Which rule fired, which credential moved, where the call was actually sent — none of it was written down, so none of it can be recovered later. That is a receipt. A record keeps the decisions themselves: same request, same result, same latency, and still readable six months from now when somebody asks why it was permitted.
None of this is extra work at request time. Identity gets resolved, policy gets evaluated, a credential gets selected, a route gets chosen — in both chains. Keeping outcomes only does not skip a step. It computes the answer and throws it away.
- Request
- Allowed
- Success
Proof that something happened. Nothing about why it was allowed to.
- Request
- Identity
- Policy
- Credential broker
- Routing
- Upstream
- Immutable audit evidence
Seven nodes, seven decisions the gateway already made. The only question is whether they survive the request.
Reading the record
Audit questions become lookups.
That last node is the one enterprises care about, because it is the one that gets asked about months later. Once a record exists in this shape, each of the usual questions is a field rather than an investigation.
- Why was this tool call allowed?
policy_decision.decisionand.rule. In this run,allowby way ofallow_cloudflare_docs_search— a named rule, not an inferred one.- Which policy version authorized it?
policy_decision.policy_version, captured at evaluation time. Editing the policy afterwards does not change what this record says was in force.- Which credential was used?
credential_resolution.modeand.binding. Enough to identify the credential and trace it back to its registration; not enough to use it.- Did the request bypass the gateway's routing?
route_decision.reason. A value likeregistered_private_endpointmeans the destination was one the gateway already knew about, rather than a path taken around it.- Did it actually reach the server?
upstream_execution.upstream_attemptwithlatency_ms. This is what separates "policy allowed it" from "it happened."- Did any secret get logged?
completion.secret_loggedandpayload_logged, both recorded as part of the run rather than asserted in documentation.
Deliberate gaps
What the record leaves out, and why.
An audit trail that captures request bodies becomes a second copy of the data it was meant to govern — and a new thing to secure, retain, and eventually leak. The gaps below are structural, not an oversight to be filled in later.
- Request and response payloads
- Credential values, tokens, or keys
- Anything matched by a redaction rule
- That a payload existed, and its outcome
- Which credential binding was selected —
mode,binding - That redaction ran —
redaction: applied
Producing one on purpose
The record comes from a request, so you can just make a request.
Nothing above depends on waiting for production traffic. Amelfi exposes this as a governance proof: it issues one real tool call, then checks that all seven stages completed and that the safety fields came back as expected. The output is an ordinary audit record — the same one any other call produces.
- Confirms identity, policy, and routing are actually wired
- Fails loudly on a stage that never ran
- Checks the deployment, not the documentation
- Run it following a policy edit or upgrade
- A missing stage is a regression in the governance path
- Cheap enough to run on a schedule
- Produces a concrete record to read, on request
- Answers version and credential questions from fields
- No secret has to exist in the trail to prove the trail works
The rest of the boundary
Policy, credentials, routing, and the record they produce.
The audit trail is the output of the controls around it. See how Amelfi handles the decisions that get written down.