MCP Security and Authorization: A Practical Guide for AI Agents

MCP / 01

What MCP changes

Model Context Protocol gives AI applications a common way to discover and invoke tools and retrieve resources from servers. A server can expose a repository search, database operation, messaging action, issue tracker, infrastructure workflow or payment-adjacent service. That common interface helps teams reuse integrations, but it also makes the agent-to-tool boundary an important security boundary.

The protocol does not make every exposed capability safe or appropriate for every agent task. A capability being listed means the client can discover it; a successful connection means the client can reach the server. Neither fact says that this agent, acting for this task, may cause a particular downstream effect. The relevant unit for many security decisions is an operation with a target and parameters, not merely a server or tool name.

Consider a database tool that supports reading a customer record and changing an account entitlement. A single tool allowlist can treat both as permitted even though the second operation has a different consequence. An architecture that distinguishes them needs to understand the requested action at the point it can still be blocked.

• Tool visibility: what can the client discover?
• Connection access: may this client reach the server?
• Action authority: may this agent cause this exact effect now?

MCP / 02

A layered MCP security architecture

MCP security starts before a tool call. Secure deployment includes trusted server selection, protected credentials, transport security, validated inputs, careful tool descriptions and containment of untrusted content. The official MCP authorization specification describes transport-level authorization for HTTP-based MCP, while local stdio deployments use different credential patterns. Those controls establish a necessary baseline.

A useful architecture separates seven questions. Connection decides whether a client may reach a server. Identity attributes the client, workload, agent and task. Discovery controls visible capabilities. Authority establishes the originating permission and its delegated limits. Action control checks the exact operation, target and parameters at runtime. Execution records what the tool accepted or attempted. Verification reconstructs the decision and, where possible, observes the resulting state.

These questions may be answered by different components. An identity provider may authenticate a workload. An MCP gateway may route traffic, expose tools, apply policy and log requests. An application service or tool wrapper may understand the business semantics of an operation. A downstream executor may retain its own transaction and safety rules. The architecture should name which component owns each decision and where bypass paths remain.

MCP / 03

The trust boundary and its threat model

MCP servers and their tools can carry data, descriptions and instructions back into an agent’s context. Some content is untrusted even when it arrives through a legitimate connection. OWASP guidance discusses tool poisoning, misleading descriptions, over-scoped tokens, confused-deputy behavior, credential exposure and server trust. Prompt injection can induce an agent to ask for an unintended action. A compromised server or agent can attempt the same effect more directly.

The security design should not rely on the agent reliably identifying every malicious instruction. Treat the proposed tool call as a request requiring independent authorization. If the request attempts to send sensitive data, change an entitlement, release funds or modify infrastructure, a control near the effect should enforce the allowed operation, target and scope. This limits the authority available after an upstream error; it does not eliminate the upstream error or replace prompt-injection defenses.

Parameter manipulation is a particularly ordinary failure mode. The tool may be approved, but the request points to the wrong customer, repository, environment or beneficiary. Stale grants are another: the parent task was cancelled while a child waited in a queue. Approval replay can turn one human-approved action into several. Cross-agent delegation can widen permissions if a specialist inherits a parent’s full credential instead of a narrow grant.

Each risk asks for a different control. Validate inputs at the tool implementation. Keep secrets out of descriptions and outputs. Restrict server and tool trust. Carry attributable principal and task identity. Narrow grants during delegation. Re-evaluate at execution. Make high-impact approvals exact and replay-resistant. Record what was decided separately from what was observed. No authority layer should claim to replace all of these controls.

• Untrusted server, tool description or output
• Prompt-injection-induced tool use or compromised context
• Over-scoped token and credential leakage
• Confused deputy and privilege propagation
• Changed parameters, stale grants and approval replay
• Execution ambiguity after timeouts or retries

MCP / 04

Authentication is not authorization

Authentication answers whether a principal is who it claims to be. MCP transport authorization answers whether a client may access a server under the applicable transport model. Tool discovery answers whether a capability is visible to the client. None of these alone determines whether an agent has authority for an exact business action.

