MCP Server Security: How to Build Non-Bypassable Authorization

The MCP Security Challenge

The Model Context Protocol (MCP) gives AI agents structured access to external tools and services. But with that access comes a fundamental security question: how do you ensure an agent cannot bypass authorization controls?

In a naive implementation, the agent has direct access to payment APIs. It can call the payment endpoint, skip validation, or manipulate request parameters. Any authorization check that lives in the same process as the agent is bypassable by definition — a sufficiently capable model can reason about and circumvent in-process guards.

The Dual-Server Solution

Authorail solves this with architectural separation. Instead of one MCP server that handles both authorization and payment execution, Authorail runs two distinct servers:

• Agent MCP Server. This is the server the AI agent interacts with. It exposes tools for submitting spending requests, checking budgets, and viewing transaction history. It never has access to payment credentials.
• Admin MCP Server. This is the server that holds payment credentials and executes transactions. It is only accessible to the policy engine, never to the agent directly.

The agent cannot bypass authorization because it physically cannot reach the payment execution layer. The two servers communicate through an internal policy engine that enforces rules deterministically.

Env-Binding Authentication

Traditional API key authentication has a weakness in the agent context: if the agent can read its own environment variables or configuration, it can extract credentials and make direct API calls.

Authorail uses environment-binding authentication. The agent’s MCP server authenticates using credentials that are injected into the server process at startup and never exposed to the agent. The agent authenticates to the MCP server through a session token that grants it a specific identity and permission scope — but this token cannot be used to access payment APIs directly.

This means even if an agent is instructed to “find your API keys and make a direct payment,” there are no payment API keys in its environment to find.

Response Sanitization

Every response from the MCP server to the agent is sanitized to remove information that could be used to bypass controls:

• No credential leakage. Payment account numbers, API keys, and internal endpoint URLs are never included in responses.
• No policy details. The agent sees the decision (allow, deny, escalate) and a human-readable reason, but not the internal policy rules that produced it. This prevents the agent from gaming the policy engine.
• Structured responses only. Free-text fields that might contain sensitive data are filtered before being returned to the agent context.

Closed-Loop Payment Execution

When a spending request is approved, the payment execution follows a closed loop:

1. The agent submits a spending intent to the Agent MCP Server.
2. The policy engine evaluates the request and returns a decision.
3. If approved, the policy engine sends an execution command to the Admin MCP Server.
4. The Admin MCP Server executes the payment and returns a confirmation.
5. The agent receives a sanitized confirmation — amount, vendor, and transaction ID — but no payment details.

At no point does the agent participate in payment execution. It requests, and it receives confirmation. The actual movement of money happens in a process the agent cannot observe or influence.

Five Security Invariants

Authorail’s architecture maintains five invariants that hold regardless of agent capability:

1. No direct payment access. The agent never has credentials that can execute a payment.
2. No policy bypass. Every spending request passes through the policy engine. There is no alternative path.
3. No credential exposure. Payment credentials exist only in the Admin MCP Server process, which the agent cannot access.
4. No decision manipulation. The agent cannot modify policy rules or influence the policy engine’s evaluation.
5. Complete auditability. Every request, decision, and execution is logged with tamper-evident records.

These invariants are not enforced by prompting or guardrails. They are enforced by architecture — by the physical separation of concerns across process boundaries. A more capable model does not weaken these guarantees; it simply operates within them.

Why This Matters

As AI agents become more capable, security-by-prompting becomes less reliable. An agent that can reason about its own constraints can potentially reason around them. The only durable security model is one where bypassing controls requires breaking architectural boundaries, not just crafting clever prompts.

Non-bypassable authorization is not a feature. It is a design principle that must be embedded in the system architecture from day one.