Enterprise MCP: how do you connect AI agents without exposing your data?
MCP makes it easier to connect AI agents to tools and data, but it does not secure those connections automatically. Here is the architecture, controls and evidence an enterprise should require.
Model Context Protocol, or MCP, gives AI clients a common interface for discovering and using tools or resources. This interoperability can accelerate integration, but it does not protect data automatically. A secure enterprise deployment separates the agent, access policy, MCP servers and business systems. Every action needs an identity, a constrained scope, a check before execution and evidence after the event.
Short answer
Never connect a general-purpose agent directly to a broad tool catalog with powerful rights. Put a policy boundary between the client and enterprise systems: user and agent identities, tokens intended for the correct server, minimum scopes, tools separated by risk, approval for sensitive writes, network filtering and correlated logs. Tool results and documents remain untrusted input because they can carry malicious instructions.
The architectural rule is simple: MCP describes how to call a capability. The enterprise decides who may call it, with which data, in what context and with what evidence.
Nexxom reference architecture. MCP servers are separated by trust domain, and no sensitive action bypasses policy or logging.
What is MCP, and what does it not secure?
MCP is an open protocol that standardises the relationship among a client, servers, tools and resources. An agent can discover a capability, understand its parameters and call it without a different proprietary integration for every system. The specification released on 28 July 2026 makes the protocol transport stateless, carries client identity and capabilities in metadata, and adds headers that help gateways route and meter calls.
These mechanisms improve interoperability and support technical controls. They do not determine data classification, business roles, whether an action is legitimate or how much autonomy is acceptable. MCP also does not replace identity management, a secrets vault, a network gateway, data-loss policy or incident management.
| Layer | What MCP provides | What the enterprise must add |
|---|---|---|
| Discovery | Structured descriptions of tools and resources | Approved registry, owner, version and risk level |
| Invocation | Common format for arguments and results | Schema validation, business policy, quotas and error handling |
| Authorisation | OAuth framework for remote HTTP transports | Identities, consent, scopes, delegation and revocation for the context |
| Transport | Standard exchange between client and server | TLS, network filtering, egress proxy, segmentation and monitoring |
| Traceability | Available technical metadata and events | Correlation of user, agent, tool, policy decision and business outcome |
The first design mistake is therefore treating an MCP server as a simple connector. It is a new access surface for business systems, potentially able to read, change or trigger operations.
Five trust boundaries in an enterprise MCP architecture
1. The user and the agent are not the same identity
The user delegates a task. The agent or client executes calls. The MCP server exposes capabilities. The business system ultimately applies an operation. Logs need to distinguish these roles and retain the delegation link.
The NIST NCCoE concept paper on software and AI agent identity highlights agent identification, delegation, logging and data-flow provenance. This separation prevents a shared technical account from erasing accountability for the user or application that initiated an action.
2. Policy comes before the tool call
A model decision is not an authorisation decision. Before invocation, a deterministic layer should check role, tenant, data classification, risk level, destination and required approval. A write tool must not become accessible merely because the model produced its name and valid arguments.
Policy can return four outcomes: allow, deny, request approval or reduce scope. It should be versioned, tested and independent from the main prompt.
3. Each MCP server creates a trust domain
Putting every tool behind one server increases the impact of compromise and complicates rights. Separate public data, internal data, sensitive information and write actions at minimum. HR, finance, support and infrastructure tools should not automatically share the same secrets or runtime.
Separation enables distinct identities, logs, networks and incident procedures. It also makes it possible to revoke one server without interrupting the entire ecosystem.
4. The business system remains the final authority
The MCP server should not bypass controls in the target system. The business API still validates identity, permissions, schema, limits and operation consistency. When the server uses a service account, its rights should be as narrow as possible and never administrative by default.
For a sensitive effect, a strong design often exposes two tools: propose an operation and execute an approved operation. The first produces a reviewable object. The second requires proof of approval and rejects any parameter change after that approval.
5. Logs form a detection boundary
Security does not stop at denial. Teams need to detect unexpected behaviour: a sudden tool change, unusual volume, repeated denials, scope elevation, a new destination or output containing sensitive data. Agent, policy, MCP server and business-system logs should share a correlation identifier.
In Running Codex safely at OpenAI, OpenAI describes connecting requests, approval decisions, MCP usage and network decisions, then exporting agent-aware telemetry to security and compliance systems. The same principle applies to other agent platforms.
Main risks and controls
| Risk | Scenario | Preventive control | Evidence to retain |
|---|---|---|---|
| Indirect prompt injection | A document or tool result tells the agent to exfiltrate data or call another tool | Treat content as untrusted, separate data from instructions, restrict tools and approve sensitive actions | Content source, proposed plan, policy result and approval decision |
| Excessive rights | A read agent can also delete or administer | Minimum scopes, separate tools, progressive elevation and short-lived rights | Requested, granted and denied scope, duration and identity |
| Token passthrough | A server forwards a received token to an API for which it was not intended | Validate issuer, audience and resource, prohibit passthrough and use controlled delegation | Validated claims, target resource and validation outcome |
| Confused deputy | A malicious client exploits an MCP proxy or prior consent to act as a user | Per-client consent, exact redirect matching and transaction-bound state | client_id, redirect URI, consent and transaction correlation |
| SSRF | OAuth discovery or a redirect targets an internal service or cloud metadata endpoint | HTTPS, private-range blocking, per-hop validation, safe DNS and an egress proxy | Requested URL, resolution, network decision and redirects |
| Compromised local server | A package or startup command runs code with client privileges | Approved registry, visible command, consent, sandbox and restricted file/network rights | Artefact, version, exact command, signature and approval |
| State-handle hijacking | A task handle is guessed or reused by another user | Random handle, short lifetime and server-side binding to authenticated identity | Owner, creation, expiry and rejected attempts |
| Log leakage | Arguments, results or secrets are written in clear text | Redaction schemas, hashing where appropriate, restricted access and defined retention | Logging policy, masked fields and log access records |
The MCP security best practices for version 2026-07-28 cover confused-deputy attacks, token passthrough, SSRF, local servers and state-handle hijacking. They should be applied together with current OAuth security practice.
How should identity and tokens be secured?
Use authorisation for sensitive remote servers
MCP guidance recommends authorisation when a server accesses user-specific data, needs to attribute actions, requires consent or operates in an environment with strict access controls. For remote HTTP transport, the MCP server acts as a protected resource and the client uses an authorisation flow.
The server must validate that the token is intended for it. Checks include issuer, audience or resource, expiry and scopes. The specification prohibits accepting or transiting tokens issued for another resource. IETF RFC 9700 adds current OAuth security practice, including PKCE, exact redirect URI matching and replay protection.
Start small and elevate when required
A general client should not receive the whole permission catalog during its first connection. Begin with discovery or low-risk read capabilities. When an operation requires an additional right, the server returns a precise challenge and the process seeks new authorisation.
MCP guidance for 2026-07-28 describes this progressive least-privilege model. Elevation should be visible, contextual and logged. A generic admin scope is rarely appropriate for an agent.
Keep secrets outside the conversation
Tokens, keys and secrets should never be placed in a prompt or returned by a tool. They remain in a vault or identity component and are used at the last moment by the authorised server. Errors must never include the complete secret.
How can data exposure be limited?
Classify tools, not only databases
For each tool, document the categories of data it reads, transforms or writes. A tool called search_customers may appear harmless while returning personal information. Classification should cover parameters, responses, attachments and logs.
Minimise results at the server
An agent does not need a complete table to answer a precise question. Tools should filter server-side, limit fields, paginate and mask unnecessary values. The agent should not be responsible for removing sensitive columns after receiving them.
Block cross-tool exfiltration chains
Risk often emerges between two tools: read an internal document, then send its content to messaging or a URL. Policy should examine source, destination, classification and purpose together. External write tools require stronger controls than internal read tools.
OpenAI warns that untrusted MCP servers increase risks including prompt injection and recommends reviewing them before publication. For private servers, a Secure MCP Tunnel can avoid exposing the service directly to the public internet, without removing the need for authorisation.
What contract should every MCP tool meet?
An enterprise-approved tool should have at least:
| Field | Question to answer |
|---|---|
| Owner | Which team owns the code, data and incidents? |
| Purpose | Which precise business purpose authorises the tool? |
| Inputs | Which parameters, formats, lengths and values are accepted? |
| Outputs | Which data and classifications can be returned? |
| Effects | Does the tool read, propose, modify or delete? |
| Authorisation | Which identities, resources, scopes and conditions are required? |
| Approval | Which action requires human validation, and how is it bound to parameters? |
| Limits | Which quotas, timeouts, budgets and stopping conditions apply? |
| Logging | Which events are logged, redacted and correlated? |
| Lifecycle | Which version is approved, and how does revocation work? |
The model-facing description is not enough. These properties need to be enforced or checked by the server and policy gateway.
A pre-production checklist
Governance
- Inventory clients, servers, tools, owners, versions and target systems.
- Classify every tool by data, effect and maximum impact.
- Define who approves a server, a tool change and a permission elevation.
- Plan revocation of a server, token and compromised version.
Identity and authorisation
- Separate the user, client, agent, MCP server and business-system account.
- Validate issuer, audience, resource, expiry and scopes on every call.
- Prohibit token passthrough and shared administrator accounts.
- Use short-lived, minimum and progressive rights.
Data and actions
- Filter data in the tool before returning it to the model.
- Separate read, propose and execute capabilities.
- Bind human approval to the exact action parameters.
- Block unauthorised data destinations and combinations.
Network and execution
- Allowlist domains, protocols and redirects.
- Block private addresses and cloud metadata in untrusted discovery flows.
- Isolate local servers and show the exact command before execution.
- Enforce quotas, timeouts, call limits and kill switches.
Observation and incident response
- Correlate user, agent, client, tool, version, rule, approval and outcome.
- Redact secrets and sensitive data under a documented schema.
- Detect elevation, repeated denials, unusual volume and new destinations.
- Test revocation, shutdown, investigation and recovery before launch.
Common architecture mistakes
- Publishing an MCP server only because its source code is public.
- Giving an agent every scope to avoid authorisation prompts.
- Using one service account across tenants and business domains.
- Confusing parameter validation with authorisation of the action.
- Trusting tool content because it came from an internal database.
- Passing a user token to an API without validating its intended resource.
- Logging full prompts, results and tokens by default.
- Combining internal reads and external writes without data-flow policy.
- Testing agent answers while ignoring tool errors, denials and approvals.
For the broader application-security context, read our analysis of the OWASP risks in LLM applications and our method for selecting an agentic process.
Frequently asked questions
Does MCP encrypt data automatically?
MCP defines interactions and transports, but protection depends on implementation and infrastructure. Remote servers should use a secure transport, and data must remain encrypted according to organisational policy in transit and at rest.
Is an internal MCP server automatically trusted?
No. It can contain a vulnerability, compromised dependencies, a misleading tool description or excessive permissions. Internal origin can reduce some risks, but it does not replace review, isolation, testing and monitoring.
Can one MCP server cover the whole enterprise?
It is rarely a strong trust boundary. Separation by domain limits impact, simplifies authorisation and clarifies ownership. A common gateway can centralise some policy without combining every secret and tool.
How should write actions be handled?
Expose narrow tools, validate parameters at the server and require approval for sensitive effects. Approval should cover the exact action, destination and data. Any subsequent parameter change invalidates that approval.
Should every part of agent reasoning be logged?
No. Retain events needed for audit: request, identity, tool, useful and redacted arguments, policy result, approval, outcome and error. Avoid collecting unnecessary sensitive data or internal reasoning.
Conclusion
MCP reduces integration cost, not risk by default. A secure architecture treats each server as a new access boundary, every tool as a business capability and every output as potentially untrusted data. Rights are minimal and progressive, sensitive writes require approval, network destinations are controlled and useful events share a correlation identifier.
The goal is not to connect the largest possible number of tools. It is to give each agent the smallest capability set that can complete a task, with operational evidence of what was requested, authorised and executed. Nexxom can design that registry, policy and architecture around your actual systems.
Primary sources
- Model Context Protocol: 2026-07-28 specification
- MCP: Security Best Practices, 2026-07-28
- MCP: Understanding Authorization, 2026-07-28
- NIST NCCoE: Software and AI Agent Identity and Authorization, 2026
- NIST: AI Agent Standards Initiative, 2026
- IETF RFC 9700: Best Current Practice for OAuth 2.0 Security
- OpenAI: Developer mode and MCP apps in ChatGPT
- OpenAI: Running Codex safely at OpenAI, 2026
Sources and specification verified on 9 August 2026. MCP and its authorisation mechanisms evolve. Check client, server and SDK versions before making an architecture decision.
