An MCP server gives an AI agent a path into enterprise tools and data. The security challenge is deciding what the agent can do once connected, especially when employees add third-party servers, store credentials locally, or expose tools that security teams have never reviewed.

The OWASP MCP Top 10 identifies risks across that access path, including exposed secrets, excessive permissions, poisoned tools, and sensitive context leakage. Applying its guidance at scale means turning those risks into specific control points: discovering the servers people use, limiting agent actions, checking requests before execution, and recording the decisions. Those controls, however, need to reach beyond centrally managed servers to the MCP connections already operating across the business.

Below, we explore how you can turn those risks into practical controls across the MCP servers your teams build, adopt, and use.

Key Takeaways

• The OWASP MCP Top 10 turns MCP security into an enforceable set of risks around credentials, tool integrity, scope, command execution, and context handling.
• Enterprise enforcement has to cover unmanaged MCPs and shadow AI because employee adoption often reaches third-party servers before central review.
• Secure MCP governance depends on action-level permissions rather than on just authenticated connections or broad network access.
• Runtime guardrails are needed because agent behavior changes with context, tool output, prompt state, and delegated intent.
• Willow is the agentic access platform that extends existing IdPs with discovery, identity, scope, runtime guardrails, and audit for MCP usage across the enterprise.

Contextualizing the OWASP MCP Security Standard

The official OWASP MCP Top 10 project defines the major security risks that appear when MCP connects model reasoning to real tool execution. Why security risks? Because an MCP gives agents a structured way to discover tools, call functions, receive context, and act inside systems.

The familiar OWASP Top 10 model gives security teams a shared language for risk prioritization. In the MCP version, the center of gravity shifts from web application flaws to agentic execution flaws, including token handling, excessive scope, poisoned tools, unsafe schemas, command execution, and context manipulation.

A company enforcing OWASP MCP controls at scale therefore needs to answer four operating questions:

• Discovery: Which MCP servers, clients, skills, and tool schemas exist across endpoints and developer workflows?
• Identity: Which human, agent, machine user, or service account initiated the action?
• Scope: Which tool operation, resource, project, environment, or data class is allowed?
• Audit: Which request, context, policy decision, and tool result can be reconstructed later?

That structure moves the program away from static allowlists and toward enforceable governance. After all, a server can follow secure coding practices, but a company still needs runtime control over how employees and agents use it.

Targeting the Weak Spots: Token Mismanagement and Scope Creep

Token Mismanagement (MCP01) and Privilege Escalation via Scope Creep (MCP02) are the primary risks because they define what an agent can reach and how long that reach lasts.

Token Mismanagement in Practice

The risks of giving AI agents static API keys extend beyond insecure storage: a valid credential can still grant more authority than the task requires. Short-lived credentials reduce exposure duration, but they can still authorize an immediate destructive operation if the agent receives broad write authority. In contrast, a safer model evaluates the specific agent, the requested action, the target resource, and the environment before execution.

Transport-level protections, such as mTLS and DPoP help bind requests to trusted clients and reduce token replay risk, but they don't decide whether an approved agent should delete a record in production. Because of this, we recommend treating them as authentication and token-binding controls that sit below action-level authorization.

Containing Scope Creep

Scope creep follows the same pattern. Traditional IAM can authenticate the user and provide group membership, and existing IAM plus target-system policies can support granular access. The delegated-access gap appears when an agent performs actions through tools that were never modeled as first-class actors.

Action-level permissions close that gap. For example, a Jira-connected agent might read tickets in selected projects, create tickets in an engineering backlog, re-assign only within a team-owned queue, and never delete production incident records. And so while the identity is approved, approval does not imply unrestricted inheritance of the human’s administrative authority.

The Minimum Control Set to Have

For enterprise MCP security, the minimum control set typically consists of:

• No unmanaged long-lived secrets in local MCP configuration files.
• Separate identity for agents and machine users, tied back to the human or workflow that invoked them.
• SCIM-provisioned group mapping, so existing enterprise groups inform agent RBAC.
• Action-level permissions for read, create, update, delete, execute, and administer operations.
• Environment-aware policy so production, staging, and local workflows receive different treatment.
• Request-bound approvals that review the target, operation, resource, and impact, with re-review after material changes.

Defending Against Tool Poisoning and Supply Chain Risks

Tool Poisoning (MCP03) and Software Supply Chain Attacks (MCP04) focus on the integrity of the tools an agent sees and the instructions those tools carry. In an MCP, a tool schema is more than just documentation as it can also influence how the model chooses and executes actions.

Tool Poisoning (MCP03)

Tool poisoning happens when an MCP server, skill, manifest, or schema contains misleading descriptions, malicious instructions, hidden prompt text, or altered behavior that steers an agent toward unsafe actions. The risk isn't limited to code execution either because the schema itself can influence how the model chooses tools and interprets the next step.

