MCP gives agents a standard way to connect to external tools and data sources. The practical security question is not “do we use MCP?” It is whether a coding session can call a tool that writes to GitHub, Jira, Slack, cloud, data stores, incident systems, customer systems, or internal APIs using a standing token.
What to map for each MCP tool
Tool and operation
List the declared tool, callable operations, read/write behavior, and whether the call can mutate external or internal state.
Credential
Identify OAuth grant, service token, PAT, app credential, local token, or delegated user identity.
Target system
Connect the tool call to GitHub, Slack, Jira, cloud APIs, incident tools, data stores, package systems, or internal APIs.
Approval and evidence
Record who approved the tool call, why it was allowed, which policy applied, and where the outcome is logged.
MCP tool risk tiers
| Tier | Examples | Default review |
|---|---|---|
| Read-only | Docs search, repo lookup, ticket search, read-only logs. | Allow with owner and logging. |
| Write-capable | GitHub issue writer, Jira transition, Slack sender, PR commenter. | Approve based on target, audience, and reversibility. |
| Privileged | AWS deploy helper, database query tool, customer lookup, incident system action. | Require explicit approval, scoped credential, and outcome evidence. |
Risks worth reviewing first
- Tools that can write, delete, deploy, publish, change tickets, notify customers, or call production-adjacent APIs.
- Token passthrough or broad standing tokens where the tool carries more authority than the task needs.
- Tools reachable from repo instructions, agent settings, local config, or shared developer environments without clear owner.
- Missing evidence tying human request, agent session, tool call, credential, target, approval, and outcome together.
Starter boundary
Allow read-only and low-impact tools by default. Require approval for write, deploy, publish, destructive, customer-facing, data-access, cloud, or privileged internal-system calls. Block unmanaged token passthrough, ownerless tools, and tools that bypass existing approval paths.
Source notes
- MCP security best practices discuss confused deputy risk, token passthrough, session hijacking, and least-privilege authorization.
- Claude Code permissions docs describe tool permission decisions that are relevant when MCP tools become part of coding workflows.
- Clyra's identity guide explains why identity inventory is necessary but not enough without the action path.
Map one MCP tool path.
Clyra maps tool reachability, credential scope, owner, approval point, and evidence gaps for selected workflows.
Map one workflow