Governed Agent Tooling on AWS

A Control Framework for Bedrock AgentCore Gateway

Author: Karim Boudich
Audience: CTO/CISO, platform engineering, security architecture, and product owners
Edition: 1.0 · 21 October 2026
Status: Implementation reference; production adoption remains conditional on the validation gates below.

Scope assumption. An AWS-hosted business application serves multiple customer tenants through agents. Tenants may share platform infrastructure, but identity, entitlements, records, approvals, and evidence must remain tenant-scoped. The design prioritizes MCP business tools. HTTP passthrough and Runtime routes require separate enforcement verification. No particular AWS Region, database, identity provider, or regulatory regime is assumed.

Evidence notation. [FACT] identifies behavior supported by retrieved official AWS documentation. [CONTROL] identifies this paper’s recommended application or operating control. [GATE] identifies evidence required before enabling a deployment capability. User-supplied research snapshots are marked [INPUT SNAPSHOT], rather than represented as a current service commitment. Architecture diagrams are conceptual recommendations, not verified deployed systems.

Executive summary

Adopt Amazon Bedrock AgentCore Gateway as a managed entry point for governed tools, provided the application retains authority over tenant context, record access, human approvals, and transaction completion. Centralizing tool access makes a consistent enforcement surface possible. It does not make a multi-tenant application safe by itself.

The recommended decision is conditional approval for read-only tools, followed by reversible writes and then narrowly bounded consequential actions. Every production tool must have an accountable owner, an explicit risk tier, a versioned schema, tested authorization, a tenant isolation contract, and a containment mechanism independent of rate limiting. A consequential write must additionally carry an approval bound to its exact intent and an idempotent execution record.

Three conditions determine whether this design is credible. First, trusted tenant identity must come from validated token context and reach a backend that independently enforces tenant-scoped access. Second, Gateway policy must remain enforcing, with permissions to weaken it tightly controlled. Third, business success must be demonstrated by a durable business transaction, rather than inferred from an allowed tool call or a successful transport response.

The platform should refuse production promotion where identity propagation, bypass prevention, or write reconciliation is unproven. It should also avoid claiming uniform protection across target types: current AWS documentation limits the described Policy evaluation to MCP tools. The adoption decision is therefore a decision about a verified route, target, credential, and application control combination, not simply the presence of a Gateway resource.

Table of contents

1. Executive decision and scope

[CONTROL] Decision: use Gateway for centralized tool connectivity and eligible policy enforcement; make backend authorization and business correctness mandatory dependencies. The CTO owns delivery accountability, the CISO owns security risk acceptance, and product owners define acceptable business authority. None can delegate transaction correctness to the model.

The initial scope is tenant-scoped retrieval and bounded business workflows. Arbitrary SQL, generic shell execution, unrestricted URL fetches, unconstrained administration, and tools that accept a tenant identifier as authority are excluded. An exception requires a redesigned capability with enforceable limits, not a warning in its description.

Five invariants govern release:

1. Every data access derives tenant scope from authenticated, validated context.
2. Every business action is authorized again against current backend state.
3. Production policy enforcement cannot be weakened by ordinary tool authors.
4. A retry cannot multiply an approved business effect.
5. A responder can stop dangerous actions without depending on consumption throttles.

These invariants remain necessary when prompt filtering is deployed. Retrieved documents, tool responses, and user prompts are untrusted inputs; instructions within them do not create business authority. A model can propose an action, but only deterministic controls can admit it.

[GATE] Executive acceptance: approve an explicit tenant isolation model, tool classes, financial exposure bounds, recovery objectives, and named operational owners. Missing owners or undefined recovery behavior block production. This paper supplies a control framework and design contracts; it does not claim that infrastructure, credentials, or policies have been deployed or tested in an AWS account.

2. Product boundary: Gateway and the application

