MCP server security risks are broader than prompt injection

At a glance

What this is: This is an analysis of five MCP server security risks, showing that authentication, scoped permissions, token handling, and audit logging all need to be designed explicitly for agent tool access.

Why it matters: It matters because MCP changes how AI systems touch production data and services, and IAM, PAM, and NHI teams must govern the agent-to-tool boundary rather than treating it like a normal API.

👉 Read WorkOS's analysis of MCP server security risks and agent tool access

Context

MCP server security is not just API security with a new label. An MCP server sits between an AI client and production systems, exposes callable tools, and often defaults to no authentication, which means the trust boundary is the agent session itself rather than a human login flow.

For IAM and NHI programmes, that changes where control needs to live. The real problem is not whether the model is smart enough to use tools, but whether the server can prove identity, limit scope, and record activity when non-human access is invoked programmatically.

The strongest open question is governance, not syntax: who is allowed to call which tool, under what session conditions, and how would you reconstruct the event if the agent behaves badly? That is the point where MCP becomes an identity security issue, not just an integration pattern.

Key questions

Q: How should security teams govern MCP tool access in production environments?

A: Security teams should govern MCP tool access as delegated non-human identity, not as generic API traffic. That means authenticating every call, scoping tools to the current task, and revoking access when the session ends. If the server cannot prove who called what, the control design is too weak for production use.

Q: Why do MCP servers increase the blast radius of AI systems?

A: MCP servers increase blast radius because they often give an agent access to multiple tools for the full session, not just the minimum needed for one action. If a prompt injection or token leak occurs, the actor can move across connected systems far more easily than a narrowly scoped workload identity would allow.

Q: What do teams get wrong about audit logging for AI tool use?

A: Teams often log the server error but not the identity event. For MCP, the useful record is which agent called which tool, on whose behalf, with what arguments, and when. Without that detail, incident response and compliance review become reconstruction exercises instead of evidence-led investigation.

Q: Who is accountable when an AI agent misuses MCP-connected tools?

A: Accountability should rest with the team that defined the agent session, granted the tool scope, and accepted the downstream access model. If a tool can alter data or reach external services, governance must assign a named owner for the agent identity, the session policy, and the audit trail.

Technical breakdown

Unauthenticated tool access in MCP servers

Many MCP implementations expose tools with no identity check at all, even though the protocol expects OAuth 2.1. In practice, that means any client that can reach the endpoint may invoke server-side tools directly, bypassing any agent-facing guardrail that the application layer assumed would exist. The gap is structural because agents connect programmatically, so there is no browser-style authentication prompt to make the absence obvious. Once tool calls are public, the server is no longer mediating trusted non-human access; it is simply accepting requests.

Practical implication: enforce authentication at the MCP layer before any tool is callable.

Prompt injection through tool results

MCP tools often return text from emails, documents, rows, or web pages, and the model cannot reliably distinguish instructions from data once both enter the context window. That makes tool output a delivery channel for prompt injection, especially when the returned content is attacker-controlled or externally sourced. Sanitisation alone is not enough if the result still contains actionable instructions, because the agent may follow them as if they were part of the task. High-risk outputs therefore need schema constraints and approval gating.

Practical implication: treat every tool result as untrusted input and require approval before risky follow-on actions.

Excessive permissions and persistent token exposure

MCP servers often grant broad tool access for an entire session and may hold long-lived OAuth tokens so the agent can act across downstream services. That creates two related failure modes: excessive permissions expand blast radius, and persistent tokens turn one compromise into multi-service misuse. The server is effectively concentrating delegated authority in one runtime context, which is convenient but dangerous. Least privilege has to be expressed as session scope, service scope, and revocation scope, otherwise a single injected action can reach far beyond the original task.

Practical implication: scope access per task and avoid handing agents durable credentials they do not need.

Threat narrative

Attacker objective: The objective is to turn an AI tool bridge into a broad, hard-to-audit path into production systems and connected services.

1. Entry occurs when an attacker or untrusted client reaches an MCP server that exposes tools without authentication, or when a legitimate agent session is granted overly broad access.
2. Escalation occurs when the attacker leverages permissive tool scope, injected tool output, or persistent tokens to move from one harmless call to privileged actions.
3. Impact occurs when the agent or attacker modifies data, exfiltrates secrets, or executes unwanted actions across connected systems with poor reconstruction capability.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security exposes an identity control plane problem, not just an application hardening problem. The article is right to frame MCP as a distinct attack surface because tools are invoked by agents through a protocol boundary that sits between model output and production access. That means the security question is who or what is authorised to call a tool, not just whether the tool itself is vulnerable. Practitioners should treat MCP servers as non-human identity governors, not as ordinary APIs.