Suppose an expense-processing agent can connect to a server exposing lookup_invoice, validate_vendor, create_payment and release_payment. Its parent task delegates lookup and validation, plus create_payment up to $5,000. The agent requests release_payment for $4,200 to an approved vendor. The identity is valid. The connection is valid. The tool exists. The request must still be denied because release authority was never delegated. The approved vendor and in-range amount do not cure the missing operation grant.

This is why “the token has access to this tool” can be too coarse. A tool may contain multiple operations or accept parameters that determine the actual consequence. A useful runtime decision asks: who is acting, on whose authority, for what purpose, using which operation, on which target, with what values, under which current policy and context?

MCP / 05

Agent identity and delegated authority

The workload running an agent and the logical agent serving a task are not always the same principal. A platform service credential may authenticate a request to an MCP server, while several agents share that service. If the downstream system sees only the platform credential, it cannot explain which agent and originating task caused the action. The architecture needs a trustworthy binding between workload, agent, task and grant.

An authority origin identifies the human or organizational decision that permitted the work. A parent agent may delegate part of that work to a specialist. The specialist grant should be no broader than the parent grant: narrower operation set, target set, amount, purpose, lifetime or delegation depth. A child cannot acquire payment-release permission from a parent that lacks it. The same rule must apply even when the child invokes a tool through an MCP server that itself has powerful service credentials.

Delegation also needs lifecycle semantics. A grant should expire, be revocable and identify whether sub-delegation is allowed. If multiple children draw on a shared budget, issuing each child the full parent limit can multiply actual spending. A common counter or reservation mechanism may be required. If a parent is revoked, an unexpired child token should not continue to authorize action merely because its own timestamp has not passed.

The decision record should preserve both ends of the chain: the last acting principal and the first authority origin. A reason such as “parent grant revoked” is materially more useful than a generic permission error. It explains the result without exposing secrets or giving the agent a bypass path.

MCP / 06

From tool-level to parameter-bound authority

A tool-level rule can be a helpful first filter, but the action decision should include the consequential parameters. Imagine transfer_funds is available to an agent. Its task grant permits transfers up to $10,000, only to Vendor A, only for Invoice 8274, and only before 15:00 UTC. The request is $8,500 to Vendor B. Tool access is YES and the amount is inside the ceiling, but beneficiary authority is NO. The decision is DENY.

Parameter-bound checks require a stable representation of the action. The PEP should know which fields change the consequence and normalize them before comparison. If the target account is hidden in a free-form payload, the policy decision cannot reliably enforce the beneficiary constraint. If an amount uses multiple currencies or units, normalize them with explicit conversion rules. Required fields that cannot be verified should not silently default to allowed values.

Purpose is also a constraint rather than a free-form excuse. A grant to update one customer’s entitlement for a support case does not authorize a broad migration, even if both use the same tool and target table. The purpose must tie to an attributable task, and the system should decide which purpose facts are trusted. An agent’s own natural-language assertion can be context; it should not manufacture authority.

For low-risk reads, the policy may allow a wider envelope. For writes, money movement, messages to external recipients or infrastructure changes, the envelope should describe the precise effect. The value of the model is its specificity: the same agent and tool can receive different decisions for different targets, parameters and moments.

MCP / 07

Human approval should bind to the exact effect

High-impact actions often require a human to approve a proposed effect. A broad approval such as “let this agent handle payments” can outlive the original task and permit different payments. A stronger approval names the principal, tool, operation, target, normalized parameters, amount or value, purpose and expiry. Where applicable, a unique identifier or nonce prevents the same approval from being reused after execution.

An approver should see the same meaningful details that the executor will receive. If the agent changes the beneficiary, increases the amount, swaps the repository or delays the action beyond the approved window, authorization should be evaluated again. Approval does not override a revoked parent grant or the executor’s own safety and transaction checks.