[FACT] Gateway aggregates MCP targets and also supports HTTP targets. Its documented MCP integrations include Lambda, API Gateway REST APIs, OpenAPI, Smithy, and MCP servers; HTTP targets include Runtime agents and passthrough endpoints. HTTP routing does not provide MCP aggregation or semantic tool search. These distinctions matter when selecting an enforcement surface. AWS: Gateway core concepts

Figure 1 — Shared-responsibility boundary map. Gateway mechanisms support the control framework; the application owns business authority and data correctness. Editable draw.io.

[CONTROL] Treat the user-supplied characterization of Gateway as a managed tool control plane as an architectural shorthand. Gateway processes runtime traffic as well as exposing managed configuration. Neither its runtime mediation nor its control plane replaces application authorization, isolation, approval, or transactional code.

[FACT] The retrieved Policy integration guide explicitly applies Policy evaluation to MCP tools. It states that MCP prompts and resources are always allowed by this policy evaluation, irrespective of mode. Listing uses partial context; invocation uses actual parameters. AWS: Use Gateway with Policy

[CONTROL] Disable or withhold sensitive prompts/resources at the target unless independently protected. Inventory all exposed protocol methods. Do not extend the MCP tool policy claim to HTTP passthrough, inference, or Runtime routes without a documented, tested control path.

[GATE] Record supported authentication, private connectivity, timeout, payload behavior, and policy coverage for every selected target. A working connection is insufficient evidence of governed access.

3. Governance operating model and separation of duties

[CONTROL] Govern each tool as a production API with an additional agent misuse threat model. A small cross-functional tooling council should own standards and exceptions, while domain teams retain responsibility for business semantics. Review effort should follow potential harm, rather than the number of tools.

Figure 2 — Governance roles and separation of duties. Authors propose; independent reviewers approve; an automation identity releases approved artifacts. Editable draw.io.

Tool authors must not approve their own increase in authority or directly change production policy mode. Platform operators must not grant themselves business approval authority. Human approvers need domain entitlement, not infrastructure administration rights. Release automation should validate that the submitter, reviewer, and releaser satisfy separation rules.

The release packet contains catalogue metadata, schema digest, policy digest, test results, backend revision, dependency versions, region/account, approval records, and rollback instructions. Preserve it outside the model context. An exception contains a bounded scope, owner, expiry, review date, and a technical withdrawal mechanism.

[GATE] Before production, test the identities themselves: a tool author cannot update Gateway; a release role cannot silently bypass review; an ordinary operator cannot access approval secrets. Schedule recurring access reviews and remove orphaned tools when their owners leave. A diagram of separation is not evidence that IAM permissions enforce it.

4. Reference architecture and trust boundaries

[CONTROL] Use separate administrative and runtime paths. Administrative changes enter a reviewed infrastructure/policy pipeline. Runtime requests pass through an application identity boundary, agent orchestration, Gateway, a constrained adapter, and the domain backend. The domain backend is the final authority for tenant scope and business state.

Figure 3 — Multi-tenant trust and data flow. Private ingress and target egress are different network segments; trusted context crosses each boundary through a verified mechanism. Editable draw.io.

At the caller boundary, validate identity and resolve active tenant membership. At the model boundary, distinguish proposed arguments from trusted identity. At Gateway, authenticate the inbound caller and evaluate eligible tool policy. At the target boundary, authenticate the workload and obtain independently trustworthy tenant/delegation context. At the data boundary, scope each query and mutation to that tenant and its entitlements.

For a shared service credential, the backend sees the adapter’s identity, not automatically the original user. The adapter therefore needs an application-owned context mechanism, such as a short-lived signed assertion or an opaque reference resolved over an authenticated channel. This is a recommended design, not a claim that Gateway automatically creates or transports such an assertion. Strip caller-supplied headers with the same names and verify the transport for the chosen target.

