OWASP's MCP Server Guidance: What It Asks You to Be Able to Show

Every MCP server that can touch a payment release, customer record, or internal tool turns security guidance into an audit problem. That is the useful reading of OWASP’s Model Context Protocol material: not that a checklist will make the call safe, but that unsafe calls have recognisable causes. OWASP Gen AI Security Project published A Practical Guide for Secure MCP Server Development on 17 February 2026, describing MCP servers as the connection point between AI assistants and external tools, APIs, and data sources. The Model Context Protocol site published Security Best Practices on 28 July 2026, and that document addresses state handles, inbound authorization, token acceptance, local servers, and proxy risks.

Secure MCP server development as build-time work

The OWASP Gen AI Security Project page is titled A Practical Guide for Secure MCP Server Development. It says the guide provides actionable guidance for securing Model Context Protocol servers. That matters because development guidance asks whether the server was built with the right controls. It does not, by itself, answer whether a later call to change a credit limit carried enough authority at the moment it ran.

A Practical Guide for Secure MCP Server Development provides actionable guidance for securing Model Context Protocol (MCP) servers—the critical connection point between AI assistants and external tools, APIs, and data sources.

— OWASP Gen AI Security Project, A Practical Guide for Secure MCP Server Development, 17 February 2026

The guide’s premise is sound. An MCP server is a place where an assistant can reach outward. If that outward reach includes a payment tool, a ticketing system, or a records application, the server becomes part of the path by which an agent produces consequences. The security argument begins before deployment, but the audit argument begins when somebody asks why one consequence was allowed.

OWASP has also discussed MCP security in broader terms, including a 22 April 2025 article that says teams hosting their own MCP servers may expose internal tools, databases, or proprietary functions to AI models. That is not a small boundary. It is the line between a model producing text and an agent causing work to happen elsewhere.

The useful objection is that OWASP never claimed that its server guidance was an evidence system. Correct. That is the point. Secure development guidance can reduce the chance that a server accepts the wrong input, trusts the wrong caller, or exposes the wrong tool. It cannot later reconstruct the business authority for one tool call unless the system was designed to preserve that authority.

This is why the question in Who Authorizes an MCP Tool Call? is not academic. A tool call is often described technically: which agent called which server, and which tool was invoked. The harder record is normative: who or what allowed the action, under which rule, with which human approval if one was required. A build checklist can say the server should be safer. It does not automatically leave a record fit for dispute.

MCP server security after deployment

The Model Context Protocol Security Best Practices page is more direct than most vendor material. It says MCP servers must not treat possession of a state handle as sufficient, must not accept tokens that were not explicitly intended for them, and must verify all inbound material where authorization is implemented. Those are runtime failures expressed as server obligations.

They are also evidence clues. If a server must verify an inbound authorization condition, then a later reviewer will ask whether that verification happened. If a server must not accept the wrong token, then a later reviewer will ask what the server accepted. If a state handle is not enough, then a later reviewer will ask what else was checked.

The MCP authorization page published on 2 August 2026 states the uncomfortable middle ground plainly.

While authorization for MCP servers is optional , it is strongly recommended when:

— Model Context Protocol, Understanding Authorization in MCP, 2 August 2026

That sentence should stop a compliance reader from overclaiming. The document does not make authorization universal. It says optional, then strongly recommended in defined situations. A team that treats all MCP deployments as identical will misread the guidance. A team that treats “optional” as “irrelevant” will misread the risk.

The same MCP authorization page tells builders to verify that what the MCP server gets from the client matches the required constraints. That sentence is narrow, but it is the hinge. It points to a comparison between a request and a constraint. For governance, the missing artefact is often the durable record of that comparison.

Suppose an agent asks an MCP server to update a supplier bank account. The server may know the agent identity. It may know the requested tool. It may know the target record. None of that proves the request was allowed under the organisation’s rule for supplier-payment changes. The proof has to show the permission decision, not just the completed update.

OWASP’s broader MCP security article puts the operating burden on the builder. It says full stack security includes the operating system, network settings, MCP server application code, and tool adapters. It also says treating MCP security as part of an AI governance strategy is crucial. That is useful guidance, but it still leaves a division of labour. What to secure is not the same question as what must be evidenced when the secured path is used.

A generic MCP server security label is therefore too broad to be operationally useful unless it is split. There is server construction. There is connection control. There is tool exposure. There is runtime authorization. There is the after-the-fact record. Collapsing those into one control family makes dashboards look tidy and investigations harder.

Are MCP servers a security risk in practice

OWASP’s answer is not subtle. In a 22 April 2025 article, OWASP Gen AI Security Project said MCP integration opens doors for new security risks that traditional API security alone cannot fully address. The OWASP Cheat Sheet Series also says compromised or malicious MCP servers are a direct supply chain risk to the development environment.

While MCP integration offers tremendous benefits, it opens doors for new security risks that traditional API security alone cannot fully address.

— OWASP Gen AI Security Project, Securing AI’s New Frontier: The Power of Open Collaboration on MCP Security, 22 April 2025

That does not mean every MCP server is a catastrophe waiting to happen. It means the server is a security-relevant component once it mediates between an agent and systems that matter. The useful answer is not fear. It is scope.

The OWASP MCP Top 10 page is a draft, incubator, or public-review resource rather than final guidance, and it describes “Shadow MCP Servers” as unapproved or unsupervised deployments outside formal security governance. That category is practical. It is what happens when an engineer connects an agent to a useful tool before the risk owner knows the path exists.