This is an architecture pattern, not a claim that a particular ProofGrid approval token or schema is published. Implementations must also protect approver identity, prevent substitution between review and execution, and distinguish an approval decision from an actual completed effect.

MCP / 08

Runtime enforcement, TOCTOU and revocation

A policy decision point (PDP) evaluates authority and policy. A policy enforcement point (PEP) stops or permits the request at a boundary that can still prevent the consequence. In an MCP deployment, the PEP might be in a gateway, tool wrapper, application service or downstream executor. The best location depends on whether it can understand the action and whether another path can bypass it. A PEP that logs the call after execution is not enforcing that call.

Time of check versus time of use appears when a job is queued or an agent pauses before invoking a tool. Authorization at task creation may have been valid then but stale now. A parent grant may be revoked, an approval may expire, an operating state may change or a policy may be updated. Re-evaluate at the last meaningful enforceable boundary before the effect, using the facts that must be fresh for that action.

Revocation is not simply deleting a token. A child grant may be cached; a queued worker may hold an old decision; a gateway and executor may see different state. Define propagation time, cache behavior and what happens during uncertainty. For high-consequence writes, unverifiable authority should fail closed. A carefully defined degraded mode may allow safe reads or status reporting while protected changes stop. “Degrade” must identify the remaining allowed action set rather than become an emergency bypass.

Retries need separate treatment. A timeout after a tool call may mean the executor accepted the action but the response was lost. Retrying blindly could cause a duplicate payment or change. Use idempotency where supported and reconcile the observed outcome before retry. An authorization receipt explains why an attempt was allowed; it does not prove that the downstream action happened exactly once.

MCP / 09

Execution receipts and observed outcomes

For each consequential request, capture the acting principal, task, authority origin, parent chain, tool, operation, target, normalized parameters, policy version, relevant context, decision and reason. If a human approved the action, link the exact approval. This is decision evidence: it explains why the request was permitted, denied, escalated or constrained.

Execution evidence answers a different question. The tool may return success, failure, timeout or an ambiguous acknowledgement. An observed outcome may arrive later from an independent system: a changed account state, a delivered message, a settled transfer or a physical controller’s status. Preserve those as distinct facts with timestamps and sources. Do not convert “tool accepted request” into “desired state verified.”

This separation helps operators investigate partial failure. An allowed command may be rejected by a payment network. A denied command should have no execution attempt; if it does, the enforcement boundary was bypassed. A command may execute but its final state remain unknown until reconciliation. Reviewable evidence should represent uncertainty honestly instead of completing a tidy but false narrative.

MCP / 10

MCP gateways and authority infrastructure

A gateway may centralize connectivity, routing, tool discovery, authentication, logging and policy enforcement. Those are useful functions. Some gateways can also evaluate operation-specific policies. The distinction here is not a claim that gateway products lack security features. It is a question about what authority evidence the decision has and whether that evidence survives delegation.

For a consequential action, ask where the permission originated, how it reached this agent, which constraints were narrowed at each handoff, whether the parent chain is still valid and what exact effect is requested. A gateway can be an effective PEP for that decision if it receives trustworthy action and authority context and cannot be bypassed. Another deployment may enforce in a tool wrapper or service closer to the effect.

ProofGrid is the authority and evidence layer around those decisions, integrating with identity, gateway and execution systems at the protected boundary. It does not replace protocol authentication, an MCP gateway or the execution system; the public architecture intentionally omits private interfaces and deployment details.

MCP / 11

A worked architecture example

An organization authorizes a procurement workflow to validate invoices and prepare payments for approved vendors. The parent agent receives that task with a $10,000 aggregate ceiling and a two-hour expiry. It delegates document extraction to one child and vendor validation to another. Neither child receives release_payment authority. A payment-preparation agent receives create_payment up to $5,000 for a particular invoice and beneficiary, but release requires exact human approval.

