The Model Context Protocol (MCP) has become a common way to connect AI agents to tools, APIs and data. It is easy to start with, which is exactly why it needs thought before it reaches production systems.
Where enterprise gaps remain
A recent review of the 2026 MCP roadmap by WorkOS highlights four areas where enterprise readiness still needs work: audit trails and observability, enterprise-managed authentication (many deployments still rely on static client secrets), gateway and proxy patterns, and portable configuration across clients. Until the protocol closes those gaps, much of the responsibility sits with the teams deploying it.
Five controls to put in place
- Use identity, not static secrets. Connect MCP access to your single sign-on and identity provider so access can be granted, reviewed and revoked centrally.
- Apply least privilege to every tool. An agent that only needs to read tickets should not be able to close them or touch other systems.
- Put a gateway in front of your servers. A central gateway gives you one place to enforce authentication, rate limits and policy. Managed options such as AgentCore Gateway on AWS can help.
- Log every tool call. Record who or what called which tool, with what inputs and what result, and send it to the tools your security team already uses.
- Approve servers before you connect them. Keep an allowlist of reviewed MCP servers, and require human approval for high-impact actions such as deletions or payments.
What the MCP security guidance says
The Model Context Protocol project publishes its own security best practices, which back up several of the controls above. Some points worth reading closely:
- No token passthrough. The guidance says MCP servers must not accept any tokens that were not explicitly issued for the MCP server, and describes forwarding client tokens to downstream APIs as an anti-pattern that makes audit trails and incident investigation harder.
- Minimal scopes. It recommends starting with a minimal set of low-risk scopes, asking for more only when a privileged operation is first attempted, avoiding wildcard or catch-all scopes, and logging scope elevation events.
- Local servers need consent and sandboxing. A client that offers one-click setup of a local server must show the exact command that will run and get explicit approval first, and should run servers with restricted file system and network access.
- Protect against server-side request forgery. Clients running on a server should require HTTPS and block requests to private and link-local address ranges, which include cloud metadata endpoints, and may use an egress proxy.
The OWASP Top 10 for LLM Applications (2025 edition) is a useful companion. It lists both prompt injection and excessive agency among its ten risks, and the second maps directly onto the least-privilege control above.
Treat it like any other integration
MCP servers are integrations, and the same rules apply: review them, give them the minimum access they need, monitor them and own them. Teams that already run mature cloud and DevOps practices are well placed to do this, because the controls are familiar.
If you are planning to connect agents to internal systems, our Agentic AI & AI Agents team can help you design the guardrails first. Get in touch to discuss your use case.
Sources: WorkOS, “2026 MCP roadmap: enterprise readiness”; AWS Amazon Bedrock AgentCore documentation. Also: Model Context Protocol, security best practices (checked October 2026); OWASP Top 10 for LLM Applications (2025).