[FACT] AWS documents PrivateLink interface endpoints for Gateway ingress. Separately, Gateway VPC egress uses target-specific connectivity; private MCP and OpenAPI resources can use privateEndpoint with VPC Lattice. AWS: Interface endpoints, AWS: Gateway VPC egress

[GATE] Draw and test both directions: caller-to-Gateway and Gateway-to-target. Validate DNS, TLS trust, security groups, endpoint policies, and public reachability separately. An interface endpoint’s existence does not demonstrate that all ingress must use it. Test disallowed public and alternative routes explicitly. Choose pooled, tenant-cohort, or dedicated infrastructure based on contractual isolation and measured operational overhead, with tighter blast-radius partitions for high-impact tools.

5. Identity, authentication, delegation, and trusted tenant context

[CONTROL] Tenant identity originates in validated token context. For users belonging to multiple tenants, a trusted authorization service validates the selected membership and issues or binds the active-tenant context. Never treat a tenant ID in model arguments, an unverified header, a session ID, or a retrieved document as authority.

The platform context contract should include an opaque subject, tenant, calling workload, delegated scope, issuer, intended audience, expiry, unique request identity, and an authorization-context version. Bind it to the requested operation where feasible. The model receives only the fields necessary for planning; it cannot mint or modify authoritative context.

[FACT] AWS documents JWT and SigV4 inbound patterns, including offloaded authorization modes. The detailed inbound guide specifies that AUTHENTICATE_ONLY validates SigV4 identity without making an authorization decision. This detail is more precise than the general concepts page’s description. The same guide warns that JWT subject information can appear in CloudTrail. AWS: Inbound authorization

[CONTROL] Use opaque subjects; validate issuer, audience/client restrictions, signature, expiry, and required scopes using the selected authorizer configuration. Document key rotation and revocation behavior. Reject missing tenant membership at the application boundary even when the token is otherwise valid. For IAM callers, map an authenticated workload to permitted tenant operations through trusted service authorization; a workload role alone is not tenant authority.

Choose delegation deliberately:

• A service credential represents platform authority. Limit it to adapter operations; carry user and tenant context separately and verify it at the backend.
• A delegated user credential must have a target-specific audience and bounded scope. Confirm token exchange or delegated OAuth support for the actual target before selecting it.
• A scheduled agent needs a named tenant service principal, explicit mandate, expiry, and revocation path. It must not impersonate an absent user by copying an old session.

A session groups interactions; it does not prove tenant ownership. Persist the binding between application session, principal, and tenant in trusted state. Reject session reuse across tenants. Re-evaluate membership and business entitlement at execution, especially after a human approval delay.

[GATE] Demonstrate expired-token rejection, wrong audience, wrong issuer, missing/ambiguous tenant, revoked membership, confused deputy attempts, forged headers, and cross-tenant session reuse. Capture what the backend actually receives for each integration. Where propagation is unsupported, introduce a constrained adapter or defer the target; do not accept a model-populated context field as a substitute.

6. Tool catalogue governance: risk tiers and change control

[CONTROL] Maintain a versioned catalogue independent of discovery results. Each entry specifies owner, business purpose, target identity, schema version and digest, required scopes, tenant-context mechanism, data classes, side effects, approval rule, idempotency contract, operational limits, runbook, and retirement date. A tool description is reviewed executable influence: it affects model selection and must not embed credentials or tenant-sensitive examples.

Figure 4 — Tool risk-tier promotion workflow. Failed evidence returns a tool to remediation; an authority expansion triggers reclassification. Editable draw.io.

Classify by worst credible effect, including bulk extraction and downstream automation. A read tool exporting an entire customer dataset can deserve T3 controls. Prefer business-specific verbs with constrained fields over generic REST, SQL, or administration wrappers. Narrow tools improve enforceability but increase catalogue maintenance; use shared implementation libraries without exposing unrestricted generic capabilities.

Treat argument additions, endpoint changes, widened enums, relaxed bounds, output-field additions, credential changes, and tool descriptions as reviewable changes. A syntactically compatible change can still expand authority. Pin the schema-policy-backend tuple in a release manifest. A new schema must regenerate or revalidate its policy bindings before release. Keep old versions only with named consumers, deprecation dates, and equivalent controls.

[GATE] A production catalogue entry must match deployed target configuration and actual discovered capabilities. Detect unexpected additions and fail promotion on drift. For external MCP servers, rehearse capability changes and credential revocation. Unknown tools stay quarantined until classified; automatic synchronization must not become automatic business approval.

7. Cedar policy lifecycle: observation to enforcement

[FACT] Policy in AgentCore uses default-deny and forbid-wins semantics. Its Cedar schema is generated from Gateway tool definitions and is used for validation. This supports tool-level and parameter-aware authorization, but policy validation does not prove the application’s business rules. AWS: Policy core concepts

[CONTROL] Begin with no broad permit. Permit identified principals to named tool actions under bounded conditions; add explicit forbids for containment and non-negotiable prohibitions. Generate actual entity/action identifiers from the deployed schema. Do not copy illustrative Cedar identifiers into production without checking them.

Maintain a decision specification before writing policy:

[FACT] Discovery can show a tool when some circumstances would allow invocation; it lacks the full call context. Visibility is therefore not a promise that any specific call is authorized. AWS: Use Gateway with Policy

Figure 5 — Cedar policy lifecycle from LOG_ONLY to ENFORCE. Production enforcement stays active while replacement policy is validated. Editable draw.io.

[FACT] Gateway-level LOG_ONLY records decisions without enforcing them. ENFORCE applies decisions. A principal with bedrock-agentcore:UpdateGateway can weaken mode or remove the policy engine; AWS documents no separate mode-specific action or condition key. Restrict that permission accordingly. AWS: Policy enforcement modes

[CONTROL] Run initial LOG_ONLY observation on an isolated gateway with synthetic data or backend restrictions sufficient to contain every call. Never expose consequential production tools merely to observe policy. Promote only after positive and negative cases match the decision specification, discovery is checked independently, and no unexplained mismatch remains. Use an ENFORCE canary before broad rollout.

[FACT] AWS also documents policy-level LOG_ONLY versus ACTIVE, distinct from the Gateway-level mode. A policy in observation does not contribute to the enforced decision. AWS: Test a policy in LOG_ONLY mode

[CONTROL] Keep these two controls explicit in manifests and dashboards. Validate newly observed policies without demoting the entire production gateway. CI must cover allow, no permit, forbid overlap, boundary values, absent attributes, type mismatch, schema drift, tenant spoofing, and direct invocation without listing. Test the deployed route as well as policy logic.

Break-glass authority is short-lived, independently approved, and session-audited. Its normal action is adding a narrow active forbid and disabling the backend operation. Roll back to a tested enforcing release; do not use LOG_ONLY as routine incident recovery. [GATE] Prove effective denial with a synthetic probe and backend evidence before declaring containment complete.

8. Multi-tenant data isolation and network bypass prevention

[CONTROL] Enforce tenant scope in the backend repository layer, not only the tool wrapper. For a relational store, every tenant-owned lookup and mutation includes a trusted tenant predicate; database row controls can add defense in depth where appropriate. For key-value stores, tenant scope belongs in enforced key construction and access design. Object retrieval verifies tenant ownership before returning content or issuing access URLs. Never retrieve globally and filter only after results enter the model context.

The following is conceptual backend pseudocode, not an AWS API or drop-in implementation:

context = verify_trusted_context(authenticated_channel)
require context.tenant and current_membership(context.subject, context.tenant)
reject_authority_fields(arguments, ["tenantId", "subject", "roles"])
record = repository.get(tenant=context.tenant, id=arguments.recordId)
require business_entitlement(context, action, record)
execute_with_state_and_idempotency_checks(context, record, arguments)

