How to secure MCP architectures for enterprise production

I've seen the Model Context Protocol (MCP) unlock incredible agentic workflows, but there is a hard truth I always tell my clients: building the technical architecture is the easy part. The gap between "it works perfectly in my demo" and "the enterprise security team approves it for production" is where most MCP projects die.

To get your AI agents out of the sandbox and into production, you need to design for security, governance, and enterprise reality from day one. Here is a pragmatic guide to the security considerations and best practices I use for enterprise MCP development.

1. OAuth token management in stateless architectures

The MCP server works perfectly in the demo. Then your container autoscales to zero overnight, and everything breaks.

The core problem is OAuth token expirations. If your "stateless" architecture loses the token the moment a container goes down, the user has to re-authenticate every morning, without refresh tokens. Your enterprise security team will not approve a system with this level of friction.

Here are four ways to solve this, ranked by implementation pain:

• Separate token storage (low pain): Store refresh tokens outside the container in a secrets manager or a lightweight persistence layer. When the container boots, it grabs a fresh token seamlessly.
• Read-only vs. write access split (medium pain): Most MCP use cases are heavily read-oriented. Use a long-lived service account token for read-only operations, and require user-level OAuth strictly for write operations.
• Keep the container warm (high cost, low pain): Simply disable autoscaling to zero. It is expensive, but it might be the right call if your security team blocks token persistence.
• 90-day refresh window (the sweet spot): Configure the system so that if users interact with it at least once every 90 days, the refresh token stays valid. The container can go down nightly, but authentication persists as long as there is regular usage.

2. Data access boundaries: the sandbox pattern

Never let your AI agent fetch its own data.

If an agent has direct access to production data sources, it inherits the permissions of its service account. In most organizations, service accounts hold far more access than any individual user should have. In early 2026, I audited a client environment where a "read-only" AI assistant inherited a legacy service account that still had DROP TABLE permissions across three production databases. The agent does not understand IAM boundaries or data classification; it will happily query everything it can reach.

This often leads to the agent discovering sensitive data and surfacing it in a prompt response. To prevent this, implement the Sandbox Pattern:

1. A separate process fetches data using the customer's actual privileges, not the agent's.
2. That data is loaded into a sandboxed environment.
3. The agent operates exclusively within that sandbox.
4. The agent physically cannot skip IAM rules because it never touches the source systems.

Treat your AI agent like an untrusted intern with good intentions. Give it exactly the data it needs, at the user's permission level, and nothing more.

3. Permission models and the Human-in-the-Loop

Teams often give agents broad access because building proper permission boundaries takes time. This creates three distinct failure modes: breaking undocumented API contracts, destroying data through ruthless optimization, and triggering cascading system failures.

To mitigate these risks, enforce these three principles:

Scoped tokens, not credentials

Every agent interaction with production must go through purpose-built APIs using the minimum required permissions. Agents should never hold admin keys, deployment credentials, or tokens capable of destructive operations.

Mandatory human approvals

Anything that cannot be easily undone requires human approval. Database changes, production deployments, and external communications need an actual review from someone who possesses the business context the AI lacks.

Document constraints in code

AI optimizes for the objective it is given, based on the context it can read. If an API contract, dependency, or business rule exists, it needs to live in the codebase. Comments, configuration files, and architecture decision records are visible to the agent. PDFs buried in SharePoint are not.

4. Operational guardrails for AI workflows

Dynamic AI workflows are excellent for prototyping, but they introduce unpredictability in production. Enforce these four operational rules:

• Do not let AI skip the boring parts: AI optimizes for completion and will skip slow steps like code scanning or security checks. Hard-code quality gates into the pipeline so they are non-negotiable.
• Never give write credentials to critical systems: If an agent needs to perform a dangerous action, it must request approval through a human-in-the-loop gate via scoped APIs.
• Context is scarce: AI does not know what it does not know. Every undocumented constraint is a ticking time bomb.
• Standardize dynamic workflows: Once an AI discovers a successful dynamic workflow, freeze it. Convert it into a deterministic, repeatable pipeline, just as I advise teams to do with our standard DevSecOps practices.

5. Supply chain security: the slopsquatting threat

AI coding assistants frequently hallucinate package names. Attackers have realized this and are registering those fake names on public registries. This is called "slopsquatting", and it is highly predictable because AI models tend to hallucinate the same fake packages repeatedly.

The attack chain looks like this:

1. An AI assistant suggests a non-existent package in a code snippet.
2. An attacker identifies this common hallucination and registers the malicious package on npm or PyPI (as seen in recent supply chain attacks documented by Sonatype's 2026 State of the Software Supply Chain Report).
3. A developer follows the AI's suggestion and installs the package.
4. The CI/CD pipeline runs the malicious code with full access to the build environment.

To mitigate this, strictly lock your dependencies using hash verification, audit all AI-suggested packages before installation, and use allowlists in your CI/CD pipelines to permit only pre-approved libraries.

6. Token and access governance

Whether you are dealing with GitHub integrations or MCP servers, programmatic access requires strict governance. Every enterprise needs these four foundational documents to avoid endless firefighting:

• PAT and SSH Access Guidance: Define which authentication method to use, scope restrictions, and expiration policies.
• Migration Path to Apps: Outline how to move from legacy Personal Access Tokens to granularly scoped Apps.
• Incident Response Plan: Detail the exact detection, escalation, and remediation steps for compromised tokens or secrets.
• API Access Decision Tree: Map specific use cases to approved access methods and security trade-offs.

7. Context management at enterprise scale

Context files (like AGENTS.md) work beautifully for small teams with a single repository. At enterprise scale with hundreds of repositories, this approach collapses.

Historical knowledge lives in wikis, domain logic is in people's heads, and architectural decisions are scattered. You cannot maintain 200 decentralized markdown files as patterns drift over time. While per-repo context files offer immediate value, your organization-level context layer must be centralized and dynamically queryable across platforms.

8. Data residency vs. sovereignty

When enterprise architects ask about "sovereign AI" for MCP deployments, you must clarify the terminology before architecting a solution.

• Data residency: Your data stays in a specific geographic region on a cloud vendor's infrastructure. This satisfies GDPR and covers 95% of enterprise needs.
• Data sovereignty: You control the entire stack. No foreign entity can subpoena access.

Use this decision framework for MCP hosting:

If you cannot point to a specific law or contract clause requiring Tier 3, you are likely overbuilding.

Summary: the MCP security checklist

Getting an MCP project to production means surviving the security review. Use this checklist as your baseline: