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.
Part 8 | MCP Prompt Injection: Why Your AI Agents Can’t Defend Against It Alone (Coming Soon)
Part 9 | MCP PII Data Security: How Tool Calls Leak PII and How to Stop It (Coming Soon)
Part 10 | MCP Enterprise Architecture That Actually Works: The Complete Reference (Coming Soon)
MCP Enterprise Security: The Access Control Questions
“Who has access to which MCP servers?”
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. The marketing team sees the marketing tools. Engineering sees the engineering tools. No one sees what they don’t need.
“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 API keys. Remove someone from the relevant group in Entra or Okta and their MCP access ends — automatically, immediately, without anyone manually updating a config.
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.
Try Obot Today
⬇️ Download the Obot open-source gateway on GitHub and begin integrating your systems with a secure, extensible MCP foundation.
The Audit 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, logged with the user’s identity, timestamp, server name, and tool identifier. Not just that something happened, but who did it and what exactly they called.
“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. 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. Make sure your logging infrastructure matches what your compliance obligations require.
The Credential Questions
“Where are OAuth tokens stored?”
“In the client” is not the right answer. Tokens are credentials. 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 config files or environment variables on developer machines, that’s worth fixing before the review.
“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, and have a plan for improving it.
“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.
The 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. 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.
“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.
The Agent Security Questions
“Can an agent be manipulated into taking actions it shouldn’t?”
This is the prompt injection question, and it’s increasingly on security teams’ radar. 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
“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.
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
A summary of which systems each MCP server connects to and what data it can access
Evidence of your access control model (IdP integration, group mappings, tool-level scoping)
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. 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.”
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.