Use the same discipline for caches, conversation history, retrieval indexes, embeddings, batch jobs, export files, error bodies, and evidence queries. Cache keys include tenant and relevant entitlement/version context. Pagination tokens and export references must be integrity-protected and tenant-bound. Global search indexes require pre-retrieval authorization filters or a demonstrably equivalent isolation design.

Block the agent workload’s direct database access and unnecessary backend credentials. Restrict the backend to approved authenticated callers and operations. For shared administrative APIs, separate the agent-facing adapter from operator access and log both paths. A private address alone is not sufficient: another workload in the VPC may still be able to invoke it.

[FACT] AWS’s VPC egress guide describes different paths for MCP/OpenAPI, Lambda, Smithy, and API Gateway, including private endpoint arrangements and integration-specific limitations. Support must be checked against the chosen target rather than generalized across all targets. AWS: Gateway VPC egress

[GATE] Demonstrate denial from the agent runtime directly to the backend, from an unrelated workload, and through old endpoints, alternate DNS names, function invocation APIs, and exported credentials. Test public access from outside the VPC. Verify a normal approved request still succeeds after bypass restrictions. Where a legacy backend cannot enforce tenant scope, put a narrowly privileged adapter in front and assess whether its service credential can still expose excessive data; otherwise use a dedicated tenant deployment or defer onboarding.

9. Human approval, idempotency, and consequential writes

[CONTROL] Human approval authorizes an exact business intent. It must not be a conversational “yes,” a model-generated flag, or a reusable bearer token visible to the model. The approval service resolves the target record, normalizes arguments, calculates the intent digest, and presents a human-readable summary from those same normalized values.

An approval record binds tenant, initiating subject/workload, approver, tool and schema version, normalized arguments, target business record/version, amount/currency where relevant, expiry, nonce, and permitted execution count. The approver must have current authority over that tenant and business action. Require a different person for high-impact requests where separation of duties demands it. If arguments, recipient, currency, record version, or material context change, invalidate the approval and request a new one.

Figure 6 — Consequential-write approval and idempotency state machine. An unknown outcome enters reconciliation rather than a blind retry. Editable draw.io.

Use a server-generated idempotency key scoped to tenant and business operation. Store the request digest with a durable execution record. The same key and digest returns the recorded outcome; the same key with a different digest is rejected. Concurrent workers must compete through an atomic claim or conditional state transition. A model-supplied fresh key must not bypass business duplicate detection.

For local database writes, commit the business change and execution result in the same transaction where possible. For external systems, persist the execution intent before dispatch and use the provider’s idempotency mechanism if verified. An outbox can coordinate durable dispatch, but it does not by itself eliminate duplicate external effects. Reconcile unknown outcomes by provider transaction reference and business invariants. If the provider lacks a reliable duplicate guard or outcome query, keep the operation manual or accept a specifically documented residual risk.

Consume approvals and execution rights through a durable protocol. A crash after dispatch must preserve enough state to distinguish “not sent” from “possibly committed.” Exactly-once business outcomes cannot be inferred from Gateway delivery or transport success. Compensating actions require their own authorization, audit record, and often approval; they are not automatic erasure of the original effect.

[GATE] Inject duplicate delivery, concurrent retries, worker crashes before and after commit, approval expiry, entitlement revocation, and a lost success response. For every case, prove the number of business effects and the returned status. No consequential tool is released with an unbounded UNKNOWN state or an undocumented manual resolution owner.

10. Audit evidence, observability, data handling, and retention

[CONTROL] Build an evidence chain that answers who initiated an action, for which tenant, under which authority, using which released tool/policy, with which approval, and with what durable outcome. Use opaque correlation identifiers; do not use raw tokens or personal identifiers as trace IDs. Validate or replace incoming trace headers so an attacker cannot join another tenant’s evidence stream.

Figure 7 — Evidence trace from caller to business transaction. Service traces and application transaction evidence are complementary records. Editable draw.io.

