A practical checklist for MCP governance
Follow one agent tool call from server inventory to authorization, approval, execution, and evidence with this seven-step MCP governance checklist for security teams.
By Halo Security Engineering
A list of approved MCP servers is a useful starting point for agent governance. It leaves open what an agent can do with the tools those servers expose. A more useful exercise follows one action from discovery all the way to execution.
MCP, the Model Context Protocol, is an open protocol introduced by Anthropic in November 2024 for connecting AI applications to tools and data. The glossary entry for the Model Context Protocol gives background. This checklist covers what to govern on that connection.
Follow one tool call from inventory to authorization to approval to evidence. Gaps show up at the step where the trail goes cold.
The checklist at a glance
| Step | Question to answer | Evidence to keep |
|---|---|---|
| Inventory | Which servers and tools exist, and who owns them? | Server list with owners, versions, and exposed tools |
| Actors | Who delegated the work, and which credential acts? | Delegator, agent identity, and credential binding |
| Authorization | Is this operation allowed on this resource with these arguments? | Policy version and decision |
| Approval | Does a person need to confirm it? | Approver, request details, and expiry |
| Boundary test | Can the agent reach the service another way? | Test results and remaining exposure |
| Evidence | Can a reviewer reconstruct the call? | Server and tool identity, actor, and outcome |
| Capability check | Does the vendor govern execution or only query records? | A live demonstration |
Walk through the seven checks
1. Inventory the servers and tools
Record each server, its owner, its connection method, and the tools it exposes. Track versions and configuration changes. A familiar server name should not hide a newly added operation or broader access than the reviewer originally approved.
Local servers need attention too. A developer can run a server on a laptop and connect it to an AI client in minutes, so a list maintained by hand will lag behind the servers that exist. For the full path from inventory to runtime, see our post on MCP security from server inventory to runtime enforcement.
Review tool descriptions as well as tool names. The model reads those descriptions when it chooses a tool, so a changed description can change behavior. It is also one route for prompt injection to reach an agent.
2. Identify the actors
The agent and the person delegating the work are related, and they are separate identities. Preserve both where the architecture supports it, and show which credentials authorize the eventual action. Shared credentials can make accountability and revocation hard to reason about.
For example, suppose a support lead asks an agent to close stale tickets. The record should show the support lead, the agent, and the credential used. If the credential belongs to a shared service account, the record should say so, and the team should decide whether that is acceptable.
3. Scope authorization to the operation
Reading a ticket and closing it are different actions. An agent that needs one should not automatically receive the other. Include the target resource and the relevant arguments in the policy decision, and validate that the enforcement point can actually check them.
Sorting tools into tiers gives approval rules something concrete to attach to.
- Read only. The tool retrieves information and changes nothing.
- Reversible change. The tool makes an edit that can be undone, such as a comment or a label.
- Consequential change. The tool closes, deletes, pays, sends, or publishes.
4. Define when approval is required
A high-impact operation may need a person to review the proposed change. The approval should cover a specific action and context, expire when appropriate, and be checked again if the request changes.
A general acknowledgement in a chat thread may fall short as evidence of an authorized action. Our post on an agent's permission and the action decision describes what a specific approval looks like.
5. Test the boundary
Try the approved path, a prohibited operation, and a changed argument. Where applicable, test direct access to the underlying service as well as the MCP route.
| Test | Example | Result to record |
|---|---|---|
| Approved path | Read a ticket through the MCP route | Allowed, with the decision recorded |
| Prohibited operation | Close a ticket without approval | Blocked or held for approval |
| Changed argument | Approve one refund amount, then submit another | A new decision, per your policy |
| Direct access | Call the ticket system's API with a different credential | The scope you documented as in or out |
If the agent can bypass the intended control with another credential or tool, record that remaining exposure. The last row shows where the MCP control ends, which is the information a risk owner needs.
6. Preserve useful evidence
Capture the server and tool identity, the actor, the relevant request context, the policy version, and the outcome. Limit sensitive payload collection to what investigation and accountability require. Make the collection and retention choices visible to administrators.
See what an AI audit log should contain for a field list.
7. Ask which MCP capability a vendor means
Two different product capabilities share the MCP label.
- Querying. The product uses MCP to query governance records.
- Governing. The product governs MCP tool execution.
A platform can provide one without providing the other. Ask the vendor to demonstrate the exact capability you need, using your own tool and your own policy.
A short worked example
Take a hypothetical ticketing server that exposes read, comment, and close operations. Applying the checklist might produce these decisions.
- Reading and commenting are allowed for the support agent on tickets in its own queue.
- Closing a ticket requires approval from the queue owner.
- The approval covers one ticket and expires after a short window.
- A direct API call with a personal token falls outside the control, and the team records it as remaining exposure.
Each decision maps to a row in the checklist, and each one leaves evidence a reviewer can inspect.
How Halo helps
Halo's MCP and tool gateway applies identity, policy, approvals, budgets, and evidence to agent traffic, and credential brokering keeps credentials bound at the gateway so agents receive scoped capabilities and never see raw keys. Policy as code supports tool-level checks, and human approval gates cover higher-impact actions. Halo Endpoint's metadata-first discovery looks at AI-related configuration files, with paths, hashes, and permissions as evidence, which can give your server inventory leads, though no discovery method finds everything. Bring one realistic tool action to a walkthrough, and read more about AI agent governance and the Model Context Protocol integration.