Series: Enabling MCP at Enterprise Scale | Post 6 of 10
You’ve built something with MCP. It works well. Now you need to get it approved for production.
If your organization has a security review process — and most enterprises do — MCP enterprise security is going to raise questions. Not because MCP is inherently risky, but because it’s new, it connects AI agents to real systems, and security teams haven’t seen it before. They’re going to ask about access controls, audit trails, credentials, and data.
The good news: these questions have answers. This post lays out what to expect and what you need to have in place before that conversation.
This is usually the first question, and it’s a reasonable one. If your MCP infrastructure connects to HR systems, financial data, or customer records, the answer can’t be “everyone who has the connection URL.”
What a good answer looks like: access is managed through named registries that map MCP servers to specific users and groups, synced from your enterprise IdP. In practice, identity management and a governed central registry for MCP tools give the MCP client the context it needs to enforce access policies with authentication, authorization, and visibility. The marketing team sees the marketing tools. Engineering sees the engineering tools. No one sees what they don’t need.
Server registry allowlists also help block a malicious MCP server or other malicious MCP entries from being exposed to users.
“What happens when someone changes roles or leaves the company?”
The expected answer here is that access is tied to IdP group membership, not to individual configuration files or static credentials. Remove someone from the relevant group in Entra or Okta and their MCP access ends — automatically, immediately, without anyone manually updating a config. In stronger setups, zero-trust checks verify user and agent authorization on each tool call rather than relying on broad, long-lived service accounts.
If your current setup requires manual revocation steps, flag that before the review. Security teams don’t love hearing “we’d update the config” as the answer to an offboarding question.
“Can we scope access more granularly than just which servers a user can connect to?”
Server-level access is a start. Tool-level access is what security teams actually want. The ability to say, “this user group can read from the CRM but can’t delete contacts or create new records” is the difference between MCP feeling controlled and feeling like a wild card. Attribute-based controls can further limit data access by evaluating signals beyond roles when agents discover or invoke tools. That tighter scoping also reduces authorization errors caused by overly broad permissions.
Centralized visibility also helps teams find unmanaged endpoints and reduce shadow access across MCP environments.
🔐 Stop rebuilding OAuth for every MCP server. Obot’s control plane handles DCR, token brokering, and unified revocation out of the box. → Try Obot free — no OAuth plumbing required
The Audit Logs Questions
“Do we have a record of every tool invocation?”
Yes — and be specific about what that means. Every tools/call, resources/read, and prompts/get should be captured in comprehensive, structured audit logs with the user identity, agent identity, timestamp, server name, tool identifier, full request context, authentication events, token issuance, and policy decisions. Not just that something happened, but who did it, which agent executed it, and what arguments were passed.
“Can we filter and export those logs?”
Compliance teams don’t just want logs to exist — they want to be able to query them. Filtering by user, server, call type, and date range. Exporting for SIEM (Security Information and Event Management) integration or compliance reporting. Logs should also be forwarded to centralized logging systems, or recorded locally where needed, from both local MCP servers and remote MCP servers. If your audit logging is just a text file somewhere, expect it to come up.
“How long are logs retained?”
Know the answer before the meeting. Retention requirements vary by regulation — HIPAA, PCI DSS, and GDPR all have different expectations in enterprise environments, and implementation details matter because standard MCP logging often misses execution context in a structured, compliance-ready format. Make sure your logging infrastructure matches what your compliance obligations require.
The Credential Management Questions
“Where are OAuth tokens stored?”
“In the client” is not the right answer. Tokens are credentials, so good credential management means they should be encrypted at rest, stored centrally in the control plane, and not accessible to individual MCP clients. If your current setup has tokens living in env files or other sensitive files on developer machines or scattered across file systems, that’s worth fixing before the review to avoid dangerous MCP OAuth shortcuts that undermine enterprise security. You should also require strong authentication with short-lived, rotating credentials and multi-factor authentication, and include authentication configuration in the review checklist.
“Can we revoke access immediately if a token is compromised or an employee leaves?”
This is where centralized token storage earns its value. Revocation at the control plane level — one operation, effective immediately, audit-logged. If revocation requires manually rotating credentials across multiple systems, say so, have a plan for improving it, and use that work to reduce credential sprawl across MCP deployments.
“Do agents hold credentials that could be used outside of MCP?”
This one surprises teams that haven’t thought about token brokering. If your MCP clients hold raw OAuth tokens, those tokens can often be used directly against the underlying API — outside of MCP, outside of your audit logs, outside of any access controls you’ve put in place. The token brokering pattern closes that gap by keeping raw credentials inside the control plane, where clients never touch them directly. Robust authentication is still necessary because the specification itself does not guarantee it, which raises the risk of unauthorized access and resource misuse.
The Sensitive Data Security Questions
“What data flows through MCP tool calls?”
Be honest here. If your MCP tools touch customer records, employee data, financial information, or anything else sensitive, say so. Security teams respect candor; they don’t respect discovering things you didn’t mention.
More importantly, think about what tool responses actually return and how to prevent PII leaks from MCP tool calls. Treat MCP servers as first-class trust boundaries for data sources and API calls, especially when tools return more information than needed. APIs are often generous with data — a contact lookup might return a full customer profile including fields your agent doesn’t need and shouldn’t be processing. That extra data flows into LLM context, potentially into logs, potentially into agent responses.
“How do we prevent sensitive data from leaking through tool responses?”
Filters at the control plane level — PII detection and redaction before tool responses reach the LLM. The specifics depend on your data types and risk tolerance, but the answer should include where the filtering happens (in the control plane, not in the agent), what gets blocked versus redacted, and how filtering decisions are logged. Real-time policy evaluation also helps prevent regulated sensitive information from flowing into public AI training pools.
For high-risk workflows that touch sensitive resources, use secure sandbox isolation with ephemeral container environments that wipe credentials and execution context immediately after completion.
“Is our data being sent to external LLM providers?”
This question comes up in every enterprise AI security review. Know your LLM routing — which models are in use, where they’re hosted, what data retention policies apply. If you’re using Azure OpenAI or AWS Bedrock rather than the public APIs, lead with that. Also note how MCP limits exposure when connecting external tools to enterprise data.
The Agent Security Questions
“Can an agent be manipulated into taking actions it shouldn’t?”
This is one of the main security risks and security vulnerabilities in MCP environments, and it’s increasingly on security teams’ radar, which is why MCP prompt injection defenses need to be part of your core security design rather than an afterthought. Prompt injection is a significant risk in MCP environments, where an attacker can embed malicious instructions within content processed by an AI agent, leading to unauthorized actions without direct access to the system. No agent is completely immune — but there are concrete mitigations:
Filters that scan tool responses for instruction-like content before they reach the agent
Agent-scoped tool sets that limit what an agent can do even if it is manipulated
Audit logging that lets you detect and investigate anomalous behavior after the fact
Organizations should validate and sanitize inputs at every layer of the MCP architecture to catch malicious instructions and hidden instructions. Harden against prompt injection by deploying application-layer filtering gateways and real-time detection shields as core security controls. A compromised tool can also expand the attack surface and create significant security risks. Local MCP servers running custom code can introduce command-injection risk and broader data exfiltration exposure if not isolated, underscoring the broader MCP security risks and best practices you’ll be expected to address in an enterprise review.
“What’s the blast radius if an agent goes wrong?”
Scope your answer to the specific agent and tools in question. An agent that can only call read-only tools has a much smaller blast radius than one with write access to production systems. If you’ve used agent-scoped tool sets to limit permissions to exactly what the task requires, say so. For irreversible actions like data deletions or financial transactions, require human oversight and human approval, and use Real-Time Policy Enforcement to intercept high-risk actions before execution.
See How Obot Answers These Questions Out of the Box
Now that you know what questions are coming, here’s what to have ready. Security teams move faster when you come prepared. Before the meeting, have answers ready for each category above — and ideally, documentation to back them up. That means:
A diagram or description of your MCP architecture, showing where the control plane sits
Documentation of whether you use local MCP servers or remote MCP servers, and the different trust assumptions for each deployment model
A summary of which systems each MCP server connects to and what data it can access
A registry or allowlist review showing which servers are approved and excluding unofficial or untrusted servers. Since there’s no official repository, malicious servers could otherwise slip in and lead to unauthorized access or data breaches
Evidence of your access control model (IdP integration, group mappings, tool-level scoping), plus any security measures used to reduce server onboarding risk
Your audit log setup: what’s captured, retention period, and how logs can be exported
Your token storage and revocation process
Your LLM routing and any applicable data processing agreements
You don’t need all of this on day one. But the more of it you can produce, the shorter the review cycle.
The Framing That Helps
Security teams aren’t trying to kill MCP projects. They’re trying to understand the risk and make sure someone has thought about it. Because the model context protocol is an open standard that lets AI systems connect to external tools and data with less custom integration work, this review exists to make sure that interoperability doesn’t outpace governance and to align with a forward-looking MCP security risk action plan at the CTO level. Coming to the review with clear answers — and a control plane that centralizes auth, access controls, auditing, and filtering — changes the conversation from “can we approve this” to “how do we operate this safely.” MCP operates in a client-server model, where the host application manages connections to servers that broker access to outside systems and maintain state, permissions, and other capability metadata.
The teams that move fastest through MCP enterprise security review are the ones who’ve already answered these questions for themselves.
This post is part of Obot’s series on enabling MCP at enterprise scale. Obot is an open source MCP gateway with built-in access controls, audit logging, token brokering, and filtering. Learn more at obot.ai.
