Engineering Agent Authorization, Part 2: Where to Enforce AI Agent Permissions in Gateways, Tools, and Destination Systems

The tradeoffs between enforcing agent permissions in a gateway, a trusted tool, or the destination system, and what each one still cannot guarantee.

An agent’s permissions matter only if a trusted component checks them before data is released or a change is made. For platform and security engineers, the design question is where that check belongs: in a gateway, a tool service, the destination system, or a combination of them.

Part 1, Your AI Agent Needs More Than an API Key, explains how to scope and handle credentials. This article follows an authorized request through execution, failure and recovery.

TL;DR: Enforce each rule where it can prevent the protected effect, close bypass paths, and validate the operation that will actually execute. Both session-based and stateless Model Context Protocol (MCP) deployments need a trusted workflow state. Keep permission decisions, execution reports and verified outcomes distinct.

Consider an agent authorized to read invoice INV-1042 and create a review result. The component reaching storage must check the actual source, destination and write conditions.

Start with the effect and its possible paths

For the invoice workflow, define two effects: release one source version to an authorized reader, and create one result at an approved destination. The result must not overwrite the source or an existing result. Authorization should resolve the relevant tenant, resource and operation from trusted context rather than accept the model’s description of them.

Enumerate how the runtime could cause either effect. Include the intended tool, direct storage access, other installed tools, ambient credentials and retry workers. A gateway is useful only if the protected operation cannot bypass its checks. A trusted destination can enforce its own rules, provided the runtime cannot reach the underlying data through broader credentials.

Put a gateway in the path when it provides needed control

A gateway can authenticate the caller, validate an action capability and forward an approved request using a downstream credential held outside the agent runtime. A separate policy decision service may supply the decision. Envoy’s external authorization filter, for example, calls an HTTP or gRPC authorization service. [1]

The gateway must check the request that will execute. MCP 2026-07-28 exposes Mcp-Method, applicable Mcp-Name, and selected parameter headers for routing and policy. Servers processing the body must reject header/body mismatches. Header-based intermediaries should require a protocol version with that validation. Exact-action checks still need the relevant parameters; routing metadata alone is insufficient. Revalidate any transformation that changes the approved action. [12]

Protect downstream access with network restrictions, narrow credentials or destination verification of gateway identity. Strip untrusted provenance headers before adding trusted ones. A gateway-name header is not proof of passage.

A gateway centralizes credential custody and checks, but adds routing, availability and adapter dependencies. Payload inspection needs explicit rules, format support and tests. Sending bodies to a central policy service also expands its data access; a customer-side verifier can send bounded metadata where policy permits.

Enforce at a trusted tool or destination

A trusted tool service can validate authority immediately before reading or writing. For the invoice example, it resolves source version v7, checks the approved result identifier and uses a storage operation that cannot overwrite an existing result. The service can bind these checks to the actual API request rather than rely on the model’s account of its intent.

Destination preconditions help close races. Google Cloud Storage documents generation-match conditions, including value zero for creating an object only when no live version exists. A checked application boundary should enforce the precondition when the workflow requires it; merely hoping the caller supplies it is insufficient. [2]

Local validation keeps business rules near the effect, but distributes maintenance. Each adapter needs consistent caller validation, policy, replay protection and recovery. Shared libraries reduce duplication; rollout and compatibility still need owners.

For protected HTTP MCP, the server validates access tokens and their intended audience on every request; downstream access uses separately obtained credentials. Under the 2026-07-28 specification, the MCP client checks a returned authorization-response iss against the issuer recorded from validated metadata before redeeming the code. If issuer support is advertised, a missing iss must be rejected. Persisted client credentials remain bound to their issuing authorization server. These rules do not require a gateway. [3] [13]

A local wrapper is a boundary only if process isolation and credential custody prevent bypass. If the agent can edit it or use its broader credentials, the checks provide little protection.

Review tool definitions independently of execution authorization. MCP 2026-07-28 adds discovery cache hints (ttlMs, cacheScope); private results must stay within the same authorization context. Tool-change notifications still exist through an opted-in subscriptions/listen stream. Treat annotations from untrusted servers as untrusted. Pinning reviewed definitions detects descriptor drift, not unsafe implementation or results; a cached catalog grants no execution permission. [11] [14]

Use provider IAM for the restrictions it can express

A broker can issue a restricted provider credential and let runtime code call storage directly. The provider then evaluates access using its supported resource, action and condition semantics. This removes the application gateway from business-data traffic. It can suit reads whose required restrictions map cleanly to provider policy.

Provider IAM does not automatically interpret custom action digests, cumulative budgets or application block lists. Permission to create objects under a prefix may allow several writes. A rule requiring one specific result needs a trusted verifier or a documented native mechanism that expresses it.

Provider semantics also differ. GCP Credential Access Boundaries are limited to Cloud Storage. AWS session-policy evaluation must account for resource policies, including grants directly to role sessions. Azure shared access signature (SAS) behavior depends on its type and signing authority. [4] [5] [6]

• Gateway — Main advantage: Shared application checks and downstream credential custody. Main cost or limit: Routing dependency and adapter upkeep; bypass paths must be closed.
• Trusted tool or destination — Main advantage: Validation close to the actual effect. Main cost or limit: Every participating service must implement and maintain the contract.
• Provider IAM after brokerage — Main advantage: Direct data access with native restrictions. Main cost or limit: Delivered credentials retain provider semantics; custom rules need another boundary.

