MCP Is Not a Security Boundary: Build AI Agent Access at the Data Layer
MCP is not dead. MCP is also not your security boundary. The first statement corrects the headline bait. The second corrects the more expensive architecture mistake.
The Model Context Protocol, not “Model Content Protocol,” standardizes how an AI application discovers and invokes tools, resources and prompts. That makes integrations easier to build and govern. It does not prove that the caller may read one customer's phone number, update one invoice, or export one document. If a code-capable AI agent can reach the same system through a shell, SDK or direct API with broader credentials, the narrow MCP tool is a preferred route, not a boundary.
This distinction matters to founders, CTOs and security teams buying agent infrastructure. A protocol can make safe behavior easier. Only an enforcement point that the workload cannot bypass can make unsafe behavior fail. If you need the OAuth and multi-tenant implementation details after this decision guide, use our separate enterprise MCP authorization reference architecture. This article answers the prior question: where should the trust boundary be?
Need an agent access-control design your security team can approve?
Plan a production reviewWhat is the short answer?
MCP is an interface boundary. Authorization is a policy decision. Your security boundary is the set of unavoidable enforcement points between an identity and each protected action or data object.
A useful test is simple: can the agent obtain the same data or cause the same side effect through another path? If yes, the MCP server is not the complete boundary. Every alternate route needs equal or stronger controls, including direct APIs, database connections, browser sessions, local files, queues and cloud SDKs.
| Layer | What it defines | What it does not guarantee |
|---|---|---|
| MCP | Tool, resource and prompt discovery; schemas; invocation; optional HTTP authorization framework | Object, row or field permission in a downstream system |
| API | A general service contract and its operations | Least privilege unless identity and authorization are enforced |
| Agent harness | Which tools, shell commands and networks the runtime exposes | Protection against credentials or routes available outside that harness |
| Security boundary | An unavoidable, fail-closed decision before a protected read or write | Nothing beyond the resources and paths it actually controls |
Is MCP designed to limit what an AI agent can do?
It can help narrow the interface, but that is not the same as enforcing the limit. MCP tools have input schemas, and clients can present a smaller, task-relevant surface than a broad REST API. The current MCP schema also defines annotations such as readOnlyHint and destructiveHint. The specification is explicit that these properties are hints and that clients must not make security decisions from annotations supplied by an untrusted server.
MCP's HTTP authorization specification adds valuable OAuth controls. It requires resource indicators so a token is intended for a specific MCP server, and the security guidance forbids token passthrough to downstream APIs. Those controls answer “is this token meant for this server?” They do not fully answer “may this subject see field contact_email on customer 42 for this support task?”
That second question requires business context and resource context. It belongs in a deterministic authorization system, not in a prompt and not in the model's judgment.
Can a code-capable agent bypass MCP?
Yes, when its execution environment exposes another usable route and credentials. No, when the surrounding system removes or constrains those routes.
An agent that can write code does not automatically gain every API. It still needs network reachability, credentials, executable tooling and permission. This is the part the “MCP is dead” argument gets wrong. Code generation changes the threat model, but a sandbox, egress allowlist, workload identity and least-privilege credentials can make generated code powerless outside the approved path.
The correct conclusion is not “MCP is useless.” It is: never confuse a convenient interface with a non-bypassable control. MCP remains useful for typed discovery, consistent tool invocation, credential separation and audit hooks. It becomes a credible control point only when the runtime cannot step around it and the downstream resource still rechecks authorization.
Where should AI agent access control live?
As close to the protected resource as practical, with earlier layers reducing risk before the request gets there. “Data-level access control” should not mean one magic database feature. It means the final authorization decision includes the specific object, operation and data classification, and every path to that object is covered.
| Control layer | Decision it must enforce | Example |
|---|---|---|
| Delegated identity | Who asked, which agent acts, and on whose behalf | Short-lived token keeps the human subject and agent actor distinct |
| Sandbox and egress | Which files, processes, hosts and protocols are reachable | Support agent can reach the customer service, not the production database |
| Tool or API policy | Which operation and arguments are allowed now | Refund allowed only below an approved amount |
| Object or row policy | Which exact records the subject may read or change | Agent may retrieve customers assigned to the user's support queue |
| Field protection | Which attributes are necessary for this purpose | Return a masked phone number unless callback permission is present |
| Audit and revocation | Can the decision be explained, stopped and investigated | Log subject, actor, purpose, object, fields, policy version and result |
This layered model matches established security practice. NIST's Zero Trust Architecture focuses protection on resources instead of network location. NIST's ABAC guidance evaluates subject, object, operation and environmental attributes. An agent is a non-person entity acting in a context, so the old model still works when you preserve that context.
What does data-level access control look like in a real support task?
Consider the example behind the viral argument:
retrieve_customer_by_email(email)A narrow tool name sounds safer than a generic GET /customers endpoint. It is not sufficient. The email parameter may name a customer outside the user's tenant. The tool may return fields the task does not need. A code-capable agent may call the backing API directly. A shared service credential may have administrator access.
A defensible request carries a decision envelope:
subject: user_184
actor: support_agent_7
purpose: resolve_ticket
action: customer.read
resource: customer_42
requested_fields: [name, plan, last_invoice_status]
tenant: acme_eu
ticket: ticket_912
environment: production
The enforcement sequence is deterministic:
- Derive tenant, subject and actor from verified identity, never from model-written arguments.
- Confirm the ticket relationship and the user's permission for this customer object.
- Allow only the fields necessary for the support purpose.
- Apply the same check in the API and data layer, even if the MCP gateway already allowed the tool call.
- Return a policy decision ID with the response for audit and revocation analysis.
For relational data, PostgreSQL row-level security can enforce which rows a database role may see or change and defaults to deny when row security is enabled without an applicable policy. For shared documents and nested organizations, a fine-grained relationship model such as OpenFGA can answer whether this user or delegated agent may perform this action on this object. These are examples, not a requirement to buy either product.
Does field-level encryption make the data itself the boundary?
Encryption can make the boundary stronger. It cannot replace authorization.
If the same overprivileged agent runtime can ask the key service to decrypt every email address, ciphertext at rest has not changed the effective permission. The security gain appears when key release or re-identification is itself bound to verified identity, purpose, object, field and time, and when plaintext exists only in the smallest trusted component.
Use cryptographic controls according to the job:
- Envelope or field-level encryption: limits which services and identities can recover sensitive fields.
- Tokenization or pseudonymization: lets most workflows use stable substitutes without seeing the original value. Google Cloud's documentation describes reversible and irreversible patterns.
- Redaction and masking: remove data the task does not need before it reaches the model.
- Short-lived, audience-bound credentials: reduce what a stolen credential can reach and for how long.
The practical rule is: authorize first, minimize second, decrypt last. Do not release a broad dataset and ask the model to ignore fields it should never have received.
"A narrow MCP tool is useful. It becomes a boundary only when the agent cannot bypass it and the protected resource independently enforces the same identity and policy."
MCP vs API security: which one should you use?
Usually both. MCP and APIs solve different parts of the stack. MCP gives agent clients a standard discovery and invocation contract. APIs remain the durable service interface behind many MCP servers. Neither choice removes the need for object-level authorization.
| Situation | Recommended shape | Security condition |
|---|---|---|
| Several agent clients need the same curated tools | MCP in front of existing services | Gateway identity plus downstream reauthorization |
| One deterministic workflow calls one service | Direct API or SDK may be simpler | Scoped workload identity and object-level policy |
| Agent can execute arbitrary code | MCP plus sandbox and egress policy | No broader credentials or bypass network route |
| Highly sensitive fields | Data broker or dedicated retrieval service | Field minimization, gated decryption and complete audit |
| Many tenants and downstream systems | MCP gateway plus policy engine and per-tenant data controls | Tenant from verified claims, never tool input |
For the exact OAuth flow, audience validation, token exchange and tenant isolation design, continue with the MCP authorization architecture guide. For the broader choice between knowledge, connectivity and procedure layers, use our MCP vs RAG vs Agent Skills comparison.
What should buyers ask an MCP or agent platform vendor?
The commercial risk is not whether the vendor has an “enterprise MCP gateway” slide. Ask for evidence that the claimed boundary survives bypass attempts.
- Identity propagation: Can logs distinguish the user, agent, service and downstream actor on every hop?
- Alternate paths: What prevents shell code, browser automation or a direct API client from using broader credentials?
- Authorization granularity: Can policy include tool, arguments, tenant, object, relationship, fields, purpose and risk?
- Fail-closed behavior: What happens when the policy engine, identity provider or key service is unavailable?
- Credential design: Are tokens short-lived, audience-bound and exchanged instead of passed through?
- Data minimization: Can sensitive fields be masked, tokenized or withheld before model inference?
- Audit proof: Can one decision ID trace user intent, policy evaluation, tool call, downstream API and returned fields?
- Revocation: How quickly can one user, agent, tenant, server or policy version lose access?
- Adversarial test: Will the vendor demonstrate a denied cross-tenant read and a denied direct-API bypass?
If the answer is “the prompt tells the agent not to,” there is no security boundary. If the answer is “the MCP tool is read-only,” ask which component verifies that claim. The official MCP schema warns that tool annotations are hints, not trusted facts.
Is MCP dead?
No. The better conclusion is less dramatic and more useful: MCP is infrastructure, not authority. A standard protocol can reduce integration cost, make tools discoverable, separate some credentials from the model and create a consistent inspection point. Those are valuable properties.
MCP fails when teams assign it a job it does not claim to complete. It cannot rescue an administrator token, an unrestricted shell, a flat multi-tenant database or a service that authorizes only at login. The remedy is not to discard MCP. The remedy is to design identity, execution and data access so the protocol sits inside a real trust boundary.
Implementation checklist
- Inventory every path from the agent runtime to sensitive data and side effects.
- Remove standing administrator credentials and isolate the execution environment.
- Propagate the delegated human identity and the agent actor separately.
- Enforce tool and argument policy before execution.
- Recheck authorization on the exact object or row at the downstream service.
- Minimize fields before they reach the model, then gate decryption or re-identification.
- Use audience-bound, short-lived tokens and exchange them for downstream audiences.
- Log one correlation and policy decision ID across the complete call chain.
- Test a direct-API bypass, a cross-tenant read, a forbidden field and a revoked identity.
Final thoughts
MCP is a useful standard interface, not a complete security boundary. APIs are powerful service contracts, not boundaries by default either. The enforceable boundary is the chain the agent cannot bypass: constrained execution, delegated identity, deterministic policy on the action and arguments, object-level authorization at the resource, field minimization or gated decryption, and an audit trail that proves each decision. Build that chain first. Then choose MCP wherever its interoperability and tooling make the system easier to operate.
Primary sources
- Model Context Protocol authorization specification, 2025-11-25
- Model Context Protocol security best practices
- Model Context Protocol schema reference for tool annotations
- RFC 8707, Resource Indicators for OAuth 2.0
- RFC 9700, Best Current Practice for OAuth 2.0 Security
- NIST SP 800-207, Zero Trust Architecture
- NIST SP 800-162, Attribute Based Access Control
- PostgreSQL row security policies
- OpenFGA fine-grained authorization overview
- Google Cloud Sensitive Data Protection, pseudonymization
- AWS Security Blog, secure AI agent access patterns with MCP