The Model Context Protocol is becoming the standard way AI agents interact with tools. That adoption is outpacing security. Research published in early 2026 found that 32% of MCP servers have critical vulnerabilities. The root cause is straightforward: MCP has no built-in authorization layer. The protocol defines how to discover tools and call them. It does not define who is allowed to call what, under which conditions, or how to audit what happened.
This means every MCP tool server is responsible for implementing its own access control. Most do not. The result is that any MCP client connected to a tool server can call any tool with any arguments, with no policy check and no audit trail.
You could add authorization to each tool server individually. But this does not scale. If you are running ten tool servers, you now have ten separate authorization implementations to maintain, ten sets of policies to keep in sync, and ten different audit log formats to reconcile. One misconfigured server and you have a gap.
What you actually need is a gateway. A single enforcement point that sits between every MCP client and every tool server, evaluating every call against a unified policy before forwarding it.
The Authensor MCP Gateway implements the SEP (Structured Evaluation Protocol) authorization flow using three message types.
authorization/propose — The client sends the intent to the gateway. This includes the tool name, arguments, and the identity of the agent making the call. Nothing is executed at this stage.
authorization/decide — The gateway evaluates the intent against the active policy. The policy engine checks action rules, resource constraints, time windows, rate limits, and content safety (via Aegis). The decision is ALLOW, DENY, or REVIEW. If REVIEW, the intent is routed to a human approver.
authorization/receipt — After the decision, the gateway creates an immutable receipt. The receipt contains the full intent, the policy version that evaluated it, the matched rules, the decision, and a hash-chain link to the previous receipt. This is your audit trail.
Only after an ALLOW decision does the gateway forward the tool call to the downstream server. The tool server never sees denied requests. It does not need to implement any authorization logic.
If your MCP client does not support SEP messages, the gateway falls back to inline evaluation. The tool call arrives, the gateway evaluates it internally, and either forwards it or blocks it. The client does not need to change. You get policy enforcement and audit logging without modifying any existing MCP integration.
Every tool call across every connected server is evaluated against one policy. You define the policy once. The gateway enforces it everywhere. If agent-finance is only allowed to call read_transactions and create_report but not delete_account, that rule lives in one place and applies regardless of which tool server hosts the tool.
Rate limiting, time-of-day restrictions, required approval for high-risk actions, content scanning of tool arguments — all handled at the gateway layer.
Add the gateway as a proxy between your MCP client and your tool servers. Point the client at the gateway. Point the gateway at your downstream servers. Define a policy. Every call flows through the gateway from that point forward.
npx create-authensor
The scaffolder sets up the gateway, a starter policy, and receipt storage. From there, you customize the policy to match your requirements. The gateway, the policy engine, and the receipt system are all open source. You run them on your infrastructure.