[FACT] AWS publishes Policy invocation metrics and exposes additional spans when Gateway tracing is enabled. Documented fields include authorization decision, determining/mismatched policies, engine identity, and mode; policy spans are available in aws/spans. AWS: Policy observability data

[CONTROL] Extend these records with application-owned tenant reference, deployment manifest digest, tool/schema version, normalized intent digest, approval ID, idempotency key reference, backend transaction ID, and terminal outcome. Do not assume every application field is generated by AWS. Persist policy content and deployment history so an investigator can reconstruct the effective policy instead of relying on a mutable identifier.

Record denials and anomalies without indiscriminately copying arguments or results. Store a redacted summary and cryptographic digest for sensitive intent; put any necessary full evidence in a separately protected store. Hashes prove equality under a defined normalization, not lawful processing or confidentiality; low-entropy sensitive values can still be guessed. Separate operational dashboards, forensic access, and tenant-facing audit views.

Define retention by data class and purpose: security decision evidence, business transactions, approval records, debug traces, payload samples, and backups may need different schedules. The data governance owner approves durations and deletion/legal-hold rules; this paper specifies no universal duration. Validate encryption, key access, export destinations, regional processing, log subscriptions, replication, and support access arrangements for the actual deployment.

[GATE] In a staging tenant, insert recognizable synthetic sensitive data and inspect every enabled log/trace/export sink. Prove redaction, least-privilege evidence access, retention expiry, and preservation under approved hold. Verify complete correlation for consequential transactions without relying on sampled tracing. If a mandatory business journal is unavailable, reject new consequential writes or durably queue them under a reviewed design; optional telemetry loss alone should not silently corrupt business execution.

11. Cost, quotas, performance, and reliability guardrails

[FACT] Gateway rate limits can fail open when evaluation encounters documented errors, including service timeout or an unresolved dimension. They support consumption management rather than a dependable security boundary. AWS: Rate limit enforcement

[CONTROL] Use rate limits for fairness and backend protection. Use active Cedar forbids, credential restriction, and backend operation/tenant suspension for containment. Enforce financial caps and business operation counts atomically in the backend when exceeding them would be a security or business loss. Bound agent steps, fan-out, retries, tool response sizes, and wall-clock duration. Missing tenant dimensions should alert even if traffic proceeds.

The following numbers preserve the research inputs as planning snapshots. The retrieved AWS pricing page supports the listed price examples; deployment-specific applicability still requires re-verification. AWS: AgentCore pricing

Use C = I×pI + S×pS + A×pA + T×pT + G×pG + Cother, with counts and unit prices normalized consistently. At the snapshot rates, one million Gateway operations, 100,000 searches, one million authorization requests, 500 indexed tools, and 100 GB yield an illustrative $33.20 subtotal. This is arithmetic, not a quote. Add model inference, agent compute, adapters, storage, identity dependencies, network infrastructure, telemetry, security services, and external APIs. Do not assume one business request equals one billable Gateway or policy operation.

[FACT] Retrieved AWS quota documentation lists the following defaults, but account/Region configuration and adjustments must be checked. AWS: AgentCore quotas

[CONTROL] Measure p50/p95/p99 end-to-end latency by tool and tenant cohort, including authorization, adapter, database, and external dependencies. Use bounded exponential backoff with jitter for retryable reads; writes follow their idempotency protocol. Establish time budgets per hop and backpressure before dependency saturation. Test noisy-neighbor bursts and partial failures. A second gateway does not automatically increase an account-level quota.

[GATE] Approve a load-tested capacity envelope, cost per successful business outcome, quota headroom, dependency failure behavior, and an application SLO. Revalidate regional feature availability and any contractual SLA separately; this paper asserts neither an AWS SLA value nor a list of supported Regions.

12. Deployment lifecycle, acceptance tests, incidents, and recovery

