MCP server security depends on purpose-built tool design

At a glance

What this is: This is a discussion of how to build agent-ready MCP servers and why tool design, scoping, and OAuth are the real bottlenecks.

Why it matters: It matters because IAM and NHI teams have to govern how AI agents reach production systems, and poor tool shaping turns authorization into a noisy, over-broad risk surface.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Stytch's discussion of MCP server design and agent authentication

Context

MCP changes the access model for software by letting AI agents call tools directly instead of forcing every action through a human dashboard. That shifts the identity question from whether an application has APIs to whether those APIs are intentionally shaped, scoped, and authenticated for machine use.

For IAM and NHI practitioners, the risk is not just more automation. It is a larger set of agent-facing entry points, each of which can widen the blast radius if tool definitions are bloated, authentication is weak, or sensitive actions are exposed without enough constraint.

Key questions

Q: How should security teams govern MCP servers used by AI agents?

A: Security teams should govern MCP servers as delegated access paths, not as generic developer tooling. That means limiting exposed tools, tying OAuth scopes to specific tasks, logging every agent action, and reviewing whether any tool grants more authority than the workflow requires. The governance unit is the action surface, not just the token.

Q: Why do MCP servers create new NHI security risks?

A: MCP servers create NHI risk because they let non-human actors reach production systems through a new, model-facing tool layer. If that layer is broad or poorly scoped, the agent can inherit more authority than a human user would reasonably receive, which increases the blast radius of a compromised token or misused tool.

Q: What do teams get wrong about OAuth for remote MCP?

A: Teams often treat OAuth as a login wrapper when it is actually the policy boundary for agent access. If scopes are too broad, refresh behavior is loose, or consent is poorly defined, the agent becomes a broad proxy rather than a constrained delegate. That turns a controlled integration into an over-permissive one.

Q: How can organisations reduce risk when exposing APIs to AI agents?

A: Organisations should expose fewer tools, not more, and make each tool narrower, more legible, and easier to audit. Multi-step workflows should be collapsed into one bounded action where possible, while response filtering should remove anything the agent does not need to finish the task. That reduces drift, repetition, and unnecessary authority.

Technical breakdown

Why OpenAPI-to-MCP translation often fails

A direct translation from OpenAPI into MCP usually produces too many tools, too much parameter noise, and long call chains that models struggle to reason through. OpenAPI documents are designed for developers and integrations, not for an agent deciding in real time which action sequence is safe and sufficient. When every endpoint becomes a tool, the agent sees breadth without guidance, which increases error rates and makes privilege scoping harder. The real issue is not whether the API is callable, but whether the tool surface is cognitively and operationally usable for an LLM-driven workflow.

Practical implication: Prune the tool set before exposing it to agents, and only surface actions that map cleanly to bounded operational tasks.

How OAuth and authorization shape remote MCP risk

Remote MCP servers still depend on ordinary web security patterns, especially OAuth, but the difference is that the client may now be an agent rather than a person. That means authorization has to tolerate machine-driven workflows, token exchange, and repeated tool invocation without assuming a browser-centric human journey. If auth is bolted on after the fact, teams end up with broad tokens, confusing consent boundaries, and weak assurance about who or what is actually acting. In practice, OAuth is not just a login mechanism here. It is the control point that determines whether agent access stays bounded or becomes ambient.

Practical implication: Treat OAuth design as part of the MCP security model, not as a wrapper around it.

Why one-shot tools matter more than long call chains

If a human developer would normally copy and paste several API calls from documentation to complete one task, that sequence should usually be collapsed into a single agent-facing tool. Long chains create brittle dependency points, more opportunities for scope drift, and more chances that the model will lose context between calls. That is especially important when the task involves production changes, sensitive data, or side effects that should not be repeated. A concise tool is not just easier to use. It is easier to govern, audit, and constrain.

Practical implication: Package multi-step workflows into fewer high-value tools so the agent does not assemble risky sequences on its own.

Threat narrative

Attacker objective: The objective is to convert agent access into over-broad operational control over production APIs, data, or administrative actions.

1. entry via overexposed or poorly shaped MCP tools that accept broad agent requests without strong scoping. Escalation follows when the agent receives tokens or permissions that cover more functions than the immediate task requires.
2. Standing privilege is then abused through long tool chains, verbose responses, or weak filtering that reveals more data or actions than necessary. Impact occurs when the agent reaches production systems with enough authority to change resources, move data, or trigger downstream actions at scale.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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 tool sprawl is becoming an identity problem, not just an API design problem: When every endpoint is surfaced to an agent, authorization no longer protects a small set of high-value actions. It has to govern a much larger runtime surface where the actor may choose tools dynamically and repeatedly. That means the security question is really about tool entitlement, task scope, and blast-radius control. Practitioners should treat MCP catalog design as part of identity governance, not only developer experience.

