PRACTICAL AI OPERATIONS
MCP Tool Permission Review: A Practical Checklist
Before you connect an agent to internal tools, write down the action, the identity and the data boundary. Then test whether the boundary holds. A tool name or a confirmation dialog is not enough evidence.
This is a review procedure for an individual engineer preparing a limited MCP pilot. The example below uses a fictional support workspace and synthetic data. It describes tests to perform; it does not claim that your server, client or deployment has passed them.
1. Start with one task and one effective identity
Take a concrete pilot: an agent may read three approved support articles and draft a reply to one synthetic ticket. It may not search other customer workspaces, send the reply, edit permissions or export attachments. This scope is small enough for a reviewer to understand and test.
Record the MCP client, server build, transport, tool inventory and the identity used for downstream access. A developer's admin account is a different permission boundary from a dedicated account with access to one test workspace. Review the effective permissions of that identity, including inherited access, rather than copying the name of an OAuth scope into a spreadsheet.
The MCP tools specification defines discovery through tools/list and warns that tool annotations are untrusted unless they come from trusted servers. Treat a label such as “read only” as something to verify against the implementation and account permissions. It is not an authorization policy.
2. Put the boundary into a permission matrix
Use one row per action. If a single tool both creates a draft and sends it, split those effects in the review. Ask whether the implementation can restrict them separately. A useful matrix makes the destination and enforcement point visible, not just the verbs “read” and “write.”
Illustrative policy for the synthetic support pilot:
| Action | Allowed boundary | Control to verify | Evidence to retain |
|---|---|---|---|
| Read article | Three approved test documents | Account and document ACLs | Allowed document succeeds; outside document is denied |
| Create reply draft | One synthetic ticket; no delivery | Draft-only API permission or server restriction | Draft exists; no message was sent |
| Send message | Disabled for this pilot | Downstream permission denies sending | Direct tool attempt is denied |
| Export attachment | Disabled for this pilot | Tool exposure and storage permission | No artifact or external transfer appears |
| Change access | Disabled for this pilot | No administrative rights | Permission-changing request is denied |
Add an owner, review date and expiry to every approved row. A blank cell means unresolved work. If the downstream API cannot separate a needed action from a dangerous one, narrow the pilot, introduce an independently enforced restriction or leave the integration disconnected.
Read access also deserves a destination check: an agent that can read a private document and call an outbound tool can move that content elsewhere. Review combinations of tools, not only each tool in isolation.
3. Inspect approval and credential handling separately
For a later pilot that allows sending, a proposed review rule could require approval for the exact recipient, message and attachment set. If any of those changes, require a new review. This is an operating rule to implement and test in the chosen client; a sentence in an agent prompt does not establish that enforcement.
The MCP specification recommends human oversight and the ability to reject calls, but it does not prescribe one universal approval interface. Observe the actual client: can a reviewer see the action's arguments, cancel it and distinguish a draft from a send? Test cancellation with synthetic data and verify that no side effect occurred.
Remote authorization and local process access need different reviews. For a remote service, identify the token's intended audience, requested permissions and revocation path. For a local stdio server, inspect the launched executable, inherited environment and accessible directories. Do not assume a local process becomes isolated merely because it speaks MCP.
The official MCP security guidance prohibits accepting a token that was not issued for the MCP server and explains risks from local server execution and excessively broad scopes. Review the applicable section for your transport and implementation. Keep actual secret values out of screenshots, prompts and the review record.
4. Test the denied paths before expanding access
Run these exercises only in an authorized test environment with synthetic records and destinations you control. Describe the expected denial before running the attempt; record what actually happened afterward. A model declining a request is not the same as the server denying it.
- Outside resource: request a document that the pilot identity must not access. Check the server response and audit record, not just the agent's final answer.
- Prohibited effect: attempt a send through the tool while the pilot is draft-only. Verify the external system contains no delivered message.
- Changed destination: where exact-action approval exists, change the synthetic recipient after approval. Confirm the revised action cannot reuse the earlier decision.
- Untrusted instructions: place a harmless instruction to ignore the task inside a test document. Confirm the workflow treats it as document content and does not grant new tool permissions.
- Revocation: revoke the pilot credential or disable the test account. Confirm later access is denied, and document any relevant session or cache behavior.
- Tool change: modify the test server's tool schema or allowed destination. Confirm the owner notices the change and repeats the relevant review.
These exercises provide evidence about specific paths, not a universal prompt-injection defense. For the broader input review, use the existing prompt-injection risk guide. If your agent also writes code, pair the permission review with independent CI acceptance checks.
5. Record a decision that another engineer can inspect
Keep the tool and client versions, account identifier, policy rows, test identifiers, timestamp, result and evidence location together. Prefer redacted record identifiers and error categories over full customer content. Assign retention and access rules to the evidence itself.
Use three explicit outcomes: approved for this bounded pilot, blocked pending a named fix, or not tested. Do not turn the last outcome into a green check. Reopen the review when tool capabilities, downstream permissions, client behavior or the data boundary changes.
- Every enabled action has an owner and a defined resource boundary.
- Each prohibited effect has evidence of enforcement outside the prompt.
- Cancellation and credential revocation have been exercised.
- The operator knows how to disconnect the integration and investigate an incident.
- Unresolved findings and the next review date remain visible.
Watch the first lesson, then work through the course
Inspect what your MCP agent can actually do — free lesson 1 on YouTube ↗. The lesson is in English and uses a local exercise with synthetic data.
MCP Security & AI Agent Operations: all eight lessons and the original toolkit includes 2h 00m of English video and eight supplementary exercises. Continue through identity and tenant boundaries, prompt injection, exact-action approval, tokens, audit records, rollout gates and an incident drill.
The download contains MP4 videos, a local HTML course library, transcripts, chapter markers and separate SRT subtitle files. Load the SRT files in a compatible player; the included HTML player has no subtitle switch. Review all eight lessons and prerequisites before choosing the course.
Apply the review to your own systems
The toolkit supports human-reviewed work. It does not enforce runtime permissions or certify a deployment.
For a review across your real identities, systems and owners, contact Cloudpeakify about an AI agent and MCP review. Describe the client, tools, data boundary and decision you need to make. Team and client-delivery use require the appropriate terms.
Related: CI checks for coding agents · Free repository readiness checklist · AI and operations toolkits.