MCP Server Security 101: Inventory, Tool Calls, and Pre-Execution Control
MCP turns an AI agent from a text generator into an operator for files, SaaS apps, databases, internal APIs, browsers, and memory stores. An allowlist alone is not a security model.
Thesis
MCP security has to distinguish configured reach from observed use, inspect server and tool arguments before execution, preserve identity and workstation context, and record enough evidence to reconstruct side effects.
Technical readout
MCP security primitives
The MCP security question is never only whether a server is installed. The higher-value question is whether each server/tool/argument combination is acceptable for this user, workstation, repository, and session.
server provenance
Which MCP server was configured, where did it come from, which transport does it use, and which host reported it?
Inventory configured MCP servers from workstation scans and distinguish them from gateway-managed servers and observed runtime calls.
tool descriptor and call
Which tool did the model choose, what arguments were supplied, and what side effect could the server perform?
Record server name, tool name, operation type, argument keys, redacted values, response status, and verdict for each observed call.
identity and authority
Whose OAuth token, API key, local filesystem permission, or service account will the server use?
Bind MCP activity to the human user, workstation, policy group, source tool, host identity, and upstream account where available.
control point
Can the organization block the call before the MCP server runs, or only audit it after the fact?
Use hooks for supported workstation agents and an MCP gateway for managed server paths that require enforcement independent of client self-reporting.
Research artifact
MCP threat and control matrix
The most practical MCP controls are simple, but they need to be applied at the right stage.
A tool description or plugin instruction nudges the model toward unsafe behavior or data disclosure.
Tool name, server provenance, plugin source, prompt context, next action, and argument payload.
Activity evidence, plugin inventory, prompt/tool detections, and policy on the next high-risk action.
The model uses a legitimate server with the user's authority to do something outside the user's intent.
Human user, agent session, OAuth scope, repository, workstation, destination, tool, and argument intent.
Identity-bound policy, Runtime Shield, MCP activity, and gateway enforcement for managed MCP paths.
Secrets in files, environment variables, tool outputs, or arguments flow into an MCP call.
Sensitive paths, secret-like strings, env files, token patterns, tool output summaries, and redaction events.
Blocked reads, sensitive-read warnings, credential exfil detections, and redacted payload retention.
A filesystem, database, browser, or cloud server exposes more operations than the workflow needs.
Configured server, exposed tools, transport, account scope, host count, last seen, and activity volume.
Agent Inventory, MCP Activity, policy action buttons, and optional MCP Gateway for central managed servers.
A server response returns instructions that influence later model actions.
Tool output source, untrusted content markers, prompt-injection categories, and the next proposed action.
Detection-to-action correlation and policy escalation when suspicious content precedes sensitive operations.
Research artifact
Inventory is not enforcement
A useful MCP page should make configured reach and observed use visually distinct.
Configured MCP inventory
Visibility
Servers reported by a workstation scan, SessionStart, or other endpoint-side inventory check.
Control
Show server name, transport, command or URL, host count, last seen, source tool, and owner.
Known limit
Inventory can become stale and does not prove the server was called.
Observed MCP activity
Visibility
Runtime calls where a hook or gateway saw server, tool, arguments, verdict, and response summary.
Control
Filter by server, tool, source, host, user, policy, severity, and time window.
Known limit
Activity only covers the paths that pass through supported hooks or a controlled gateway.
Gateway-managed MCP
Visibility
Central servers exposed through an AgentKeeper-controlled gateway path.
Control
Stronger pre-execution enforcement, centralized inventory, tool policy, and upstream audit correlation.
Known limit
Requires teams to route selected MCP use through the gateway rather than direct local configuration.
Local ad hoc servers
Visibility
Developer-created or downloaded MCP servers running from the workstation.
Control
Detect through inventory scans and observed runtime calls, then move risky servers to policy or gateway management.
Known limit
A user can add, rename, or remove local configs between scans unless MDM and policy restrict drift.
Research artifact
MCP control maturity
Security teams can roll MCP security forward without blocking all agent tooling on day one.
Discover configured servers
90%Know which workstations report filesystem, GitHub, Notion, database, cloud, or custom MCP servers.
Observe calls and arguments
76%Record which tools actually run, which payloads matter, and which policies would have matched.
Warn on risky operation classes
62%Create analyst-visible warnings for exports, deletes, credential paths, external sends, and admin operations.
Block high-impact calls pre-execution
48%Move production database writes, broad file reads, secret exfil paths, and unreviewed tools to deny.
MCP moves the risk from text to authority
The Model Context Protocol is useful because it gives an agent structured access to tools and data. That same usefulness is the risk. A model that can call a filesystem server, a ticketing server, a database server, and a SaaS export tool is no longer only producing suggestions. It is operating through delegated authority.
The hard question is not whether MCP is good or bad. The question is whether the enterprise can see which servers exist, which tools are called, which arguments were supplied, whose authority was used, and whether policy made a decision before side effects occurred.
Allowlists are necessary and insufficient
An allowlist can keep obviously unapproved servers out of a managed environment, but it cannot distinguish safe and unsafe operations inside an approved server. A Notion lookup, a Notion page creation, and a Notion bulk export are materially different. A database schema read and a production delete are not the same risk just because they share one server.
AgentKeeper treats server identity as one signal in a larger event. The server, tool name, operation class, arguments, source agent, host, user, policy group, and session all matter.
Inventory and activity answer different questions
Inventory answers what the agent could reach. Activity answers what the agent actually used. Both are required. Without inventory, security misses shadow MCP servers before they are used. Without activity, security cannot tell whether a server was dormant, useful, risky, or abused.
This is why AgentKeeper separates workstation MCP configuration, installed plugins, and observed MCP activity. Empty inventory should not erase observed calls, and observed calls should not imply every configured server has been scanned.
Gateway control is the stronger long-term pattern
Hooks are a strong lightweight deployment model when the agent surface exposes enough context before execution. A gateway is stronger for managed MCP paths because the organization controls the chokepoint rather than relying only on each client to self-report.
The practical enterprise path is hybrid: use lightweight workstation hooks for rapid visibility and policy, then route high-value or high-risk MCP servers through a gateway when central pre-execution enforcement, consistent inventory, and upstream audit correlation are required.
Technical model
From configured server to governed call
MCP inventory tells you what could be reached. MCP activity tells you what the agent actually used.
MCP control path
tool_use request
policy gateway
Filesystem, cloud API, SaaS connector, internal service, database, browser, queue, or memory store.
Signals in the model
Agent runtime
Claude Code, Cowork, Cursor, Codex, Windsurf, or another tool runner that can call MCP tools.
MCP request
Server, tool, argument payload, source agent, user, host, session, and downstream authority.
Policy point
Hook or gateway normalizes, redacts, evaluates, and returns pass, warn, or block.
External capability
Filesystem, cloud API, SaaS connector, internal service, database, browser, queue, or memory store.
MCP governance is strongest when it evaluates the structured call before the server performs a side effect.
Sources and inspiration