Seal what your enforcement engine
was configured to enforce.

An outside party can establish exactly what an AgentCore gateway was configured to enforce — offline, credential-free, with nothing of Rends installed, and including the Cedar text of a policy the operator has since deleted. A default AgentCore deployment retains counters, not per-decision records. A gateway with trace delivery configured does emit a per-decision record — but it names the deciding policy, not the agent that asked or what it asked for.

On 2026-09-13 we enabled CloudWatch Transaction Search, raised indexing to 100%, granted the gateway role permission to write traces, and ran one allow and three enforced denials in the same window. The allow produced six spans in thirteen seconds — every one of them the tool Lambda’s. The gateway emitted none of its own, while propagating trace context downstream, so the decision sits in the trace as a reference to a span that never arrives. Twenty-two seconds later, three enforced denials produced nothing at all: no span, no trace, no log line.

We were wrong, and here is the re-test. That measurement was taken against incomplete instrumentation. AgentCore documents per-gateway trace delivery as a separate enablement step, and it was never configured on the gateway under test. We said we would publish the re-test whichever way it came back. It came back against us.

With trace delivery configured, the same gateway emits a span for every authorization decision — including denials. The denied call produced an AgentCore.Policy.AuthorizeAction span carrying the decision, the reason, and the Cedar policy that produced it by name, plus the enforcement mode, the policy-engine ARN and a unique request id. The trace also resolves properly: the gateway is the entry point, and the dangling reference we described was the missing delivery, not a gap in the product. A denial is recorded, not merely counted, on a correctly configured gateway.

One caution against over-correcting in the other direction. The decision span names the policy — it does not name the principal. There is no agent identity and no delegated human identity on it, the call arguments do not appear, and the policy is identified by id rather than by version. So the record establishes that a decision happened, which policy decided, and what it decided. It does not establish who asked or what they asked for.

We can now verify the decision itself, within one hard limit. With trace delivery configured, the gateway’s own AgentCore.Policy.AuthorizeAction spans can be pulled into a hash-linked bundle and checked by a counterparty offline — the same envelope, and the same verifier, as the configuration seal above. It establishes that a decision happened, which Cedar policy decided, and whether it allowed or denied. It does not establish who asked or what they asked for, because the record AWS emits contains neither, and no amount of work on our side adds them to it. A configuration seal says what the rule was; a decision record says that it fired. Together they answer a question neither answers alone — and they still do not answer “who”.

What we have captured this way is 52 decisions — 26 allow and 26 Cedar default-deny, all at enforcement mode ENFORCE — taken on 16 September 2026 and sealed into a bundle a counterparty can check offline. An earlier capture, taken on 14 September 2026, holds two decisions: one allow, and one deny determined by a named forbid policy. It is kept because it is the only capture that shows that path. Neither is a throughput claim.

A practical note for anyone reproducing this: vended trace delivery takes minutes to become active. A run fifteen seconds after configuring it reproduced the old result exactly. A four-minute wait changed the answer. Reading a pipe before it is carrying is how the original error was made.