Who Authorizes an AI Agent’s Next Tool Call in MCP?

Related resources:

Explore the agentic AI cybersecurity platform

Compare agentic security harnesses

Visit Amplify Security

An agent is investigating a SAST finding in a payments repository. It reads the relevant source file, retrieves a Jira issue, and prepares a proposed fix. Then it requests a tool call using an integration that holds an organization-wide credential.

The call may succeed. That does not mean it was authorized.

Who determined that this agent, working on this finding, could perform this specific operation on this specific resource?

Model Context Protocol (MCP) did not invent API-connected agents. It standardizes how AI applications discover and invoke tools, making it easier to connect workflows across repositories, issue trackers, and CI systems. The security problem is what happens when an available capability is mistaken for delegated authority.

Quick Answer

MCP security is fundamentally about delegated authority. Discovering a tool does not authorize its use, and a valid credential does not make every action permissible. Secure deployments verify the initiating identity, tool, resource, operation, and required approvals at enforceable boundaries. They also treat external content and tool descriptions as untrusted input, constrain downstream credentials, and record successful and denied calls.

A Tool Can Be Available, Authenticated, and Still Unauthorized

MCP clients can discover advertised capabilities through tools/list and invoke a tool through tools/call. Neither operation alone determines whether a specific developer has authorized access to a particular repository, or whether an agent may merge a pull request.

A connector may expose repository-reading and issue-creation tools. Its server might possess a token powerful enough to modify code across an organization. Availability and authentication say little about the scope of permission for the current task.

For an AppSec review, separate five decisions: who initiated the task; which tool may be called; which resource it may access; which operation is permitted; and what evidence records the decision and outcome. These decisions must be enforceable outside the model. A system prompt can guide behavior; it cannot implement a repository ACL.

AppSec Decision Lab 01: When a Tool Has Too Much Authority

Scenario: A developer authorizes a read-only investigation of the payments-api repository. The agent asks to read an in-scope file. But the MCP server has an organization-wide write-capable credential and no verified tool-level restrictions. The tool description says “read-only.”

Requested action: Read payments-api/src/checkout.ts.

Verification question: If the tool arguments change to another repository or a write operation, does the system deny the call even when the underlying token could execute it?

Trace the Authority Through an MCP Call

A useful way to review an integration is to follow the request from its initiating user to the system that performs the action:

Developer → AI host and MCP client → MCP server or execution broker → downstream API → repository, issue tracker, or CI.

Not every deployment has a separate broker. In smaller setups, the MCP server may be the enforcement point. In larger setups, an execution harness or gateway can add controls, but downstream services must still honor their own authorization rules.

Consider the seemingly simple request to read src/checkout.ts during a payments vulnerability investigation. At execution time, the system should establish the initiating principal; that the agent may use this tool; that payments-api and this path are in scope; that downstream credentials are appropriately restricted; and that returned source text cannot authorize a new operation.

A successful tool response establishes that execution worked, not that every authorization check happened. That distinction should be observable in tests and logs.

Failure Mode 1: The MCP Server Becomes a Confused Deputy

A confused deputy uses its own privileges to fulfill a request that the actual requester was never authorized to make. A server that brokers repository, cloud, or ticketing APIs can become such an intermediary when it executes every incoming request using a broadly privileged account.

Authentication to a remote MCP server and authorization by its downstream API are separate controls. The MCP server may know who connected but submit the downstream operation under a service identity with wider access. Unless the integration enforces delegated scope, the downstream service sees an authorized service account rather than the developer's actual constraints.

The official MCP security guidance also warns against token passthrough, forwarding an access token intended for the MCP server to a downstream API. Validate token issuer and intended audience for remote authentication, and use appropriately issued, narrowly scoped downstream credentials. Token validity alone is not proof that the requested repository or operation belongs to the task.

Local stdio servers have a different trust boundary. They may inherit host filesystem, environment, or network privileges from the developer workstation. Running without a public HTTP endpoint does not sandbox the local server process.

