[tomjwxf]

Follow-up to #39 and the interceptor review. This is a design RFC for buffered MCP tool calls through an ABCA AgentCore Gateway. It adds a single document and deploys no resources.

Design. A REQUEST interceptor signs and durably records its own admission or rejection before allowing a request to proceed. A RESPONSE interceptor signs the gateway response it observes. An interceptor-generated rejection also invokes RESPONSE and must stay distinguishable from a target response. Native Cedar stays in ENFORCE mode. Its actual verdict has a separate evidence source in policy traces and requires reliable correlation.

Trust and operations. The signing role and KMS key sit outside the agent runtime. The proposal uses a private S3 bucket with conditional appends and a single CloudTrail trail that includes KMS management events. It defines how duplicate attempts, incomplete outcomes and ambiguous correlation should be handled, and what a verifier can establish from an export and a pinned key.

For review. Which trusted ABCA attempt/run binding can both interceptors recover? Does an existing interceptor need to be composed? The final section proposes integration tests and a first-target latency budget. The RFC does not claim these have run in AWS.

Author disclosure. I wrote the receipt-format Internet-Draft and three of the four implementations cited in the original proposal; APS is independently authored. No particular signing or verification package is required.

Checks on this revision. Checked links and the example request digest, ran the repository's documentation sync, and verified locally signed sample request and response envelopes against an external test key. The verifier rejected an edited signed payload.

[krokoko]

Hi @tomjwxf, thank you for the follow-up RFC. This is a significant improvement over #39 — the trust model is explicit, the signer is outside the agent runtime, the compromise analysis is thorough, and the author disclosure is upfront. I appreciate the work that went into this.

However, I have a fundamental concern with the trigger mechanism, and I think it needs to be reworked before we can move forward. The EventBridge trigger is the wrong pattern here.

In my review on #39, I proposed interceptor Lambdas — synchronous, in-path, part of the gateway request/response lifecycle:

Agent → Gateway → REQUEST Interceptor (sign decision receipt) → Tool Target → RESPONSE Interceptor (sign outcome receipt) → Agent

The RFC instead proposes an asynchronous EventBridge-triggered sidecar that reacts to policy decision events after the fact. A few problems with that:

1. The event source doesn't exist. The RFC assumes source: ['aws.bedrock-agentcore'] with detailType: ['Policy Engine Decision'], but AgentCore Gateway does not emit EventBridge events for policy decisions today. The docs only mention CloudWatch logging. Building the core infrastructure around a speculative API is not something we can accept in an RFC.
2. AgentCore Gateway already supports interceptors. REQUEST and RESPONSE interceptor Lambdas are a documented, supported feature — one of each per gateway, backed by Lambda. This is exactly the pattern I proposed. It's available today.
3. Async is architecturally weaker for integrity. With interceptors, receipt signing is synchronous and in-path: the receipt is the authority for the decision, produced before the tool executes. With EventBridge, the receipt is a post-hoc recording with at-least-once delivery semantics — events can be delayed, duplicated, or dropped in failure scenarios. The hash chain's ordering guarantees become fragile on an eventually-consistent event bus. For an integrity-critical system targeting regulated environments, if you can be in-path, you should be in-path.
4. You agreed with this in docs(governance-receipts): add guide for signed decision receipts on ABCA runs #39. Your own response said: "The REQUEST interceptor signs the decision receipt before the tool runs. That makes the receipt the authority for the decision, not a post-hoc recording of it." The RFC reverts to the post-hoc pattern you acknowledged was weaker.

What I'd like to see:

• PRIMARY path: REQUEST interceptor signs the decision receipt, RESPONSE interceptor signs the outcome receipt. Synchronous, in-path, using a
  feature that exists today.
• Drop Section 7.3's EventBridge rule entirely.

The rest of the RFC is solid — the receipt contract (Section 5), trust model (Section 4), CDK patterns for KMS/S3/IAM, and compromise analysis (Section 9) can stay largely as-is. It's the trigger mechanism in Sections 6 and 7.3 that needs to be rebuilt around what AgentCore actually supports.

Minor notes:

