MCP Security: Threat Modeling and Governing Tool Execution for Enterprise AI Agents

Model Context Protocol can give AI systems a structured way to discover and invoke tools.

That makes MCP useful.

It also makes the execution boundary important.

The central security question is not simply:

Can the agent see or call this tool?

It is:

Does this exact proposed tool action currently have authority to become a real side effect?

Capability: the technical ability to invoke or interact with a tool.

Execution authority: the current bounded authority required for a consequential action to proceed.

Execution boundary: the point at which a proposed action can become a real side effect in an external system.

Demonstrated: backed by current implementation or bounded test evidence represented in this article's factual packet. It does not mean every MCP server, tool, client, gateway or execution path is controlled.

MCP expands the agent's capability surface

An enterprise agent may use MCP-connected tools to interact with:

• files;
• databases;
• cloud infrastructure;
• source repositories;
• ticketing systems;
• internal APIs;
• financial systems;
• messaging systems; or
• administrative controls.

Tool discovery and connectivity are valuable capabilities.

But connectivity alone should not establish unrestricted authority.

The fact that a model can formulate a valid tool call does not answer whether that action should be permitted in the current context.

Threat-model the action, not only the model

An MCP security review should examine what happens after the model decides to use a tool.

A useful threat model includes:

This shifts MCP security from a purely conversational problem to an execution-control problem.

Tool annotations are useful metadata, not authority

The official Model Context Protocol project has described tool annotations as a vocabulary for communicating properties and risk characteristics of tools.

That metadata can help a client reason about how a tool should be presented or treated.

But metadata is not the same thing as enforcement.

A tool labelled read-only, destructive or otherwise sensitive still exists inside a larger trust and execution model.

If an untrusted server provides misleading metadata, the label itself cannot be treated as a cryptographic or policy-backed authorization decision.

Prompt injection can become an execution problem

Prompt injection becomes particularly consequential when model output can influence real tools.

An injected instruction may try to convince an agent to:

• access information outside the intended task;
• invoke an unnecessary tool;
• modify a sensitive resource;
• send data to an unintended destination;
• perform an administrative action; or
• chain several individually plausible actions into an unintended outcome.

Model-level defenses can reduce risk.

But where the consequence is external and material, the architecture should also control the execution path.

The downstream system should not depend solely on the model correctly deciding that an action is safe.

Worked example: governing an MCP tool call

Suppose an MCP-connected agent can propose:

delete_resource(resource_id="prod-db-4")

The existence of the tool establishes technical capability.

It does not establish authority to delete that production resource.

Before execution, a governed path can evaluate:

1. which agent or operating context proposed the action;
2. whether deletion is within the agent's permitted capability;
3. whether prod-db-4 is inside the authorized resource scope;
4. whether current policy permits deletion;
5. whether human review is required;
6. whether authorization is bound to this exact resource and action;
7. whether that authorization is still fresh;
8. whether relevant authority has been revoked;
9. whether the authorization has already been consumed or replayed; and
10. whether the downstream executor can verify the required evidence immediately before deletion.

Now change the proposed action to:

delete_resource(resource_id="prod-db-5")

Authority for prod-db-4 should not silently become authority for prod-db-5.

The tool capability may be identical.

The authorized action is not.

Capability is not authority

An MCP server can expose a powerful tool while the organization deliberately grants only narrow authority to the agent using it.

That distinction matters for tools capable of:

• deleting resources;
• writing files;
• deploying software;
• changing permissions;
• sending messages;
• modifying production infrastructure; or
• causing financial side effects.

Technical reach should not be treated as unlimited delegated authority.

Privilege boundaries should be explicit

Enterprise MCP deployments should identify where privilege enters the system.

That may include:

1. the model;
2. the MCP client;
3. the MCP server;
4. credentials available to the server;
5. downstream APIs;
6. gateways or policy services; and
7. the executor capable of causing the side effect.

A secure design should avoid assuming that because one component is trusted, every downstream action originating through it is automatically authorized.

The narrower the authority exposed to each component, the easier the execution path is to reason about.

Gateways can help, but the enforcement point matters

A gateway can be useful for:

• identity checks;
• routing;
• logging;
• policy evaluation;
• request filtering;
• authorization decisions; and
• evidence collection.

But a gateway decision alone does not prove the eventual side effect obeyed that decision.

If the system says:

ALLOW

and a downstream executor later performs a materially different action, the authorization boundary has failed.

The architecture therefore needs a relationship between the approved action and the action that is actually executed.

Bind authorization to the proposed action

Consider:

write_file(path="/workspace/report.md", digest="abc123")

If authority was issued for that exact action, changing the path to:

/etc/security/config

should not inherit the original authority.

Likewise, modifying material arguments after authorization should require the action to be evaluated again.

Action binding reduces the gap between:

what was permitted

and:

what the executor actually attempts to do

Freshness and revocation matter

An authorization decision can become stale.

Between decision and execution:

• policy may change;
• authority may be revoked;
• the permit may expire;
• workflow state may change;
• the target resource may change; or
• the action itself may be modified.

A historical ALLOW therefore should not automatically be treated as current execution authority.

For consequential actions, the governed path can verify current authorization state immediately before the side effect.

Replay is also an MCP execution risk