The agents authenticate through their runtime and connect to an MCP server exposing invoice and payment tools. The server can list release_payment, but discovery does not grant release authority. When the preparation agent calls create_payment for the correct invoice and $4,200 approved beneficiary, the PEP resolves its grant and current policy. If the parent remains valid and shared budget remains, the decision may be ALLOW. The executor can still reject the transaction for a domain-specific reason.

If that same agent requests release_payment, the decision is ESCALATE or DENY according to policy because the operation is not in its delegated scope. A human approval must refer to that exact release, not a generic permission for the agent. If the parent task is cancelled while approval is pending, a later release request is denied. The record preserves the grant chain, approval, decision, tool result and observed payment state separately.

This example is deliberately conceptual. The enforcement point could be a gateway or the payment service. The important properties are attributable identity, narrow delegation, a current decision at the effect boundary, no bypass to the executor and honest evidence of what happened.

Architecture / review method

Review six controls in request order

Model a consequential tool call as six linked boundaries, not as a single “MCP access” permission. Start with the accountable task and client identity; identify the protected MCP server; validate the token’s intended resource; classify the tool and normalized arguments; place enforcement at the downstream effect; and reconcile the observed outcome. The server’s tool catalog describes what is callable, while the authorization specification governs access to the protected resource. Neither independently grants the application’s permission to change a customer record or release a payment.

1. Origin: Name who authorized the task and which agent received it. A free-form prompt is not a trusted grant.
2. Transport: Use the MCP server’s protected-resource metadata and reject a token whose audience is another resource. Do not forward the client’s bearer token to a third-party API.
3. Tool definition: Record the server and tool-definition version. Treat descriptions and annotations as untrusted unless their source is trusted.
4. Action: Decide over the actual verb, target and normalized parameters after the model has chosen them. A read grant does not include a write simply because both operations share a server.
5. Enforcement: Confirm the executor cannot be reached by a second unguarded route. Bind the decision to the request actually executed.
6. Evidence: Separate ALLOW or DENY, executor response, and verified downstream state. On timeout, reconcile before retrying.

For example, an agent assigned to check one invoice can call a lookup tool but cannot invoke release_payment for that invoice. A gateway may reject the call early; the payment API should still require the relevant authority context at the last enforceable boundary. A changed amount or payee requires a fresh decision. ProofGrid authorizes the MCP action at runtime; this public pattern does not imply vendor endorsement or disclose a private interface.

Use the MCP threat model to test token confusion, tool poisoning, direct invocation and uncertain execution against this architecture.

Implementation / Checklist

Put the boundary into practice

This checklist is useful whether your PEP is a gateway, tool wrapper or domain service. Test each item with an allowed request, an out-of-scope request, a revoked grant and an unavailable dependency.

• Give each workload and agent attributable identity, task and owner.
• Separate MCP connection and tool visibility from action authority.
• Inventory tools and identify consequential operations and targets.
• Choose an enforcement point that can actually stop each effect.
• Carry authority origin and parent chain through every delegation.
• Narrow operation, target, value, purpose and lifetime at each handoff.
• Account for shared budgets across concurrent child agents.
• Bind high-impact human approvals to exact normalized actions.
• Expire temporary authority and propagate parent revocation.
• Prevent replay and reconcile uncertain retries.
• Re-evaluate changeable facts at the execution boundary.
• Fail closed for high-consequence actions with unverifiable authority.
• Define a limited safe DEGRADE mode when appropriate.
• Record decision, execution response and observed outcome separately.
• Test bypass paths, stale queues, missing fields and revoked grants.

ProofGrid / Role

How ProofGrid fits

ProofGrid connects authentication, authorization and audit to authority origin, delegated scope, runtime policy and execution evidence around MCP actions. It asks whether this principal may cause this exact effect now, then preserves why the decision was made and what followed.

ProofGrid does not replace MCP authentication, identity providers, secret management, prompt-injection defenses, gateways, EDR/XDR, SIEM or secure tool implementations. A deployment should place enforcement where the effect can actually be stopped and validate the available product interfaces for that environment. No shipped MCP gateway, public MCP API or finalized connector is asserted here.