MCP-connected tools increase risk because they turn an AI workflow into a privileged integration path that can reach data and actions across multiple systems. If tokens, scopes, or authorisation are broad, one weak connection can expose more than the original application intended. The control question is whether each tool path is least privileged and revocable.
Why MCP-connected tools expand the attack surface
MCP changes a tool from a local helper into a live integration point. That matters because the tool is no longer just reading or transforming the prompt, it may be allowed to fetch data, call APIs, or trigger actions in connected systems. In practice, the security boundary moves from a single app to the tool path, its transport, its authorization model, and any downstream system the tool can reach.
That expansion is why MCP deserves the same scrutiny you would apply to any privileged integration. If the connection is broad, persistent, or hard to revoke, the tool inherits the trust of the application while widening the number of places an attacker or misconfiguration can touch.
For practitioners evaluating the protocol itself, the MCP authorization specification is the right baseline for understanding how server-side authorization is supposed to work, and why token handling must be explicit rather than assumed.
Why appsec risk increases when the tool can act on behalf of users
From an application security view, MCP-connected tools enlarge the blast radius of a single trust failure. A tool that can read sensitive context, exchange it with an API, and then write back into another system creates a chain of trust that is only as strong as the weakest step. If a tool is tricked, overloaded, or improperly scoped, the app can be induced to perform actions that would never be safe in a normal user flow.
The key failure mode is confused authority. The application may present a clean UI and a legitimate workflow, but the tool path can still bypass the intended guardrails if it is allowed to retrieve more data than needed, call functions the user should not directly reach, or pass tokens between systems without audience restriction. That is why authorization depth matters as much as authentication strength.
Appsec teams should treat this as an exposure problem, not a novelty problem. The relevant control question is whether every tool call is constrained to a narrow function, narrow dataset, and narrow context, or whether the integration can be repurposed once an attacker gains leverage anywhere in the chain. The broader the capability, the easier it is to turn a single compromise into data exposure or unauthorized action.
For implementation standards around authorization and access control, OWASP ASVS is the most direct external reference, and OWASP API Security Top 10 is useful whenever the tool reaches APIs that need object-level and function-level authorization.
Why IAM risk rises when broad tokens meet multiple systems
MCP-connected tools often sit at the intersection of identity, delegation, and secret handling. If one token, key, or client credential can access several back-end systems, the tool has effectively become an identity concentrator. That is useful for automation, but it creates a fragile trust design: compromise one credential, and the attacker may inherit access across every system that trusts it.
The IAM problem is usually scope, duration, and revocability. If tokens are long-lived, over-scoped, or reused across tools and environments, the identity boundary becomes porous. The practical result is that least privilege is no longer enforced at the application boundary, only hoped for inside the tool chain.
This is also where non-human identity discipline becomes important. The tool path should be treated like any other high-value integration identity, with explicit ownership, rotation, environment separation, and a clean offboarding path when the connection is retired. If those basics are missing, the AI layer is just another way to move a broadly empowered credential through the estate.
For deeper identity guidance, the MCP Security Guide is directly relevant because it focuses on token passthrough, local server credentials, and gateway patterns, while the Cloud Workload Identity Guide helps when the underlying access model depends on short-lived, workload-scoped credentials rather than static secrets.
Risk and Threat Considerations
MCP-connected tools are attractive to attackers because they concentrate access. A single weak integration can expose sensitive context, amplify a phishing or prompt-injection style compromise into downstream action, or provide a reusable credential path into systems the user never intended to open. The danger grows when tools inherit broad permissions from a central service identity or when revocation is slow.
Failure mechanism: the tool becomes a privileged intermediary with more reach than the original application, so a compromise, mis-scope, or token leak can be reused across systems and actions.
Impact: attackers can exfiltrate data, trigger unauthorized changes, or move laterally through connected services using the trust already granted to the tool path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | MCP tools can overreach if tool actions are not tightly authorized. |
| Recommendation — Enforce object and function authorization on every MCP tool action. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Tools often call APIs, and broad tool access can bypass intended function checks. |
| Recommendation — Restrict tool-triggered API actions to the exact functions each identity may use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MCP risk often depends on token scope, lifecycle, and revocation hygiene. |
| AC-6 — Least Privilege | Least privilege is the core control for preventing tool paths from becoming overpowered integrations. | |
| Recommendation — Rotate and revoke tool credentials promptly, and limit their lifetime and reuse. Minimise each tool's permissions to the smallest set needed for its task. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | MCP-connected tools behave like non-human identities when they hold broad permissions. |
| Recommendation — Right-size tool identities and remove unnecessary cross-system access. | ||
Practitioner Guidance
What to verify: confirm that each MCP tool has its own narrowly scoped identity or delegated token, and that the token cannot be replayed against unrelated services. If the same credential can reach multiple systems, treat that as a design flaw, not an optimization.
Decision rule: if a tool can read sensitive data and also invoke write actions, require explicit separation of duties or a tighter gateway before you approve production use. Read access alone is often tolerable sooner than write-capable access.
What good looks like: every tool path is least privileged, time-bounded, auditable, and revocable without breaking unrelated application functions. The operational test is whether you can disable one tool without disabling the whole AI workflow.
Practitioner takeaway: MCP is safest when treated as a constrained delegation layer, not as a convenience channel. The moment a tool can cross system boundaries with broad or durable authority, appsec and IAM risk rise together.