Whitepaper
MCP Security and Tool-Space Governance
How to control the connector layer where agent risk becomes real.
Thesis
MCP is becoming the connector layer for agentic AI. It gives AI applications a standard way to discover tools, read resources, and connect to external systems. That makes it powerful. It also makes it dangerous. Tool access is where agent risk becomes real: a model moves from conversation into execution, data access, workflow mutation, and delegated authority.
The Model Context Protocol documentation describes MCP as an open-source standard for connecting AI applications to external systems, with tools, resources, and prompts exposed through clients and servers. Its architecture includes hosts, clients, servers, a data layer, a transport layer, lifecycle negotiation, tool discovery, and tool execution. That architecture creates a new security domain: tool-space governance.
The Tool-Space Problem
Traditional API security assumes the caller knows what it is calling. Agentic systems are different. The model reads tool names, descriptions, schemas, prior context, and user intent, then chooses a tool. That means a tool description can influence behavior. A harmless-looking tool can become dangerous when chained with another tool. A trusted server can change its capabilities after approval. A remote connector can create confused deputy, SSRF, token, and consent risks. An agent can be tricked into using the right tool for the wrong purpose.
| Risk | What it looks like | Control |
|---|---|---|
| Tool poisoning | Malicious instructions hidden in tool metadata or descriptions. | Static vetting, signed manifests, human-readable diffs. |
| Rug pull | Tool changes after approval or install. | Version pinning, re-approval on capability change. |
| Parasitic chaining | One tool obtains data that another tool exfiltrates or mutates. | Cross-tool policy, data-flow constraints, allowlisted paths. |
| Confused deputy | Proxy or OAuth flow grants unintended access. | Per-client consent, exact redirect validation, audience-bound tokens. |
| SSRF and egress | OAuth or metadata discovery reaches internal services. | HTTPS requirements, private-IP blocking, egress proxy. |
Reference Architecture
The safe pattern is to place an MCP governance broker between the AI host and the tool ecosystem. The host should not blindly merge every discovered tool into the model context. Each server should be inventoried, authenticated, risk-tiered, and assigned policy. Each tool should be validated before exposure. Each call should pass through a policy decision point. Each result should be logged with trace ID, tool version, arguments, output classification, and side-effect status.
| Component | Responsibility |
|---|---|
| MCP inventory | Track hosts, clients, servers, transports, versions, owners, and environments. |
| Tool registry | Store tool metadata, schemas, risk tier, allowed callers, and approval requirements. |
| Policy broker | Decide allow, deny, or approval_required before tool exposure and before call execution. |
| Authorization layer | Use OAuth 2.1 patterns, protected resource metadata, token audience validation, PKCE, short-lived tokens, and secure storage. |
| Execution verifier | Validate arguments, destination, scope, and expected side effects. |
| Audit log | Record discovery, metadata change, call attempt, policy result, approval, and execution result. |
Governance Requirements
Evening Star should recommend five hard requirements for production MCP. First, deny by default. New MCP servers and new tools should not be automatically visible to high-privilege agents. Second, separate discovery from execution. A model can know that a tool exists without being allowed to call it.
Third, bind authority to purpose. A calendar-read tool, a file-write tool, and a deployment tool have different risk levels and should require different approval paths. Fourth, treat tool metadata as untrusted input. Names, descriptions, prompts, and schemas can carry adversarial influence. Fifth, make revocation fast. If a server, tool, credential, or descriptor becomes suspicious, the broker must be able to remove it immediately.
A Practical MCP Control Checklist
| Before connection | At runtime | After incident |
|---|---|---|
| Register owner, purpose, transport, scopes, data class, and server origin. | Enforce policy on discovery and calls; validate schemas and network destinations. | Freeze tool, revoke token, preserve trace, review descriptor diff, add eval case. |
| Review metadata and prompts for hidden instructions or excessive scope. | Require approval for write, delete, external-send, deploy, or privileged admin actions. | Rotate credentials, patch server, update registry risk tier. |
| Pin version and require re-approval for changed capabilities. | Log call intent, arguments, output class, and side effects. | Publish a governance note when users or operators need to know. |
Why This Matters
MCP will make agents more useful because it standardizes access to tools and data. But every standard connector eventually becomes a security boundary. The teams that win will not be the teams that connect the most tools the fastest. They will be the teams that know which tools exist, what they can do, who approved them, what they touched, and how to shut them down when something breaks.
For Evening Star AI, MCP Security and Tool-Space Governance should become the technical companion to the governance stack. Governance says the control plane must exist. MCP shows where the control plane must bite.
References
- Model Context Protocol: What is MCP?
- Model Context Protocol: Architecture overview
- Model Context Protocol: Security Best Practices
- Model Context Protocol: Authorization specification
- MCP-38 threat taxonomy for Model Context Protocol systems
- MCP-DPT defense-placement taxonomy for Model Context Protocol security
- Model Context Protocol threat modeling and tool poisoning analysis