Least privilege is harder to define when the tool surface is model-facing: Traditional IAM assumes the request path is known and the action is reasonably legible. MCP breaks that comfort because the model selects among tools, parameters, and execution paths at runtime. The implication is that access reviews alone will not tell you whether the tool set itself is over-permissive. Practitioners need to govern the exposed action set, not just the token attached to it.

OAuth becomes the policy boundary for agentic access: In remote MCP, OAuth is not a convenience layer. It is the mechanism that decides whether the agent can act as a constrained delegate or as a broad proxy. If token scope is vague, consent is poorly shaped, or refresh behavior is loose, the identity layer silently expands the tool blast radius. Practitioners should therefore review remote MCP through the same lens they use for high-risk delegated access.

Purpose-built agent tools are the new control plane for NHI governance: The strongest security pattern here is not more endpoints, but fewer and better-shaped endpoints. A compact tool set gives IAM, PAM, and NHI controls something concrete to govern, log, and certify. That is where mature identity programmes will differentiate: not by exposing everything to the agent, but by deciding which actions never belong in the agent context at all.

Context windows do not excuse weak governance: Models may need concise responses, but compression is not security. If filtering, chunking, and response shaping are used only for usability, teams can still leak sensitive details or enable unsafe follow-on actions. The governance test is whether the agent can do the job without inheriting unnecessary authority or unnecessary data. Practitioners should define that boundary before they automate it.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• For a broader identity baseline, Ultimate Guide to NHIs explains why lifecycle, rotation, and offboarding remain central to machine access governance.

What this signals

MCP governance will converge with NHI lifecycle control: As agents begin acting through curated toolsets, teams will need the same ownership clarity they apply to service accounts and API keys. The practical shift is from approving broad integrations to certifying narrow, task-scoped access paths that can be reviewed and revoked cleanly.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations, according to our NHI research, agent-facing APIs are inheriting an already-fragile secret landscape. That makes tool scoping and credential placement inseparable decisions for IAM and platform teams.

Identity blast radius: This is the point where exposed tool count, OAuth scope, and response shaping combine into one measurable risk surface. Teams should expect agent governance to move from one-time enablement to continuous certification of what the agent can see, call, and persist.

For practitioners

• Inventory agent-facing tools by business action Classify every MCP-exposed action by sensitivity, side effect, and required privilege. Remove duplicate or low-value tools before agents can discover them, and keep only the minimum set needed for bounded tasks.
• Design OAuth scopes around task boundaries Map scopes to concrete workflows such as read-only lookup, approval support, or single-resource modification. Avoid broad delegated tokens that let an agent wander across unrelated resources once it is authenticated.
• Collapse brittle API chains into one controlled tool If a production task normally requires multiple calls, package it into a single MCP action with explicit validation and logging. Use that pattern to reduce context loss, accidental repetition, and uncontrolled chaining.
• Review response shaping as a governance control Limit returned fields to what the agent needs to complete the task, and strip anything that could enable lateral follow-on actions. Filtering should be treated as part of the control boundary, not a UX detail.
• Certify remote MCP servers like delegated access paths Apply the same review discipline you would use for high-risk integrations, including owner assignment, scope review, and periodic revalidation of exposed tools and OAuth grants.

Key takeaways

• MCP does not remove identity risk. It shifts it into the tool layer, where broad exposure and weak scoping can multiply the impact of a single delegated credential.
• OAuth, tool design, and response shaping are the practical controls that determine whether an AI agent remains a constrained delegate or becomes an over-broad proxy.
• Security teams should govern MCP servers as part of NHI and delegated access management, not as a separate developer convenience problem.

Key terms

• MCP Server: An MCP server is a tool layer that exposes application actions and data to an AI agent through a standard interface. In identity terms, it becomes a delegated access surface that must be scoped, authenticated, and audited like any other non-human integration.
• Tool Scoping: Tool scoping is the practice of limiting which actions an agent can see and invoke. It is the difference between a narrow task-bound capability and a broad API surface that allows the model to explore beyond the intended workflow.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another within defined bounds. For AI agents, the critical issue is whether those bounds are narrow enough to prevent the agent from becoming an over-broad proxy.
• Response Shaping: Response shaping is the reduction or filtering of returned data so the agent receives only what it needs for the current task. In secure deployments, it prevents large responses from leaking unnecessary detail or enabling additional unauthorized actions.

What's in the full article

Stytch's full article covers the operational detail this post intentionally leaves for the source:

• How the MCP server generator approaches OAuth and agent authentication in practice.
• Examples of tool selection, filtering, and chunking decisions that affect real deployments.
• The transcript details specific workflow moments where orchestration breaks down or succeeds.
• The video discussion shows how the team thinks about exposing dashboard functions through agent-accessible tools.

👉 The full Stytch post covers the transcript, tool-shaping examples, and authentication discussion in more detail.

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 building or maturing identity security across human and non-human access, it is worth exploring.