Software Supply Chain Attacks (MCP04)

Supply chain risk appears when a trusted server, package, dependency, or integration path changes after approval, as illustrated in our guide to MCP security risks. A good enforcement strategy to follow here is to:

• Validate tool schemas before use. Review names, descriptions, parameters, hidden instructions, and dangerous defaults.
• Cryptographically sign schemas where possible. Use signatures or integrity pins so clients can detect unauthorized changes.
• Pin trusted versions. Treat schema drift as a security-relevant change instead of a routine metadata update.
• Risk-score third-party MCP servers. Evaluate publisher identity, code provenance, permissions requested, and known dependencies.
• Sandbox execution paths. Isolate tools that can run code, touch files, or call external services.
• Require re-approval for material changes. A new tool action, broader parameter, or changed destination should trigger review.

Out of these, unsigned schemas are of particular concern because agents rely on schema descriptions to decide what a tool does. This way, a tool named "search_docs" might later gain write capability, or what appears to be a harmless description might include instructions that bias the model toward exfiltrating context. Having integrity controls in place makes that change visible before execution.

Additionally, third-party MCP servers need the same governance logic as other software supply chain components, but with one added layer on top since the server tends to shape agent behavior through tool descriptions, returned context, and available actions, in addition to writing code.

A Layered Review Process

A strong review process separates three questions:

• Is the server trustworthy enough to connect?
• Are the tool schemas authentic and unchanged?
• Which actions should this agent be allowed to perform through that server?

After all, approving a vendor or open-source project doesn't mean every exposed action should be available to every agent, user, department, or environment.

Mitigating Command Injection and Context Subversion

Command & Code Injection (MCP05), Intent Flow Subversion (MCP06), and Context Injection (MCP10) sit closer to the agent’s reasoning loop. This is because an MCP can carry instructions, tool output, memory, and user context across boundaries that older controls did not inspect as execution inputs.

OWASP’s page on MCP10: Context Injection and Over-Sharing in particular highlights a critical point – context itself can become an attack surface when sensitive data, stale memory, malicious instructions, or cross-session content influence future actions.

How These Attacks Reach the Agent

Context injection differs from prompt injection because the malicious instruction may not arrive through the user’s prompt. It can instead arrive through a document, ticket, repository file, web page, tool response, shared memory, or a third-party MCP server. That means filtering chat input alone misses the path that is actually important.

Indirect prompt injection is often the underlying reason for many Context Injection (MCP10) breaches as it can influence the agent after the user’s original request appeared safe. That is why context controls also need to inspect tool output and retrieved content, instead of being limited to just the prompt entered by the human.

Intent flow subversion also needs precise approvals. A human approval is meaningful only when the reviewer sees the target, environment, operation, and impact. For instance, if an agent changes its goal from “summarize deployment status” to “restart production workers,” the approval needs to be re-evaluated against the changed plan.

For multi-tenant context bleed, the enforcement point has to account for memory persistence as well. Clearing the chat window is not really a control point if the agent can still retrieve stored memory, cached tool output, vectorized documents, or previous tenant state. Tests should therefore verify that context cannot cross users, departments, tenants, or data classifications.

A Runtime Control Set You Can Use

A typical runtime control set includes:

• Context sanitization before tool output re-enters the agent loop.
• PII redaction for logs, prompts, and tool responses where sensitive data is not needed.
• Ephemeral contexts for workflows that should not persist memory.
• Sandboxing for tools that touch files, shells, repositories, or CI/CD systems.
• Network segmentation so a compromised tool cannot reach unrelated systems.
• Plan-bound approvals that expire when the target, operation, environment, or impact changes.

Governing Shadow AI and Unmanaged MCP Servers

Shadow AI and unmanaged MCPs are a normal result of useful tools spreading faster than central intake can review them. Developers tend to connect local MCP servers, operators test dashboards, and teams adopt third-party skills because they solve real workflow problems.

Vibe-coded apps and quick local automations make this pattern harder to notice and record because a seemingly useful workflow can appear before security, platform, or IT has a formal intake record in place. The enterprise control plane therefore needs to discover those paths, assign ownership, and route approved usage through governed MCP access without forcing every experiment into a manual ticket.

How Willow Can Help

Willow is the agentic access platform for this control layer. Our enterprise MCP gateway is merely one capability inside that platform, used to bring unmanaged MCP connections under runtime governance rather than forcing every team back into ticket queues.

Here is how the Willow process looks like at a glance:

1. Find MCP servers, skills, clients, and browser AI usage across endpoints and workflows.
2. Bind agent activity to the right human, group, machine user, or workflow through existing IdPs.
3. Apply action-level permissions that define which agent can perform which operation against which resource and environment.
4. Stream decisions, tool calls, policy outcomes, and context needed for review into audit trails and SIEM workflows.