Retries are common in distributed systems.

That means replay protection matters when a tool action should occur only once.

A valid one-time authorization should not silently become authority to perform the same consequential operation repeatedly.

Replay controls can bind authority to an action identifier, action digest or other bounded execution state.

Downstream executor verification closes the loop

The strongest point in the execution path is the component that can actually cause the external side effect.

For an integrated governed path, that executor can verify the required authorization before executing.

A simplified flow is:

Agent → MCP/tool request → governance decision → bounded authorization → executor verification → side effect

If verification fails, the governed side effect should fail closed.

This is different from simply logging the model's decision or attaching a policy result to the request.

Read-only evidence is not execution authority

Audit evidence, replay records, screenshots and historical decisions can prove what happened.

They should not automatically become reusable execution credentials.

A read-only artifact can demonstrate that an earlier decision existed without carrying authority to cause another side effect.

Keeping those roles separate reduces the risk of evidence being accidentally reused as execution input.

What the current primary sources say

• Model Context Protocol — Tool Annotations as Risk Vocabulary: What Hints Can and Can't Do: The official MCP project explains that tool annotations can describe behaviors such as read-only or destructive operation, but they do not prevent prompt injection and are not enforcement; clients must treat annotations from untrusted servers as untrusted.
• Amazon Web Services — Secure agent tool usage: AWS states that every agent tool invocation should be authorized against declarative policy before execution, with agent identity and originating user context carried through the authorization chain.
• NIST / NCCoE — Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization: NIST NCCoE describes AI-agent access to data, tools and applications as creating a need for appropriate identification and authorization controls, and identifies authorization and auditing as areas requiring standards and best-practice work.

These sources provide technical context only.

They do not endorse Sentinel, prove a Sentinel MCP deployment, establish a partnership or establish identical guarantees.

How this maps to Sentinel

Sentinel's relevant demonstrated controls concern explicitly integrated governed execution paths.

For the evidence admitted to this article, the DEMONSTRATED claims are:

• Sentinel uses fail-closed behavior on governed execution paths.
• Sentinel binds authorization evidence to a canonical action digest.
• Sentinel uses Ed25519-signed authorization evidence on governed execution paths.
• Sentinel checks permit freshness using bounded validity windows.
• Sentinel rejects replay of previously consumed governed actions.
• Sentinel checks current authorization state immediately before bounded side effects.
• On bounded integrations, the executor locally verifies authorization evidence immediately before the side effect.
• Sentinel maintains tamper-evident append-only audit evidence.
• Sentinel does not treat read-only replay or evidence artifacts as execution authority.

The bounded Sentinel model is:

1. an agent proposes an action;
2. the governed path evaluates the action;
3. authorization is bound to the relevant action state;
4. freshness, revocation or replay controls can be checked where implemented;
5. the executor or governed path verifies authorization immediately before the side effect; and
6. evidence records the decision and execution relationship.

This does not mean Sentinel automatically controls all MCP traffic.

It does not mean every MCP server or tool is governed by Sentinel.

It does not mean traffic that bypasses an explicitly integrated Sentinel boundary is controlled.

A practical enterprise MCP threat model

For each consequential MCP tool, document:

1. Tool capability — what can the tool technically do?
2. Principal — which agent, workflow or operating context is requesting the action?
3. Scope — which resources and operations are inside that workflow's role?
4. Material parameters — which arguments change the consequence of the action?
5. Policy — what rules determine whether the proposed action is admissible?
6. Human review — which actions require explicit review under organizational policy?
7. Freshness — how long can authorization remain valid?
8. Revocation — what state can invalidate previously issued authority?
9. Replay — can the same authorization be used more than once?
10. Executor — which component actually causes the external side effect?
11. Verification — what must that executor verify immediately before acting?
12. Evidence — what proves the relationship between proposal, decision, authorization, verification and outcome?

MCP security needs a boundary outside the model

A capable model can reason about tools.

It can select tools.

It can construct valid calls.

It can follow security instructions.

But consequential authority should not depend entirely on the model continuing to reason correctly.

An execution boundary outside the model can provide a deterministic point where the proposed action must satisfy current authority before becoming real.

That is the distinction between giving an agent access to tools and governing what it is allowed to do with them.

Practical next step

Pick one MCP-connected tool with a meaningful side effect.

Identify the exact component that performs that side effect.

Then ask:

What evidence of current authority must this executor verify immediately before execution?

If the answer is only:

the model chose the tool

or:

the MCP server exposed the tool

then capability and authority are still being treated as the same thing.

• Review Sentinel Proof
• Review Sentinel security boundaries
• Read the integration quick start
• Apply for a bounded founding integration

---

Research basis

This article uses verified primary-source MCP security guidance together with Sentinel's current Claim Registry and Content Admission Policy.

The MCP source establishes protocol-specific security context.

Sentinel-specific technical statements are separately limited to DEMONSTRATED claims admitted into this factual packet.

Boundary statement

Sentinel is not represented as controlling all MCP traffic, every MCP server or every MCP tool.

Execution claims apply only to explicitly integrated Sentinel-governed paths.

Tool metadata and annotations are not treated as execution authority.

An ALLOW or DENY response alone does not establish downstream enforcement.