• Three of the four "conformant implementations" are your own packages. That's fine (someone has to write them first), but the language "four independent implementations" overstates the diversity. Consider saying "four implementations, three by the RFC author" for accuracy.
• S3 bucket should use BlockPublicAccess.BLOCK_ALL, not just BLOCK_ACLS, for a regulated-environment receipt store.
• Section 7.4 mixes a CloudTrail Trail with an EventDataStore (CloudTrail Lake). Pick one — for the cross-check use case, the event data store with advanced event selectors is sufficient.

Happy to discuss further. The direction is right, the trigger mechanism just needs to match what we actually have available and what gives us the strongest guarantees.

Thank you!

[tomjwxf]

@krokoko agreed on all.

On the trigger mechanism: I contradicted my own #39 position without a technical reason for doing so. The REQUEST interceptor signs the decision as the authority. EventBridge would react to it as a post-hoc recording.

Different integrity claims, and the interceptor version is materially stronger on ordering, delivery, and freshness. Section 7.3 also built around an event source (source: aws.bedrock-agentcore, detailType: Policy Engine Decision) that does not exist today, which shouldn't be in an RFC.

Revised architecture for the next push:

• REQUEST interceptor (in-path, sync): builds and signs the pre-tool
  decision receipt via KMS; returns signed receipt as authority; if
  signing fails, returns a deny that AgentCore enforces.
• RESPONSE interceptor (in-path, sync, optional per-tool): builds and
  signs the outcome receipt, chained via previousReceiptHash to the
  REQUEST receipt.
• Both write to S3 after return. EventBridge rule dropped entirely.

Receipt contract (Section 5), trust model (Section 4), compromise analysis (Section 9), and KMS/S3/IAM CDK patterns stay as-is. Only Sections 6 and 7.3 rebuild.

Minor points, all accepted:

• "Four implementations": three are mine (protect-mcp, protect-mcp-adk,
  sb-runtime), APS by aeoess is the genuinely independent one. Language
  will change to "four implementations, three by the RFC author and one
  independent."
• S3 BlockPublicAccess.BLOCK_ALL: correct for a regulated-environment
  receipts bucket. Will update.
• CloudTrail Trail vs EventDataStore: picking EventDataStore with
  advanced event selectors on eventName = Sign.

One question before I push: would it be useful to validate the interceptor-Lambda wiring against a working AgentCore deployment first so the CDK snippets match what actually ships, or is the doc-level spec enough for this round?

Revised RFC this week. Thanks!

[krokoko]

Thank you @tomjwxf ! I will let it open for a couple more days to have people chime in and provide additional feedback as needed

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@12c9b63). Learn more about missing BASE report.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #40   +/-   ##
=======================================
  Coverage        ?   92.46%           
=======================================
  Files           ?      328           
  Lines           ?    95033           
  Branches        ?     9436           
=======================================
  Hits            ?    87874           
  Misses          ?     7159           
  Partials        ?        0           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tomjwxf]

Refreshed Section 5 and the verification snippet to match the receipt draft as it now stands. Since this RFC was written, the chain-link rule was settled and published in draft-farley-acta-signed-receipts-03 (September): the link is previousReceiptHash, sha256:-prefixed, over the whole preceding receipt with its signature included, and the first receipt omits the member rather than carrying null. I also made explicit that the verification key comes from outside the receipt; a verifier that trusts the public_key inside the receipt it is checking cannot detect a re-signed forgery. The verifier pin moves from 0.3.0 to 0.9.6. Nothing about the trust model, the signer's placement outside the agent runtime, or the AgentCore integration path changes; this is the wire contract catching up with its own spec. Disclosure in the description stands.

[tomjwxf]

@krokoko, I’ve reworked the RFC around the synchronous REQUEST and RESPONSE interceptors you proposed. The EventBridge rule is gone. The request handler waits for a durable signed record before forwarding. The response records what the hook observed, including the case where REQUEST itself returned a rejection. A native Cedar verdict is attributed separately, only when it can be correlated to a policy trace.

I also corrected the disclosure and switched the private bucket to BLOCK_ALL. For the KMS audit I used one ordinary CloudTrail trail, since Lake closed to new customers in May and Sign is a read-only management event.

Could you re-review the revised RFC? The main integration question is which trusted attempt identifier ABCA can expose to both hooks. I’ve left that and the failure-path tests explicit for the first live pilot.