Establishing Governance Hard Gates for AI Adoption

MCP security hard gates are the minimum enforcement points that decide whether an agent can discover, connect, retrieve context, or execute an action. They should be narrow enough to avoid blocking low-risk use, but strict enough to stop unsafe delegation before production impact.

Other Considerations to Keep in Mind

• Least privilege needs to be determined at the action layer. “This agent can access Jira” is not enough – a usable policy says the agent can read tickets in selected projects, create tickets with bounded fields, and cannot delete or re-assign tickets outside the owning team’s queue.
• Approval flows need the same precision. An approval should review the actual target, environment, operation, and impact, then bind to that reviewed request or plan. If the agent’s plan changes materially, the approval should not silently follow it.
• Audit trails also need more than a timestamped tool call. For agentic workflows, reviewers need the identity chain, policy decision, selected tool, parameters, target resource, context source, approval record, and result. Without that chain, transparency stops short of accountability.
• Hard gates should not become a universal “no.” Low-risk read-only access to a non-sensitive documentation source calls for a different treatment than a tool that can run deployment commands, query customer data, or modify production infrastructure.

Moving from Visibility to Enforcement

Applying the OWASP MCP Top 10 starts with finding the servers teams use and enforcing clear boundaries around their actions. Each tool call needs an accountable identity, permissions scoped to the resource and environment, and an audit record of the policy decision. As for direct access paths, they need their own controls.

At the end of the day, the goal is to give employees a reliable route to approved tools while keeping sensitive actions subject to enforceable policy. This is where Willow comes in as it brings identity, scoped access, runtime guardrails, and audit together to support that approach.

So, start free with Willow to seamlessly connect your first agents and MCP tools. For production access that needs identity-provider integration, action-level permissions, runtime guardrails, and SIEM log streaming, make sure to also explore our enterprise plans.

Frequently Asked Questions

How is OWASP MCP different from the OWASP LLM Top 10?

The OWASP MCP standard focuses on risks created when agents use MCP servers to reach tools, data, and systems. The OWASP LLM Top 10 covers broader application risks around language models, while OWASP MCP narrows the lens to tool execution, credentials, schemas, context, and delegated actions.

For an enterprise program, that means MCP controls need runtime enforcement. A policy has to decide which agent can call which tool, against which resource, with what context and audit trail.

Can an MCP gateway prevent every unsafe agent action?

No single gateway can govern paths that do not traverse it. An MCP gateway can apply runtime policy to tool calls routed through the gateway, but direct database access, cloud APIs, shell paths, and endpoint-local execution still need their own controls.

A sound architecture pairs gateway enforcement with endpoint discovery, network segmentation, cloud controls, database permissions, and SIEM review.

How should teams handle read-only MCP tools?

Read-only doesn't necessarily mean risk-free. A read-only tool can expose sensitive data, leak context across sessions, overload a system, or give an agent information that changes a later write action through another tool.

Teams should therefore still scope read access by user, agent, data class, resource, and environment. Sensitive reads also need logging, retention controls, and context sanitization.

What evidence should an audit trail capture for MCP activity?

An MCP audit trail should capture the human initiator, agent identity, machine user where relevant, MCP server, tool name, parameters, target resource, environment, context source, approval record, policy decision, and tool result.

For high-risk actions, the record should also show why the action was allowed, blocked, or escalated. That lets reviewers reconstruct the decision rather than only seeing that a tool call occurred.

How is MCP enforcement different from a standard API gateway policy?

The caller is often an agent acting on behalf of a user instead of being a direct human or service request. The control point needs to evaluate identity delegation, tool intent, context, resource scope, and action type before execution.

This is because a standard gateway may authenticate a connection and apply rate limits. MCP governance also needs to detect schema changes, block unsafe tool calls, bind approvals to plans, and log the reasoning context that influenced the action.

How can security teams roll out OWASP MCP without affecting developers?

By separating discovery, approval, and self-serve access. Security approves trusted MCP servers and permitted actions once, then developers choose from governed toolkits instead of filing tickets for every workflow.

Ideally, the rollout should start with inventory across endpoints, IDEs, browser agents, and local MCP configs. From there on out, teams can assign owners, scope high-risk actions first, stream logs to the SIEM, and expand self-serve access as policies mature.

How does Willow fit into an existing Okta or Entra environment?

Willow plugs into the identity stack an enterprise already uses. Okta, Entra, Active Directory, and JumpCloud can provide user identity and group context, while Willow extends that context to agent activity, MCP tool calls, action-level permissions, runtime guardrails, and audit.

That means Willow doesn't directly replace the IdP, but instead adds governance for delegated agent actions that need policy decisions beyond ordinary human application login.