The same OWASP MCP Top 10 page, again not final guidance, says inadequate authentication and authorization occur when MCP servers, tools, or agents fail to verify identities or enforce access controls during interactions. That phrasing is important because it names three possible places for failure: the server, the tool, and the agent. The record of a completed action has to survive all three.

There is another risk that feels less like access control and more like instruction contamination. The OWASP MCP Top 10 page, still a draft, incubator, or public-review resource rather than final guidance, says the Model Context Protocol enables agents to retrieve complex context that can act as a secondary instruction channel. The immediate engineering response is to inspect and constrain what enters the agent’s working context. The evidence response is to preserve what the agent was authorised to do despite that context.

The distinction matters in a simple support case. A retrieved note tells an agent to close an account. The agent calls an MCP tool and the account closes. Later, the organisation can show the note, the call, and the closure. That still may not show authority. The missing record is the permission basis for closing that account at that time.

For a wider set of Crelis articles on this protocol, the Model Context Protocol topic page is the best route. For the narrower question of proving controls before they block actions, Shadow Mode is the relevant companion piece. Both questions belong together. A server can be risky before it fails, and a control can look acceptable before anyone proves it works.

What this means if you have to produce evidence

A compliance officer should read the OWASP material as a map of questions, not as a ready-made audit file. Which MCP servers exist. Which tools they expose. Which clients can reach them. Which inbound constraints were checked. Which state handles, tokens, and local privileges were involved. Which calls reached systems that changed something.

Some of those questions are inventory questions. Some are engineering questions. The final group are evidence questions. They ask what survives after the call, when the person asking was not present and does not trust the dashboard.

The MCP Security Best Practices page says local MCP servers run with the same privileges as the client. It also describes local MCP servers as running on a user’s local machine. That combination is a reminder that the boundary may sit on a device, not in a central service. The evidence problem gets worse when the action path is distributed across user machines and internal systems.

The same MCP security page says MCP clients deployed to a server must consider SSRF risks. It also says attackers can exploit MCP proxy servers that connect to third-party systems. Those are technical risks, but they become governance risks when the organisation cannot later distinguish an authorised tool call from a confused or misrouted one.

A common mistake is to treat observability as evidence. Operational records are useful. They are not necessarily the authority record. A trace may show that the agent invoked a tool, but not that the invocation met the policy for a supplier payment, a payroll change, or a deletion from a customer file.

The OWASP article from 22 April 2025 says logging and monitoring are essential for detecting issues on the server. That supports detection. It does not prove that the right authority existed for each consequential action. Detection asks whether something suspicious happened. Authorization evidence asks whether this specific action was permitted.

That distinction is also where Singapore risk owners tend to become impatient with generic AI governance language. A policy statement is not enough. A diagram is not enough. A weekly review of agent outputs is not enough. When a contested action appears, the question becomes mechanical: show the permission that existed before the tool call changed the outside world.

The same logic sits behind Crelis’s treatment of adjacent guidance such as MAS SAFR. The useful work is not to restate high-level principles. It is to translate them into records that can be produced when an agent has already acted.

Practical steps for risk owners and engineers

1. List the MCP servers that can cause external change. Start with servers that can move money, alter customer records, change supplier details, or trigger operational work. Do not begin with chat-only use cases unless they can call tools that change something.
2. Separate server security from action authority. Use OWASP and Model Context Protocol guidance to harden the server path, but keep a separate question open: what authorises this particular call to this particular tool.
3. Record the constraint that was checked. The MCP authorization page tells builders to verify that what the server receives matches required constraints. If that comparison matters, preserve it as part of the action record.
4. Treat local deployment as a governance boundary. The MCP security guidance says local MCP servers run with the same privileges as the client. If the client has access to sensitive systems, the local server path deserves the same evidence discipline as a central integration.
5. Do not confuse approval of a server with approval of a call. A server may be approved for use and still receive a request that should not be carried out. The approval record for onboarding the server is not the approval record for changing a record.
6. Test before enforcement where the organisation is not ready to block. A shadow-mode approach can collect decision records before teams allow controls to stop live work, which is why Shadow Mode belongs in the implementation plan.
7. Define retention around disputes, not debugging convenience. If records disappear before a dispute reaches the risk owner, the control may have worked in the moment and still fail as evidence. The retention issue is treated separately in the Crelis tracing and Singapore law piece.
8. Give reviewers the action, not just the alert. A reviewer needs the agent, the requested tool, the target system, the policy basis, and the outcome. An alert that says “blocked” or “allowed” is only the headline.

Crelis’s position is narrower than OWASP’s security programme. Crelis describes GREENLIGHT as a way for sensitive agent requests to be routed through Crelis so that only what policy allows is carried out, and the product demonstration page asks teams to identify where agents touch money, customers, records, or infrastructure. The point is not that a runtime permission step makes an MCP server secure. The point is that, when an agent changes a record or releases a payment, the evidence question starts before the action is taken.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Who Authorizes an MCP Tool Call? — separates identity, permission, and proof for a single MCP action.
• Model Context Protocol — collects Crelis writing on MCP governance and runtime authority.
• Shadow Mode — explains how to test governance records before controls stop live work.
• MAS SAFR — maps Singapore agentic AI guidance to evidence obligations.