An agent should receive capabilities, not reusable secrets. This article proposes a boundary in which a trusted application component mediates requests, while raw MCP credentials, model-provider keys, and gateway credentials remain outside the agent runtime. This is a proposed architecture, not a universal security guarantee.
Map the custody boundary
MCP distinguishes a local STDIO deployment, where credentials may come from the environment or an embedded library, from a remote HTTP deployment that uses OAuth authorization. That distinction should influence where the application places its trusted broker.
For model traffic, treat the provider key and the gateway-authentication token as different credentials with different jobs. Cloudflare BYOK stores a provider key in Secrets Store for gateway use, whereas an authenticated gateway request supplies a separate gateway token.
Keep the controls independent
Credential isolation limits what the agent can read. Request mediation decides which requests it may ask a trusted component to make. Destination control constrains where that component may send traffic. Server-side token validation decides whether an authenticated operation is acceptable. Audit logging records the application-defined evidence needed to investigate decisions. Use these as separate controls: a weakness in one should not be treated as evidence that another exists.
- For remote MCP access, have the resource server check received tokens rather than accepting token possession as authorization. The MCP guidance calls for checks against the server’s configured constraints, including scope and audience or resource.
- Use established security libraries for token handling and authorization decisions instead of creating those mechanisms from scratch.
- Make secret redaction, task-state preservation, egress allowlists, and log retention explicit application policies. This article does not attribute those policies to either provider.
Decision table for a mediated runtime
The table is an illustrative application policy. “Reject” and “preserve” describe the proposed broker behavior, except where a row explicitly identifies documented server or gateway validation.
| Case | Credential owner | Mediation path | Destination policy | Server-side validation | Audit evidence | Rejection condition | Bounded application-owned action |
|---|---|---|---|---|---|---|---|
| Authenticated MCP operation | Authorization system and trusted broker; the agent receives no raw MCP token. | Agent request to broker, then broker to the registered MCP service. | Only a configured MCP resource is eligible. | The MCP resource server verifies token constraints, including required scope and its intended audience or resource. | Record request identity, requested tool, decision, correlation identifier, and redacted reason. | Validation fails or the tool is outside the approved capability set. | Deny the operation and retain the task state for review. |
| Authenticated model request through an API proxy | BYOK keeps the provider key in Secrets Store; no provider Authorization header is sent by the application. | Agent request to proxy, then proxy to the selected gateway route. | Only provider routes selected by the application are eligible. | When gateway authentication is enabled, a request lacking its required gateway-authentication header is rejected. | Record selected route or alias, decision, and redacted failure category. | The agent requests a raw provider key, an unavailable route, or a failed gateway-authentication check. | Do not reveal a credential; preserve a review record and return a bounded denial. |
| Approved unauthenticated network read | No credential is released to the agent. | Agent request to controlled egress, then egress to an approved public destination. | Allow only application-listed read-only destinations and methods. | The application applies its own destination and request-shape checks. | Record destination, method, policy decision, and redacted reason. | The host, method, redirect, or request size violates local policy. | Block the read and retain task state for review. |
| Raw-credential request or unapproved destination | Trusted secret store, authorization service, or broker; never the agent runtime. | No outbound mediation occurs after denial. | Raw-secret retrieval and destinations outside the allowlist are ineligible. | No downstream server call is attempted. | Record the denied capability request and a redacted policy reason. | The request asks for a secret or names a destination not approved by policy. | Fail closed, preserve task state, and surface the event to the application’s review process. |
Walk through a hypothetical prompt-injection failure
Hypothetical scenario: an injected instruction asks the agent to read an MCP token and send it to an unintended host. Under the proposed boundary, the runtime has no token to disclose, and controlled egress declines the host before a network request is made. Those are application-owned enforcement choices.
Assume an attacker instead presents a forged token to the MCP resource server. The MCP guidance says that receiving a token alone is insufficient; the server must validate it against applicable constraints. In this design, a failed check produces a denial, preserved task state, and redacted boundary evidence for investigation. This is a proposed response workflow, not a claim that any gateway automatically retains state or logs.
Choose between local and remote MCP paths
A local STDIO server can use environment-supplied credentials or credential support built into a library. That can suit a tightly controlled local process, but this article does not assume it isolates secrets from an untrusted agent; enforce that separation in the application design.
For a remotely hosted MCP service, the described OAuth path includes user approval in a browser and an authorization-code exchange using PKCE conventions. Prefer narrowly scoped, short-lived access tokens and production HTTPS where the selected authorization system supports those choices.
For model-provider access, gateway-held provider keys are one viable alternative to embedding provider keys in each application request. Keep the gateway credential separately scoped and protected, because storing a provider key through BYOK does not eliminate the gateway authentication step.
Review limits and change triggers
This design intentionally leaves destination allowlists, broker behavior, audit fields, retention periods, review ownership, and task-state storage to the application. Define fail-closed boundaries and escalation paths before assigning autonomous work.
- Reassess the design when an underlying source changes, is retired, or introduces an incompatible release.
- Confirm whether the MCP deployment is local STDIO or remote HTTP, then document credential ownership and validation rules for that transport.
- Review issuer or tenant, audience or resource, scope, expiry, and replay-handling rules for every protected MCP operation.
- Test the application’s own denial, redaction, retention, and review procedures separately; no execution or outcome is asserted here.