Identity and privilege abuse is the core failure mode when MCP defaults to broad session access. The server grants a connected agent access to all tools for the session, which is functionally the same as over-provisioning a service account with permanent privilege. OWASP NHI guidance and zero-trust thinking both point to the same problem: if the server cannot constrain scope at runtime, the blast radius is set before the task begins. The practitioner takeaway is that session design must follow privilege design.

Persistent credential custody is a single-point failure in agent-mediated workflows. When the server holds long-lived tokens for multiple downstream services, one context leak can expose several identities at once. That is not just a token management issue, it is a delegated trust concentration issue that turns one non-human runtime into a multi-system control failure. The implication is that credentials, like access, must be treated as task-bound rather than session-bound.

Missing audit structure means MCP incidents become unreconstructable identity events. If the server cannot state which agent called which tool, on whose behalf, and with what arguments, then governance, forensics, and accountability all degrade together. This is the point where machine identity discipline matters as much as application logging, because the audit trail is the control surface that makes non-human activity governable. Practitioners should not accept agent tooling that cannot produce an identity-grade log.

Trust in MCP is really about the trust chain between human intent, agent action, and service execution. The article shows that authentication, scoped authorisation, and audit logging are interdependent rather than optional layers. When one layer is missing, the others lose meaning because the server can no longer prove who acted, what was allowed, or whether the action fit the intended task. Teams should evaluate MCP as a delegated identity architecture, not a convenience layer.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, which leaves 48% with a blind spot for compliance and breach investigation.
• The broader governance lesson is in OWASP Agentic Applications Top 10, which helps teams map agent identity and privilege abuse to practical controls.

What this signals

MCP servers are forcing security teams to treat agent runtime access as a governed identity surface. The immediate programme change is not only about whether an API is authenticated, but whether a non-human actor can be bounded, observed, and revoked at session level. That becomes harder as AI adoption grows, especially when 96% of technology professionals already see AI agents as a growing threat, according to AI Agents: The New Attack Surface report.

Tool-call auditability will become a board-level evidence issue, not a logging preference. If the platform cannot explain which principal invoked which action, the organisation loses its ability to prove intent, contain misuse, and support investigation. Teams that already struggle to track agent access should prioritise architecture that ties tool use to identity rather than to a generic application session.

Session-scoped authorisation is the control concept that will separate credible MCP deployments from risky ones. It translates least privilege into agent runtime terms and keeps the access window aligned to the task, not to the life of the process. For teams building toward OWASP Agentic Applications Top 10 alignment, OWASP Agentic Applications Top 10 is the natural next reference point.

For practitioners

• Make authentication mandatory at the MCP boundary Require OAuth 2.1 or equivalent identity enforcement before any tool is reachable, and reject unauthenticated requests at the server rather than relying on client behaviour. This is the first control that makes tool access governable.
• Scope every agent session to the smallest useful tool set Grant only the tools needed for the current task, and revoke that access automatically when the session ends. Do not let a request for read-only work inherit write, delete, or admin operations.
• Stop handing long-lived tokens directly to agents Issue task-specific credentials with per-service revocation so one leaked context cannot be reused across Slack, GitHub, or data stores. Treat persistent token custody as a credential concentration risk, not an implementation convenience.
• Build an identity-grade audit trail at the MCP layer Log agent identity, user identity, tool name, sanitised arguments, response status, and timestamp so incidents can be reconstructed without guessing. If you cannot tie a tool call back to a principal, the control is incomplete.

Key takeaways

• MCP servers change identity governance by moving the control point from user login to agent tool invocation.
• The main security failures are unauthenticated access, overly broad session privilege, token concentration, and weak auditability.
• Teams should design MCP around authentication, task-scoped authorisation, and identity-grade logging before broad deployment.

Key terms

• MCP server: A server that exposes tools and data sources to AI clients through the Model Context Protocol. In identity terms, it is a delegated access layer that mediates what an agent can invoke, which makes authentication, authorisation, and logging essential controls rather than optional extras.
• Session-scoped authorisation: An access model that grants permissions for one task or session and removes them when the work ends. For agents and other non-human identities, this narrows the blast radius of a compromised runtime and keeps access aligned to the current purpose instead of the process lifetime.
• Identity-grade audit trail: A log record that can tie an action to a specific principal, context, and time. For MCP and other NHI systems, it must capture who or what invoked a tool, what was requested, what was returned, and whether the action stayed within approved scope.
• Persistent token exposure: A condition where long-lived credentials remain available inside an agent runtime for longer than the task needs. This increases the chance that one compromised context can be used across multiple systems, turning delegated access into a broader credential failure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by WorkOS: The security risks specific to MCP servers, and how to address them. Read the original.