Model Context Protocol changes the enterprise AI conversation.
An agent is no longer limited to generating text. Through MCP, an AI application can discover and invoke tools connected to systems where enterprise data and actions live.
That may include GitHub, Jira, Slack, databases, cloud platforms, CRM systems, internal APIs, deployment systems, support platforms, and file stores.
The productivity upside is obvious.
The security implication is equally important:
Every MCP tool exposed to an agent expands the set of actions that agent may be able to perform.
MCP should therefore be treated as an authorization surface—not merely an integration standard.
MCP turns tools into agent capabilities
At a simplified level:
AI Agent
|
v
MCP Client
|
v
MCP Server
+-- tool: get_customer
+-- tool: create_ticket
+-- tool: issue_refund
`-- tool: delete_account
The important question becomes:
Which of those tools should this particular agent be allowed to invoke?
An agent being able to connect to an MCP server should not automatically mean it should receive every capability exposed by that server.
Authentication is not the same as authorization
Authentication answers:
Who is calling?
Authorization answers:
What may they do?
The MCP ecosystem supports OAuth-based authorization patterns, including server-level and per-tool approaches.
But enterprises still need to define their authorization model.
Support Agent
+-- get_customer ALLOW
+-- get_order_status ALLOW
+-- create_ticket ALLOW
+-- issue_refund DENY
`-- delete_account DENY
The correct permissions depend on the agent's business role and risk profile.
Tool descriptions become part of the attack surface
Agents decide when to invoke tools based partly on context and tool descriptions.
Security teams should inventory:
- server owner;
- tool name;
- tool description;
- input schema;
- downstream system;
- required credential;
- read/write behavior;
- destructive potential;
- data classification;
- approval requirements.
An MCP inventory should look more like an entitlement catalog than an integration list.
Risk 1: excessive tool access
Suppose an engineering MCP server exposes:
list_repositories
read_file
create_branch
merge_pull_request
delete_repository
change_org_settings
If the agent receives every tool, it now has significantly more capability than the business workflow requires.
The principle should be:
Expose the minimum tool set required by the agent's job.
Risk 2: confused-deputy behavior
An agent can act as a deputy between untrusted content and privileged enterprise systems.
Malicious ticket text
|
v
Support Agent
|
v
MCP tool
|
v
Customer database
If the agent interprets malicious content as an instruction and then calls a privileged tool, an attacker may indirectly influence a system they could not access directly.
This is one reason authorization cannot live only in prompts.
Risk 3: credential passthrough
MCP integrations often need credentials.
Poor architectures may place static tokens directly inside local configuration, environment variables, MCP server configuration, or agent environments.
Prefer scoped OAuth tokens, workload identities, short-lived credentials, centralized secret storage, credential mediation, and explicit resource audiences.
Risk 4: server trust
An MCP server is software.
Enterprises should evaluate who published it, where it runs, how it is updated, its dependency chain, what systems it can access, how credentials are stored, and whether it can reach the internet.
"Available in a registry" should not mean "approved for production."
Risk 5: tool output becomes model input
Tool responses return data to the AI application.
That introduces a second trust direction:
External MCP server
|
malicious output
|
v
Agent
|
v
Internal privileged tool
Tool output can influence subsequent model behavior. Treat MCP responses as potentially untrusted content unless the source is explicitly trusted.
Build an MCP governance layer
At enterprise scale, MCP governance should answer four questions.
Which servers are approved?
Maintain an authoritative registry.
Which tools does each server expose?
Inventory them.
Which agents may invoke which tools?
Create explicit policy.
Which identity is used downstream?
Avoid anonymous or broadly shared credentials.
Enterprise MCP Catalog
|
approved servers/tools
|
v
Agent ---> Policy Enforcement ---> MCP Server
|
+-- identity
+-- tool allowlist
+-- network policy
`-- audit
Where OpenShell can help
OpenShell supports application-layer network-policy definitions, including MCP-aware rules in its policy schema.
That lets enterprises add another enforcement layer between the agent and MCP endpoint.
For example:
Agent A:
tools/list -> allowed
tools/call/read_status -> allowed
tools/call/delete_resource -> denied
This does not eliminate the need for authorization inside the MCP server itself. It creates defense in depth.
Protect the downstream system too
The strongest architecture uses multiple layers:
Agent Policy
|
v
MCP Authorization
|
v
Downstream API Authorization
|
v
Business Rule / Approval
An agent may call issue_refund, but the runtime limits the server, the MCP server verifies identity, the payment platform restricts scope, and high-value refunds may still require human approval.
Create MCP risk tiers
Tier 0 — Public/read-only
Public docs, search, non-sensitive metadata.
Tier 1 — Internal read
Jira issues, internal knowledge bases, repository read.
Tier 2 — Business write
Create ticket, modify CRM record, send internal message.
Tier 3 — Privileged/destructive
Deploy production, modify IAM, delete resources, issue payments, rotate secrets.
Different tiers should receive different identity, logging, approval, and policy requirements.
Questions CISOs should ask about MCP
- How many MCP servers are deployed?
- Who approves new servers?
- Which tools does each expose?
- Which tools can modify data?
- Which tools are destructive?
- Which credentials do servers use?
- Are those credentials shared?
- Can agents invoke every advertised tool?
- Are MCP calls centrally logged?
- Can access be revoked without editing agent code?
- Are third-party MCP servers security-reviewed?
- Is tool output treated as trusted or untrusted input?
MCP is an opportunity to get authorization right
MCP can become one of the most useful standards in enterprise agent architecture. But its power comes from giving models access to real systems.
The enterprise objective should be:
Make tools easy for agents to discover while making permissions explicit, constrained, attributable, and revocable.
How Anpu Labs helps
Anpu Labs' Secure Agent Infrastructure Assessment inventories MCP servers and tools alongside agents, credentials, systems, and data flows.
We map which agents can reach each server, which tools they can invoke, what downstream identities are used, which operations are destructive, and where policy and audit gaps exist.
References
- MCP TypeScript SDK v2: https://ts.sdk.modelcontextprotocol.io/v2/
- MCP Apps Authorization: https://apps.extensions.modelcontextprotocol.io/api/documents/authorization.html
- MCP Go SDK Security and Authorization: https://go.sdk.modelcontextprotocol.io/protocol/
- NVIDIA OpenShell Policy Schema: https://docs.nvidia.com/openshell/latest/reference/policy-schema