[CONTROL] Deploy through reproducible infrastructure and versioned manifests. Separate development, staging, and production credentials and data. Resolve secrets at runtime through approved mechanisms; keep them out of schemas, policy repositories, diagrams, and model prompts. The release bundle identifies the tool schema, policy, adapter/backend image, authorizer, credential provider, network configuration, observability settings, and approved exceptions.

Before promotion, compare actual Gateway, policy mode, targets, role permissions, and advertised capabilities with the manifest. Reject unauthorized drift. Re-run security acceptance after any change to identity propagation, schema, network path, target auth, or business semantics. Canary by tenant cohort and risk tier, with observable rollback criteria; do not use customer writes as uncontrolled experiments.

Acceptance covers identity rejection, listing and direct invocation, tenant isolation, backend bypass, policy mode protection, schema drift, approval binding, duplicate execution, dependency outages, redaction, and evidence completeness. Success means both expected responses and absence of prohibited backend effects. A denied UI message with a committed write is a failed test.

Responders must verify effective denial at the backend, including already dispatched work and alternate routes. Credential revocation, policy changes, and cancellation may have different timing; measure containment rather than claiming an instantaneous kill switch. Preserve evidence before destructive cleanup and follow the organization’s notification process.

For disaster recovery, define RTO/RPO by service class with business owners. Restore infrastructure, schemas, policies, credential references, tenant mappings, approval records, idempotency journals, and transaction evidence. Check target readiness and regional feature parity before allowing traffic. Replication lag can resurrect consumed approvals or forgotten execution keys; fence the old writer and reconcile uncertain transactions before enabling new writes.

[GATE] Execute a recovery exercise using a separate environment and synthetic tenants. Prove that revoked access remains revoked, used approvals remain unusable, duplicate keys remain effective, and evidence can be correlated after restore. Missing regional functionality or insufficient execution-state recovery blocks automated write failover; a controlled read-only recovery may be acceptable if explicitly approved.

13. Rollout roadmap, decision gates, and final ADR

[CONTROL] Advance by evidence rather than elapsed weeks. Each phase has a named accountable owner and a go/no-go artifact. A failed gate keeps the previous safe scope active.

Figure 8 — Phased rollout decision gates and incident containment path. Every operational phase can enter containment; re-entry repeats affected acceptance gates. Editable draw.io.

ADR-001 — Adopt Gateway with mandatory application enforcement

Status: Proposed final architecture decision, ready for organizational adoption after gates pass; this document does not imply actual sign-off.

Context: A shared agent platform needs consistent tool access without allowing model arguments to establish tenant or business authority.

Decision: Adopt Gateway for eligible managed connectivity and MCP tool policy enforcement. Use validated tenant context, backend authorization, constrained target credentials, versioned tool/policy releases, approval-bound consequential actions, and durable idempotency/reconciliation. Keep production policy enforcing and maintain backend containment independent of rate limits.

Alternatives: Direct agent-to-backend access reduces mediation but disperses control and bypasses the selected evidence surface. A fully custom gateway allows specialized behavior but transfers protocol, credential, and policy integration maintenance to the platform team. Dedicated tenant stacks reduce some shared-infrastructure blast radius but increase deployment and operating cost. Choose dedicated cohorts where contracts or risk justify them; Gateway can remain part of that design.

Consequences: The platform gains a central tool boundary while retaining substantive application engineering obligations. Teams must fund catalogue stewardship, policy testing, approval services, transaction journals, and operational drills. Availability pressure cannot justify silently disabling authorization.

Acceptance: CTO/platform owner accepts operational cost; CISO/security architect accepts verified control design; product/business risk owner accepts bounded business exposure. Record dated sign-offs and evidence links in the implementation ADR. Reopen the decision after a material tenant-isolation failure, new target category, changed regional support, or an authority-expanding capability.