Design implication: Enforce permissions for the user, tool, resource, and operation before executing. Limit service credentials and local process privileges; preserve downstream ACLs and repository protections. If a user identity cannot be propagated to an upstream service, the intermediary must still check the delegated scope explicitly.

Failure Mode 2: Retrieved Content Tries to Become Authority

An agent may read a Jira description, pull-request comment, README, scanner result, or MCP response as part of a legitimate investigation. These are sources of task data, not instructions from the person who authorized the work.

An issue description might instruct the agent to switch repositories, call a different tool, or disclose sensitive configuration. This is an example of indirect prompt injection, where lower-trust content attempts to influence an agent's behavior. The security failure occurs when that influence results in an action the execution system should have prevented.

Filtering suspicious text may help. It cannot replace authorization on subsequent tool calls. Validate tool arguments, resource scope, and data destinations independently of the model's reasoning. Tool descriptions and schemas also merit review: malicious or changed metadata can steer tool selection despite apparently valid syntax.

AppSec Decision Lab 02: An Issue Tries to Expand the Mission

Scenario: The agent is authorized to read a security finding and prepare a proposed patch. A retrieved Jira issue contains text asking it to retrieve production credentials and transmit them to an external diagnostic endpoint. The developer never authorized this.

Requested action: Read a production secret and send it to an external address.

Verification question: Can an approved document or ticket cause an agent to call an otherwise permitted tool with an unauthorized destination or sensitive argument?

Failure Mode 3: A Valid Call Crosses the Wrong Approval Gate

Not every dangerous agent action is prompt injection. Some are simpler workflow-control failures.

A system may allow an agent to analyze a finding, generate a change, run tests, and open a pull request. None of those permissions automatically grants authority to merge the change. Passing CI shows that specified tests passed; it is not a substitute for protected-branch review.

Think about the workflow in four distinct stages: observe → propose → submit → approve or execute. Permissions should be scoped to the stage. A single broad “GitHub access” permission collapses distinctions the development organization already relies on.

The same separation is central to agentic security governance at scale: agents can investigate vulnerabilities and prepare fixes, while independent approval controls determine which changes are allowed to merge.

A generated security patch also needs security-specific validation. See our patch-validation analysis for why the root cause, proposed change, tests, and remediation evidence need to stay linked rather than treating a passing build as proof of a fix.

AppSec Decision Lab 03: A Green Build Is Not Approval

Scenario: An agent opens a pull request with a proposed security fix. All automated checks pass. The target branch requires a human review, but none has been completed.

Requested action: Merge the pull request into main.

Verification question: Can the same service credential merge without the reviewer? If so, what trusted enforcement point prevents the shortcut?

What Changed in the July 2026 MCP Specification?

The 2026-07-28 MCP release moved the protocol core toward stateless requests, introduced method/tool routing headers for Streamable HTTP, added caching hints for list results, and hardened elements of authorization. For example, gateways can use Mcp-Method and Mcp-Name for routing and operation visibility.

That is operationally useful. A method header is not a permission grant. The gateway can recognize a requested tool while still lacking the information required to decide whether a particular developer, repository, and action are authorized. Likewise, tool catalogs and self-reported client metadata should not be treated as proof of a trusted identity.

Use the security guidance for the MCP revision and SDK your deployment actually runs; systems built against earlier versions may have different lifecycle and session behavior. The protocol's authorization mechanisms do not replace downstream resource permissions or workflow approvals.

The Control Architecture: Enforce Before Execution, Prove Afterward

The system needs an authorization decision at the point where a requested action becomes a real API call or process operation. Notionally, that means checking identity, permitted tool, resource, operation, and any required approval, then executing using credentials that cannot silently expand those permissions.

The security property is not “our policy says agents should avoid that.” It is “the request failed at an enforceable boundary even though the model asked for it and an overpowered credential existed.”