A gateway or trusted tool can obtain a restricted provider credential from a broker and retain it while executing the approved operation. If gateway checks are required, the runtime must not receive credentials that let it bypass them.

For the invoice workflow, native restrictions may suffice for the read, while the write needs application checks and a mandatory destination precondition. Choose each path by its required guarantees; MCP usage alone does not require a gateway.

Decide which checks require current shared state

Local validation cannot reveal a newly blocked workflow or a budget consumed by another worker.

• Signature, audience and expiry — Required input or guarantee: Local validation using trusted issuer keys and allowed algorithms; keep key material current.
• Workflow block status — Required input or guarantee: Authoritative state with an explicit freshness policy.
• Shared budget or one-use capability — Required input or guarantee: Atomic reservation in shared application state.
• Preventing an overwrite — Required input or guarantee: A destination precondition enforced by the trusted execution path [2].

OAuth token introspection standardizes querying a token’s active state and documents the freshness cost of caching. It does not reserve application budgets. [7]

These application guarantees apply across MCP versions. Earlier revisions use an initialization handshake and may use protocol sessions. MCP 2026-07-28 removes both; requests carry their own protocol metadata and cross-call state uses explicit application handles. Implement the behavior of each supported revision; MCP documents compatibility between them. [12] [13]

With either model, bind workflow identifiers to authenticated tenant and workflow authority, and keep budgets, blocks and reservations consistent across server instances. A handle or protocol session ID is not proof of ownership, and a new connection must not reset limits.

Freshness costs availability and latency. If an action requires an online check, an unavailable check must prevent admission. Cached allows require an explicitly accepted staleness window, age limit and invalidation policy; they do not provide immediate revocation.

Envoy’s failure_mode_allow, partial body buffering and route-cache changes affect enforcement. Check filter order and reject incomplete input where a full-body decision is required. Measure latency under realistic payloads, failures and concurrency. [1] [8]

Define what happens after access is blocked

For application-mediated execution, specify when a block becomes authoritative and which check admits an operation. Later admissions can be rejected after the verifier observes that state. Work that already passed admission may still complete. Cancellation, containment and repair of an existing effect are separate mechanisms.

For brokered provider credentials, disabling issuance prevents new credentials but leaves previously delivered ones subject to provider controls. AWS supports revoking older role sessions through a deny policy with a time condition. Azure documents user delegation key revocation and permission changes, with possible caching delays. Neither guarantees instantaneous revocation limited to one agent task. [9] [10]

Document who can block the workflow, which other sessions a provider action could affect, and how to verify that access has actually stopped. Emergency access changes must not rely solely on the component suspected of misbehaving.

Verify effects without confusing reports with facts

An authorization decision records permission. A reservation records an execution claim. A completion report records what a component says happened. An independent destination observation can corroborate the resulting state. Keep those records distinct and correlate them using a stable operation identifier, target version and suitable digest.

If a write succeeds but its acknowledgement is lost, preserve the business operation ID and query the destination or use documented idempotency. MCP 2026-07-28 removes stream resumption; transport retries use a new request ID. Multi Round-Trip Requests also use new IDs when supplying requested input. Those IDs must not become new business operations. Recheck authority on continuation. Report retries must not repeat the write. [12] [13] [11]

Asynchronous verification reduces synchronous dependencies but introduces delay and incomplete observation. Define coverage, lateness and discrepancy ownership. A missing report does not prove no write occurred; a matching report does not prove the assessment was correct. A durable outbox helps only when its record and the effect commit atomically; remote calls need separate recovery.

Keep raw invoice data and credentials out of central evidence when metadata suffices. A digest helps compare content; it is not encryption or a guarantee against guessing low-entropy data. Evidence access and retention still require deliberate design.

• Altered parameters or header/body mismatch — Expected behavior: Reject before the protected effect.
• Bypass attempt — Expected behavior: Alternate routes cannot skip required checks.
• Duplicate delivery or a new request ID — Expected behavior: Preserve business identity and prevent duplicate effects.
• Concurrent budget requests or a new connection — Expected behavior: Enforce the shared limit; connections do not reset authority.
• Required authorization check fails or is unavailable — Expected behavior: Deny admission.
• Write commits but acknowledgement is lost — Expected behavior: Recover using the original operation identity; keep unverified outcomes unresolved.
• Block after credential issuance — Expected behavior: Reject later application admissions once the block is observed; handle issued credentials and admitted work separately.

References

Primary sources checked October 22, 2026. MCP references are pinned to the July 28, 2026 specification. Envoy links describe its current documentation; verify configuration against the deployed release.

1. Envoy external authorization filter, including route-cache security considerations.
2. Google Cloud Storage request preconditions, generation-match conditions.
3. MCP authorization specification dated July 28 2026, token audience and downstream access.
4. Google Cloud Credential Access Boundaries.
5. AWS permissions boundary evaluation, resource policies for role sessions.
6. Microsoft shared access signatures overview.
7. RFC 7662 OAuth 2.0 Token Introspection, sections 2 and 4.
8. Envoy external authorization API, failure behavior and body buffering.
9. AWS revocation of role sessions.
10. Microsoft user delegation SAS revocation.
11. MCP tools specification dated July 28 2026, list changes and tool annotations.
12. MCP Streamable HTTP 2026-07-28, mirrored headers, validation and stream recovery.
13. MCP 2026-07-28 changes, stateless core, explicit handles and authorization hardening.
14. MCP caching 2026-07-28, freshness hints and authorization contexts.