Conclusion. Gateway is a useful governance mechanism when it sits inside a complete control system. Production readiness is demonstrated by trusted identity, denied bypasses, bounded authority, correct transactions, and recoverable evidence. Those are the release criteria.

14. Implementation appendices

Appendix A — Tool onboarding checklist

[CONTROL] The domain owner supplies and the release reviewer verifies:

• Named owner, on-call, purpose, permitted tenant population, and risk tier.
• Narrow tool action; reviewed descriptions; input/output schema and digest.
• Target/auth/network compatibility record with selected Region and dated AWS sources.
• Trusted tenant/delegation mechanism demonstrated at the backend.
• Tenant-scoped queries, object access, caches, exports, and errors tested.
• Discovery, direct invocation, policy negative tests, and bypass tests passed.
• Write approval, duplicate handling, timeout/reconciliation, and business limits documented.
• Evidence fields, redaction, retention owner, alarms, and runbook verified.
• Capacity envelope, cost model, rollback, retirement plan, and release approvals stored.

Appendix B — Policy and change checklist

[CONTROL] Review authority changes, not only syntax:

• Compare schema, tool metadata, endpoint, credentials, and policy to the previous release.
• Resolve actual Cedar actions/entities from generated schema; validate missing/type cases.
• Test explicit permit, default-deny, forbid precedence, boundaries, and direct invocation.
• Verify discovery independently from argument-aware invocation and search exposure.
• Record Gateway mode and individual policy modes; keep production engine enforcing.
• Obtain independent review; restrict UpdateGateway and related administrative roles.
• Preserve tested prior enforcing artifacts; rehearse rollback and emergency forbid.
• Verify propagation with probes and backend effects; archive effective manifest and evidence.

Appendix C — Tenant-isolation acceptance matrix

[GATE] Use synthetic tenants A/B with overlapping record IDs and distinct secrets. Automate durable checks, not only response assertions.

Appendix D — Operational KPI set

[CONTROL] Establish baselines in staging and set approved targets before rollout. Zero prohibited business effects is a release requirement; latency and cost targets depend on workload.

Appendix E — Source register and bibliography

The following official sources were retrieved for this edition on 21 October 2026. Retrieval is a documentation review, not live account/Region validation. Titles below identify the actual consulted pages; repeated citations in the body refer to these same sources.

Appendix F — Mandatory pre-use validation record

[GATE] The platform owner maintains a dated register with account, Region/partition, tool/target, evidence link, reviewer, expiry, and pass/fail status for each item:

1. Reconcile the inaccessible research document before describing this edition as based on its full contents.
2. Confirm availability of Gateway, Policy, chosen target category, outbound auth/delegation, private ingress, private egress, and telemetry in each deployment Region.
3. Verify Cedar schema/action mapping, discovery/search behavior, invocation arguments, mode configuration, and non-tool/HTTP/Runtime authorization coverage.
4. Verify pricing meters, regional rates, billing treatment of list/search/failed/retried calls, network dependencies, and full-stack costs.
5. Verify effective quotas at both account and gateway scope, approved increases, payloads, concurrency, timeouts, and target limits.
6. Validate no-bypass controls, actual tenant-context propagation, and backend isolation using the acceptance matrix.
7. Validate telemetry payload contents, identity claims, redaction, retention/deletion/hold, residency, and forensic access.
8. Verify any applicable contractual SLA and support commitments directly; set an application SLO independently.
9. Rehearse containment propagation, in-flight execution handling, credential revocation, failover fencing, and restoration of approval/idempotency state.

Evidence limitations. No AWS account, Region, live quota, bill, IAM policy, deployed network, or runtime behavior was inspected. The Drive document was not accessible. Current AWS pages can evolve and sometimes describe features at different levels of detail; use the detailed target/API documentation and a tested regional deployment to resolve ambiguity. All controls, state machines, pseudocode, architecture choices, and numeric workload examples in this paper are recommendations or illustrations, not claims of native Gateway implementation or measured production results.