A Small Test Plan That Reveals Large Permission Gaps

Do not begin with a generic AI safety prompt. Start with controlled tool calls and observe whether the real enforcement points behave as designed.

1. Inventory reality: record the MCP servers and tools used, how they are installed, the identities they use, the resources they can reach, and whether they run remotely or with local machine privileges.
2. Establish an allowed case: read one in-scope file or ticket through the approved identity and confirm the expected audit trail.
3. Vary one permission dimension: swap to another repository, change read to write, change the target project, or use a different initiating user. An out-of-scope request should be denied even if the underlying integration token would otherwise succeed.
4. Introduce controlled untrusted content: use a test issue or source file that instructs the agent to switch tools or access an unauthorized destination. Verify the downstream enforcement rejects that action.
5. Test approval and failure paths: attempt a merge without required review; try an expired token or unavailable authorization service. Verify the implementation fails closed where required instead of falling back to broader credentials.
6. Reconstruct the sequence: can a reviewer see the initiator, request, scope, authorization decision, approval state, and outcome without exposing tokens or unnecessary sensitive content?

The result should be a small body of verifiable evidence: allowed actions succeeded, forbidden actions failed, and the team can explain both. Counting blocked prompts alone would miss the controls that matter most.

Where This Fits in an AppSec Program

MCP is an integration protocol, not a replacement for authorization systems. Repository permissions, identity providers, secrets controls, protected branches, CI/CD rules, and reviewed deployment policies should remain the enforcement backbone.

The challenge for security engineering is coordinating work that spans those boundaries: detecting a vulnerability, collecting context, prioritizing the risk, proposing a fix, and establishing evidence before a change is accepted. Context helps decide what matters. Authorization decides what can happen next. Neither replaces the other.

This is a useful way to understand Amplify's broader focus on custom detection agents, context-aware investigation, and remediation workflows. Amplify Console is positioned around making security work executable and trackable across an existing stack. We are not claiming native MCP integration or a specific MCP policy-enforcement feature without product-team confirmation.

For related architecture, see Building an AI Agentic Security Harness and Secure AI Agent Execution Harness: Best Practices.

Frequently Asked Questions

Does MCP automatically enforce per-repository or per-file authorization?

No. MCP defines how clients and servers communicate; deployment-specific enforcement must still ensure that a caller can use the particular tool, operation, and resource. A valid credential or successful tools/call does not establish all of those decisions.

Is a tool marked “read-only” inherently safe?

No. A description or annotation expresses intent; it does not constrain the privileges of the process or the credentials underneath. Inspect the handler and enforce read-only resource policy, ideally with downstream credentials incapable of writing.

Why is an approved MCP server still a prompt-injection risk?

Approved servers may return untrusted repository or ticket text, and their advertised metadata may change. The issue is not only whether the agent recognizes malicious language; it is whether influenced tool requests are independently validated and authorized.

Doesn't OAuth solve the authorization problem?

OAuth can provide necessary authentication and scoped access for remote integrations, but token validity and scope do not automatically encode the allowed task, file, branch, or approval state. Validate issuer and audience, use appropriate downstream credentials, and enforce resource- and action-level policies.

What should security teams monitor?

Track allowed and denied actions by tool and resource, scope violations, changes to the tool inventory, approval bypass attempts, unusual data destinations, and whether audit evidence can reconstruct incidents. These are indicators of control effectiveness—not a claim that every hostile prompt was detected.

The Test That Matters

An agent that can find a vulnerability, read code, and draft a patch is useful. The more important test is what happens when that same agent requests an action the developer never delegated.

Does the system distinguish an available tool from an authorized action? Will it deny the request even if the connector has a powerful credential? Can an engineer explain the decision afterward?

Capability determines what an integration can do. Authorization determines what this agent may do now. Mature MCP implementations never confuse the two.

Explore how Amplify Console connects security context to investigation and remediation, or request access to discuss your AppSec workflows with the team.