Map the trust boundaries
Start with the client, every connected MCP server, the authorization service, and the business systems those servers reach. Record who operates each component and who can change its tool definitions or credentials.
A tool description is information supplied to the agent; it is not permission to act. A tool result may contain untrusted instructions. Decisions about payments, publication, deletion, or data access should remain bound to explicit policy and the applicable approval process even when retrieved content asks the agent to do something else.
Distinguish a model gateway from a tool gateway. Controlling access to an LLM does not by itself control a tool invocation made through another connection. Inventory both paths and the alternate credentials that could bypass them.
Deployment checklist
- Server ownership: maintain an approved server inventory, a named operator, and a review process for configuration changes.
- Client identity: identify the calling agent and any person whose authority it uses. Do not substitute a free-form model claim for authenticated identity.
- Token handling: validate the issuer, audience, expiry, and required scope for the chosen authorization profile; redact credentials from logs and errors.
- Downstream custody: specify where provider credentials are held, who can retrieve them, and how rotation and revocation work.
- Action scope: constrain the tool, resource, account, operation, and decision-relevant arguments. Read permission should not imply write permission.
- Approval: require the appropriate person to review consequential actions before execution; bind the approval to the exact request and expiry.
- Spending: reserve commitments on controlled payment paths. Reporting estimated token cost does not enforce a limit on a separate business payment.
- Evidence: retain the decision, applied policy, approval reference, and outcome status. Preserve uncertainty when the downstream result is unknown.
The official security guidance also covers threats including confused deputies and server-side request forgery. Use that guidance alongside this action-control checklist; this page is not a complete security assessment. MCP security best practices.
Try to cross the boundary in a test environment
Use a synthetic downstream service so you can confirm effects independently of the agent's response. Give the agent a read-only capability, then request a write. Attempt to change a resource after approval, call an unapproved tool, reuse an expired authorization, and invoke the provider outside the governed path.
For a retry test, let the downstream service accept a request but suppress its response. Check how the integration records uncertainty and whether a retry can produce a duplicate effect. For an outage test, stop the decision journal and inspect both new requests and already issued grants. A denial message is not sufficient evidence: inspect the downstream service to confirm what happened.
Capture these results in a workflow-specific acceptance record. An integration passing one client profile does not establish compatibility with every client, server version, or optional feature.
AAES support and limits
The AAES aaesmcp adapter exposes a documented stdio and POST-only HTTP profile. Its action controls apply to supported requests routed through AAES. A separate connection or an agent's direct provider credential can bypass that boundary.
AAES is pre-launch and customer-operated. Live tenant compatibility is evaluated during design-partner work. Consult the capability matrix and security statement for the supported scope. The offline verifier checks exported record integrity; it does not establish complete capture or independently prove the downstream outcome.
Primary sources and version scope
Reviewed September 24, 2026. Protocol claims above refer specifically to the 2025-11-25 authorization profile, not a claim that it is the latest version or that AAES implements every requirement.
Common questions
What is MCP security?
MCP security covers the trust boundaries between an AI client, MCP servers, authorization services, and downstream tools. It includes credential handling, permission checks, trusted server configuration, and validation of the actions that tools execute.
Does an MCP gateway make every tool call safe?
No. A gateway can enforce the traffic and credentials under its control. The operator must still address direct-call bypasses, the permissions held by downstream services, untrusted tool output, and the consequences of an allowed action.
Does AAES replace MCP OAuth?
AAES action governance and MCP transport authorization are separate concerns. The aaesmcp adapter supports stdio and a POST-only HTTP profile documented by AAES; that does not establish support for every MCP transport feature or authorization extension. Check the supported profile and validate the chosen client and authentication path.