MCP security checklist and threat modelUpdated Jul 19, 2026By Editorial Automation Desk

MCP Server Security Checklist: 25 Controls for AI Agents

Audit MCP server security with 25 source-backed controls covering authentication, permissions, prompt injection, secrets, sandboxing, logging, revocation, and allow-or-deny tests.

Best for: Engineering leaders, security reviewers, platform teams, and developer tooling owners.
Use this guide to: Answer how to secure an MCP server with source-backed protocol checks and clearly labeled operational controls.

Quick Answer

Secure MCP server connections to AI agents before any tool can act. Validate authentication and token audience, avoid token passthrough, grant least-privilege read-only access first, block secrets and undeclared network destinations, log high-impact calls without sensitive payloads, and prove revocation works. Human approval and attributable audit logs are KyenAI operational recommendations for destructive or production actions, not requirements imposed by the MCP specification.

Verified 2026-07-19

MCP security threat model

Review the server, client, credentials, data, network, and deployment as one trust boundary.

Prompt injection

Untrusted repository, issue, webpage, or tool output can steer an agent toward a dangerous MCP call. Treat this as a general AI agent tool security threat and keep consequential capabilities independently constrained.

Claim basis: KyenAI operational recommendation

Excessive permissions or scope

A client, server, or token with broader scopes than the workflow needs increases blast radius. MCP guidance recommends minimal scopes and incremental elevation when more access is required.

Claim basis: Official MCP requirement or guidance

Secret or token exposure

Token passthrough, insecure storage, logs, prompts, or server output can disclose credentials. MCP authorization guidance requires audience-bound token validation and rejects accepting tokens not issued for the MCP server.

Claim basis: Official MCP requirement or guidance

Unsafe writes or deletes

A valid tool call can still overwrite code, delete data, or mutate production state. Read/write separation and human approval are KyenAI operating controls, not claims that the MCP specification mandates those controls.

Claim basis: KyenAI operational recommendation

Network reach or SSRF

An MCP server that retrieves URLs or authorization metadata can become an SSRF path to internal services. Official guidance calls for URL validation, restricted redirects, and controls around private network destinations.

Claim basis: Official MCP requirement or guidance

Third-party supply chain or local server compromise

A malicious or compromised local MCP server can execute with the user's privileges and reach local data. Official guidance recommends explicit consent, sandboxing, least privilege, and trusted installation sources.

Claim basis: Official MCP requirement or guidance

25 launch controls

MCP server security checklist

Each control includes its risk, verification method, and an observable pass condition.

Download PDF Download CSV Download JSON

Control	Risk	Verification method	Pass criteria	Claim basis
01Validate access-token audienceFor HTTP transports, accept only access tokens explicitly issued for the MCP server and validate their audience before every protected request.	Critical	Send valid, wrong-audience, expired, and unsigned tokens to each protected endpoint.	Only the valid audience-bound token is accepted; every other token is rejected without reaching a tool.	Official MCP requirement or guidance
02Require per-client consentMCP proxy servers that reuse a third-party OAuth client must record consent per user and MCP client before forwarding authorization.	Critical	Authorize one client, then initiate the same flow from a new client ID while the original consent cookie remains present.	The new client receives its own consent screen and cannot inherit the first client's approval.	Official MCP requirement or guidance
03Validate redirect URIs, state, and CSRFUse exact redirect URI matching, single-use short-lived state values, CSRF protection, and secure consent cookies in OAuth flows.	Critical	Replay state values and try wildcard, changed, missing, and attacker-controlled redirect URIs.	Every mismatch or replay is rejected and approved redirects use exact registered values.	Official MCP requirement or guidance
04Reject token passthroughDo not accept an upstream token and forward it to another service without verifying that it was issued for the MCP server.	Critical	Present a token issued only for a downstream API and trace whether it can cross the MCP boundary.	The MCP server rejects the token and never forwards it downstream.	Official MCP requirement or guidance
05Minimize scopes and elevate incrementallyRequest the smallest initial scope set and add access only when a specific operation requires it.	High	Map every requested scope to one enabled method and run the workflow with optional scopes removed.	No unused wildcard or admin scope remains and elevation is explicit and operation-specific.	Official MCP requirement or guidance
06Protect and rotate secrets and tokensKeep credentials out of prompts, source control, tool output, screenshots, and ordinary logs; use managed storage and short-lived credentials where practical.	Critical	Scan configuration, prompts, logs, errors, screenshots, and source history, then rotate a test credential.	No plaintext credential appears and the old credential stops working after rotation.	KyenAI operational recommendation
07Never use sessions as authenticationAuthorize every inbound request independently; a session identifier must not substitute for an access token or user identity.	Critical	Reuse a captured session ID without valid authorization and attempt calls against another server instance.	The request is rejected and the session ID alone grants no capability.	Official MCP requirement or guidance
08Secure, bind, rotate, and expire session IDsGenerate non-deterministic session IDs, bind them to authorized user context, and rotate or expire them to limit hijacking.	High	Test predictable IDs, cross-user reuse, cross-instance replay, and expired-session behavior.	IDs are unguessable, user-bound, time-bounded, and rejected outside their authorized context.	Official MCP requirement or guidance
09Allow only safe authorization URL schemesAccept HTTPS authorization URLs in production and reject javascript:, data:, file:, vbscript:, and other executable schemes.	Critical	Return authorization endpoints using unsafe schemes, encoded variants, and HTTP on non-loopback hosts.	Only HTTPS production URLs and explicitly allowed loopback development URLs open.	Official MCP requirement or guidance
10Open authorization URLs without a shellUse platform URL APIs rather than cmd, sh, PowerShell, or interpolated shell commands when opening authorization links.	Critical	Supply URLs containing shell metacharacters, quotes, spaces, and encoded command separators.	The URL is parsed as data, no shell starts, and suspicious values are rejected and logged.	Official MCP requirement or guidance
11Block SSRF to private and metadata rangesValidate OAuth discovery URLs and block loopback, private, link-local, reserved, and cloud metadata destinations outside explicit development exceptions.	Critical	Try IPv4, IPv6, encoded, hostname, and cloud-metadata targets through every URL-fetching path.	All private or reserved destinations are blocked before connection and responses are not reflected.	Official MCP requirement or guidance
12Revalidate redirects and DNS resultsApply URL and IP validation to every redirect hop and defend against DNS rebinding or time-of-check/time-of-use changes.	High	Use redirect chains and a test hostname that changes from a public to a private address.	Every hop is revalidated and a destination change to a blocked address terminates the request.	Official MCP requirement or guidance
13Enforce an outbound network allowlistRoute server-side discovery and tool traffic through network policy or an egress proxy that permits only declared destinations.	High	Attempt direct IP, undeclared domain, private range, redirect, and DNS-rebinding egress from the runtime.	Only reviewed destinations succeed and bypass paths cannot reach undeclared networks.	Official MCP requirement or guidance
14Require consent before local server installationBefore one-click local setup, show the exact command and explain that it executes with the client's local privileges.	Critical	Start installation from a deep link or imported configuration and inspect the complete pre-execution consent flow.	No command runs before explicit approval and the user can cancel without side effects.	Official MCP requirement or guidance
15Display full commands and dangerous-pattern warningsDo not truncate local startup commands; highlight sudo, destructive deletion, network calls, and access to sensitive paths.	High	Test long, multiline, obfuscated, and destructive commands in the installation dialog.	The entire command is visible and dangerous patterns produce a clear warning before approval.	Official MCP requirement or guidance
16Sandbox local MCP serversRun local servers with minimal filesystem, process, and network privileges and require explicit grants for additional access.	Critical	Attempt to read outside allowed roots, spawn child processes, reach the network, and access system credentials.	Default-denied actions fail and each additional privilege requires a narrow explicit grant.	Official MCP requirement or guidance
17Restrict stdio proxy process spawningWhen a proxy can spawn stdio servers, isolate the proxy, authorize dangerous commands separately, and log process creation.	Critical	Use a compromised-client test to request an arbitrary executable, unexpected arguments, and access outside the sandbox.	Unapproved commands and arguments are denied and allowed process creation is attributable and contained.	Official MCP requirement or guidance
18Inventory and scope every exposed toolDecide visibility, callability, target scope, owner, rollback path, and approval policy for each tool rather than trusting one server-wide grant.	High	Enumerate tools with MCP Inspector and compare them with the approved capability inventory.	Every exposed tool has a declared workflow and no undeclared or wildcard capability remains.	KyenAI operational recommendation
19Separate read, write, and delete capabilitiesOffer a useful read-only profile without bundling mutation, deletion, secret, network, or production permissions.	High	Run the read-only workflow and attempt every mutation and deletion method with the same identity.	Reads work within declared roots while all write and delete attempts are denied.	KyenAI operational recommendation
20Contain prompt-injection-triggered tool callsTreat repository text, webpages, issues, and tool output as untrusted data that cannot widen tool permissions or bypass approval gates.	Critical	Place malicious instructions in each untrusted input source and observe requested tool calls and permission changes.	Untrusted content cannot expand authority, reveal credentials, or execute a consequential call without policy approval.	KyenAI operational recommendation
21Require human approval for consequential actionsPause immediately before destructive writes, secret use, production access, irreversible external messages, or permission expansion.	Critical	Simulate each consequential action and inspect the approval prompt, actor, target, rollback limits, and timeout behavior.	The action cannot proceed without an informed, current, target-specific approval.	KyenAI operational recommendation
22Keep attributable, secret-redacted audit logsRecord actor, session, server version, method, target, approval, timestamp, and outcome while excluding tokens and unnecessary payloads.	High	Run allowed and denied calls, then reconstruct them from logs and scan the records for credential patterns.	A reviewer can reconstruct consequential calls and no secret or sensitive payload is exposed.	KyenAI operational recommendation
23Pin and review server supply-chain inputsUse trusted distribution sources, pin reviewed versions or integrity records, inventory dependencies, and avoid unattended latest-version execution.	High	Rebuild from a clean environment and compare resolved packages, checksums, publisher identity, and startup command with the review record.	The reviewed artifact is reproducible and an unexpected publisher, version, or dependency blocks launch.	KyenAI operational recommendation
24Test revocation and incident responseMaintain a fast path to disable the server, revoke credentials and client access, preserve relevant records, and assess affected systems.	Critical	Run a tabletop incident, disable the server, revoke a test credential, and attempt the former workflow again.	Old access fails immediately, owners receive evidence, and restoration requires a documented decision.	KyenAI operational recommendation
25Validate allow and deny paths with MCP InspectorEnumerate resources, prompts, tools, notifications, and protocol exchanges, then test both expected success and expected failure behavior.	Medium	Run the Inspector against the exact reviewed server version and preserve results for every enabled capability.	The exposed surface matches inventory, allow cases work, deny cases stay denied, and errors reveal no secrets.	KyenAI operational recommendation

Capability decisions

MCP permission matrix

Capability	Default	Data risk	Approval	Logging	Launch gate
Read repository files	Allow read-only access to declared roots	Source code, internal documentation, and embedded sensitive data	Owner approval at onboarding; no per-call approval for declared roots	Log server, actor, session, method, root, and outcome; avoid file contents	Roots are explicit, symlink escape is tested, and secret-bearing paths are excluded
Write repository files	Deny until a bounded write workflow is approved	Code integrity, build behavior, generated files, and policy changes	Per-task approval for bounded paths; review the resulting diff	Log target paths, method, approval, result, and commit or diff reference	Writes are path-scoped, reversible, and separated from delete capability
Delete repository files	Deny	Irrecoverable source or configuration loss	Per-action human approval with exact targets	Log target list, approver, timestamp, result, and recovery reference	A recovery path exists and wildcard or root deletion is blocked
Outbound network access	Deny except approved destinations	Data exfiltration, SSRF, dependency substitution, and callback abuse	Owner approval for an allowlist; separate review for new destinations	Log destination, resolved address class, method, bytes category, and outcome	Private ranges, metadata services, redirects, and DNS rebinding are tested
Secret access	Deny; inject only the minimum runtime credential	Account takeover, lateral movement, and persistent credential disclosure	Security owner approval and per-use approval for high-impact credentials	Log secret identifier and use outcome, never the secret value	Managed storage, audience and scope restrictions, rotation, and revocation are tested
Production access	Deny	Customer impact, regulated data exposure, destructive changes, and outages	Per-action human approval by an authorized production owner	Log actor, approver, server version, action, target, change reference, and outcome	Staging validation, rollback, incident contact, and emergency disablement are proven

Authentication choices

OAuth, API key, and mTLS comparison

Option	Use when	Main risk	Launch gate
OAuth / MCP authorization flow	HTTP-based servers need user or client authorization with audience-bound access tokens and scopes.	Token passthrough, wrong audience, excessive scopes, confused-deputy behavior, and stale refresh paths.	Protected resource metadata exists, token audience is validated, scopes are minimal, and deny-path tests reject wrong-audience tokens.
API key or service token	A server wraps a backend service that already uses scoped service credentials or short-lived runtime tokens.	Long-lived secrets in prompts, logs, repo files, local config, screenshots, or broad environment injection.	The key is stored in managed secret storage, injected only at runtime, redacted from logs, scoped narrowly, and revocable by an owner.
mTLS or private network identity	A production or internal server needs strong service-to-service identity inside a controlled network boundary.	Certificate lifecycle drift, over-trusted network zones, unclear client identity, and missing emergency disablement.	Client identity is mapped to allowed methods, certificate rotation is documented, network allowlists are tested, and break-glass revocation works.

Starter files

MCP security review template

Use this structure to record server profile, threats, controls, permissions, validation, and sign-off.

MCP security review

Document one named server, its capabilities, launch gates, and evidence before production use.

# MCP security review

Verified: 2026-07-19

Use this template for one named server and deployment context.

## Server profile

- Server owner:
- Version / publisher:
- Distribution source:
- Deployment environment:
- Data classes:
- Methods / capabilities:
- Credentials / authentication:
- Network reach:
- Approval gates:
- Logging:
- Dependency / supply-chain review:
- Revocation / incident response:

## Authentication choice

| Option | Use when | Main risk | Launch gate |
| --- | --- | --- | --- |
| OAuth / MCP authorization flow | HTTP-based servers need user or client authorization with audience-bound tokens and scopes | Token passthrough, wrong audience, excessive scopes, and confused-deputy behavior | Protected resource metadata exists, token audience is validated, scopes are minimal, and deny-path tests reject wrong-audience tokens |
| API key or service token | A server wraps a backend service that already uses scoped service credentials | Long-lived secrets in prompts, logs, repo files, local config, screenshots, or broad environment injection | The key is in managed storage, injected only at runtime, redacted from logs, scoped narrowly, and revocable |
| mTLS or private network identity | A production or internal server needs strong service-to-service identity | Certificate lifecycle drift, over-trusted network zones, unclear client identity, and missing emergency disablement | Client identity maps to allowed methods, certificate rotation is documented, and break-glass revocation works |

## Threat model

- [ ] **Prompt injection** - Untrusted input can steer an agent toward a dangerous MCP call.
- [ ] **Excessive permissions or scope** - Broader scopes than the workflow needs increase blast radius.
- [ ] **Secret or token exposure** - Token passthrough, logs, or prompts can disclose credentials.
- [ ] **Unsafe writes or deletes** - A valid tool call can still overwrite code or mutate production state.
- [ ] **Network reach or SSRF** - URL retrieval can become a path to internal services.
- [ ] **Third-party supply chain or local server compromise** - A compromised local server runs with user privileges.

## Control checklist

- [ ] **Authentication and authorization** - Document token audience, scopes, and deny-path tests.
- [ ] **Least privilege** - Every enabled method, root, scope, and environment has a documented use case.
- [ ] **Secure secret and token storage with rotation** - Record storage, redaction, lifetime, and revocation.
- [ ] **Read and write separation** - A read-only profile works without write, delete, or production access.
- [ ] **Human approval for destructive or production actions** - Approval identifies actor, target, and rollback limits.
- [ ] **Attributable audit logs** - A reviewer can reconstruct a consequential call without exposing credentials.
- [ ] **Isolation and network allowlists** - The server cannot reach undeclared private or metadata endpoints.
- [ ] **Revocation and incident response** - Disablement and credential revocation are tested.

## Permission matrix

| Capability | Default | Data risk | Approval | Logging | Launch gate |
| --- | --- | --- | --- | --- | --- |
| Read repository files | Allow read-only access to declared roots | Source code and embedded sensitive data | Owner approval at onboarding | Log actor, method, root, and outcome | Roots are explicit and secret paths excluded |
| Write repository files | Deny until a bounded write workflow is approved | Code integrity and policy changes | Per-task approval for bounded paths | Log target paths, approval, and result | Writes are path-scoped and reversible |
| Delete repository files | Deny | Irrecoverable source or configuration loss | Per-action human approval with exact targets | Log target list, approver, and recovery reference | Wildcard or root deletion is blocked |
| Outbound network access | Deny except approved destinations | Data exfiltration and SSRF | Owner approval for an allowlist | Log destination, method, and outcome | Private ranges and metadata services are tested |
| Secret access | Deny; inject only the minimum runtime credential | Account takeover and credential disclosure | Security owner approval | Log secret identifier, never the value | Rotation and revocation are tested |
| Production access | Deny | Customer impact and destructive changes | Per-action approval by production owner | Log actor, approver, action, and outcome | Rollback and emergency disablement are proven |

## Validation workflow

- [ ] Run the MCP Inspector against the reviewed server and version.
- [ ] Enumerate resources, prompts, tools, notifications, and protocol exchanges.
- [ ] Exercise expected allow and deny cases for every enabled capability.
- [ ] Confirm errors and logs do not expose tokens or unnecessary sensitive payloads.
- [ ] Record evidence links and unresolved findings.

## Security config example

```yaml
# Example MCP server security profile

server:
  name: repo-inspector
  owner: platform-security
  transport: http
  default_capability: read-only

authorization:
  mode: oauth
  token_audience: https://mcp.example.com/repo-inspector
  required_scopes:
    - repo.read
  reject_token_passthrough: true

permissions:
  filesystem_roots:
    - /workspace/repo
  blocked_paths:
    - .env
    - secrets/
    - production/
  outbound_network_allowlist:
    - https://api.github.com
  write_methods: []
  destructive_methods: []

approvals:
  require_human_for:
    - secret_access
    - production_access
    - write_methods
    - delete_methods

audit:
  log_fields:
    - actor
    - session_id
    - server_version
    - method
    - target
    - approval_id
    - outcome
  redact:
    - tokens
    - secrets
    - file_contents

revocation:
  disable_server_command: platformctl mcp disable repo-inspector
  rotate_credentials_owner: platform-security
  incident_channel: "#security-incidents"
```

## Sign-off

- Reviewer:
- Review date:
- Sign-off:
- Findings or exceptions:

Cautions

Label KyenAI operational recommendations separately from official MCP requirements.
Complete every permission row before enabling write, delete, network, secret, or production access.

Download mcp-security-review.md

Configuration example

MCP security config example

Copy the shape, not the literal values. Replace commands, domains, scopes, paths, and owners.

Read-only MCP security profile

Show one conservative launch profile with token audience, blocked paths, network allowlist, approvals, audit fields, and revocation.

# Example MCP server security profile

server:
  name: repo-inspector
  owner: platform-security
  transport: http
  default_capability: read-only

authorization:
  mode: oauth
  token_audience: https://mcp.example.com/repo-inspector
  required_scopes:
    - repo.read
  reject_token_passthrough: true

permissions:
  filesystem_roots:
    - /workspace/repo
  blocked_paths:
    - .env
    - secrets/
    - production/
  outbound_network_allowlist:
    - https://api.github.com
  write_methods: []
  destructive_methods: []

approvals:
  require_human_for:
    - secret_access
    - production_access
    - write_methods
    - delete_methods

audit:
  log_fields:
    - actor
    - session_id
    - server_version
    - method
    - target
    - approval_id
    - outcome
  redact:
    - tokens
    - secrets
    - file_contents

revocation:
  disable_server_command: platformctl mcp disable repo-inspector
  rotate_credentials_owner: platform-security
  incident_channel: "#security-incidents"

Cautions

Do not copy example domains, commands, owners, or paths into production without review.
Keep write, delete, secret, and production capabilities disabled until a separate approval path exists.

Ongoing ownership

Review cadence and revocation

Review cadence: Review at least quarterly and whenever the server owner, publisher, version, dependencies, scopes, credentials, methods, data classes, network reach, or deployment environment materially changes.
Revocation and incident response: Disable the server, revoke tokens and secrets, remove client access, preserve attributable records, assess affected systems and data, rotate downstream credentials, and document the decision to restore or retire access.

Evidence reviewed

Audit MCP server security with 25 source-backed controls covering authentication, permissions, prompt injection, secrets, sandboxing, logging, revocation, and allow-or-deny tests. Evidence reviewed for this mcp security checklist and threat model: MCP security best practices; MCP authorization specification; MCP authorization security considerations. Decision scope: Answer how to secure an MCP server with source-backed protocol checks and clearly labeled operational controls. Product behavior after Jul 19, 2026 and any benchmark result not shown on this page remain unverified.

Best next step

Diagnose an MCP server that connects but exposes no tools. Prove configuration, transport, initialization, tools/list, client policy, and refresh behavior before widening permissions.

Methodology and disclosure

KyenAI writes this guide as an independent editorial reference, not as an endorsement page for any third-party tool. The comparison, checklist, or workflow advice is based on visible source material from MCP, plus the operational constraints named on the page. Product behavior, pricing, availability, and enterprise controls can change after the listed update date, so vendor-specific claims should be rechecked against the linked sources before procurement, migration, or production rollout.

Define the trust boundary

MCP server security spans the client, server, authorization server, credentials, data sources, local process privileges, network destinations, and the model context that can trigger tools. Inventory the exact server owner, publisher, version, distribution source, methods, filesystem roots, data classes, credentials, network reach, and deployment environment before deciding whether it can launch.

The threat model must cover prompt injection, excessive permissions or scope, secret or token exposure, unsafe writes or deletes, network reach or SSRF, and third-party supply chain or local server compromise. Prompt injection and destructive-action gating are broader AI agent tool security concerns; token audience validation, token passthrough, SSRF, and local server compromise are addressed directly in official MCP security material.

Apply official MCP authorization controls

For HTTP transports, follow the MCP authorization flow, publish protected resource metadata, validate access-token audience, reject tokens not issued for the MCP server, and avoid token passthrough. Request minimal initial scopes and elevate only when a specific method needs more access. Keep credentials in managed storage, out of prompts and ordinary logs, and document rotation and revocation.

Use the official MCP Inspector during validation to enumerate resources, prompts, tools, notifications, and protocol exchanges. Exercise both allowed and denied calls so the review covers behavior rather than configuration alone.

MCP tool permissions boundaries

Define MCP tool boundaries at the tool level, not only at the server level. Decide which tools are visible to the agent, which are callable, which are read-only, and which require explicit approval before write, delete, network, secret, or production access.

Use a policy matrix for read-only, write-limited, and admin tools. Map each enabled tool to a declared workflow, owner, and rollback path. Separate repository read, write, and delete capabilities instead of granting one broad server profile to every agent session.

When vendors use different vocabulary such as permissions boundaries, deny policies, or read-write tool use, translate them into the same review questions: who can invoke the tool, on what target, with what evidence, and under what stop condition.

Compare OAuth, API keys, and mTLS

Authentication is not one checkbox. Use OAuth or the MCP authorization flow when HTTP-based servers need audience-bound tokens and scopes. Use API keys or service tokens only when they are narrowly scoped, runtime-injected, redacted, and revocable. Use mTLS or private network identity when production service-to-service access needs strong client identity and certificate lifecycle control.

The included security config example starts from a conservative read-only profile: token audience validation, blocked secret paths, network allowlists, empty write and destructive method lists, human approval for high-impact access, redacted audit fields, and a named revocation command.

Add operational launch gates

Separate repository read, write, and delete capabilities. Deny outbound network, secret access, and production access by default until each destination and use case is reviewed. Require an informed human decision immediately before destructive or production-facing actions, and retain attributable records that identify the actor, session, server version, method, target, approval, and outcome without logging secrets.

These approval, audit-log, read/write separation, and review-cadence controls are KyenAI operational recommendations. They are not presented as normative MCP specification requirements. Teams can adopt stricter controls when data sensitivity, regulatory obligations, or production impact warrants them.

Recommended play

Inventory one named server and version, including owner, publisher, methods, data classes, credentials, network reach, dependencies, and deployment environment.
Validate official MCP authentication and authorization behavior, including token audience, scopes, deny paths, and token-passthrough protection.
Launch with the narrowest read-only profile, then review write, delete, network, secret, and production capabilities as separate permission decisions.
Use MCP Inspector to test expected allow and deny cases, record evidence, and prove that disablement and credential revocation work.

MCP security launch decisions

Distinguish protocol-specific requirements and guidance from general operating controls before approving an MCP server.

Area	Claim basis	Security decision	Launch gate
MCP authentication	Official MCP authorization specification and security guidance	Validate token audience, metadata, scopes, and deny paths; do not pass through unrelated tokens	Authorization tests prove accepted and rejected token behavior
MCP permissions	Official least-privilege guidance plus local capability policy	Request minimal scopes and review read, write, delete, network, secret, and production access separately	Every enabled scope and method maps to a declared workflow
Human approval	KyenAI operational recommendation	Require an informed decision immediately before destructive or production actions	The prompt identifies actor, target, action, environment, and rollback limits
Attributable logs	KyenAI operational recommendation	Record actor, session, server version, method, target, approval, timestamp, and outcome	A reviewer can reconstruct a consequential call without exposing secrets
Network isolation	Official SSRF guidance plus KyenAI deployment controls	Validate URLs and redirects; allowlist destinations and block private or metadata endpoints	SSRF, redirect, DNS, and undeclared-destination tests pass
Revocation	KyenAI operational recommendation informed by MCP token guidance	Disable the server, revoke credentials and client access, preserve records, and assess affected data	The owner proves emergency disablement and names incident contacts

Execution steps

Record the server profile

Name the owner, publisher, version, distribution source, methods, resources, prompts, data classes, credential source, network destinations, dependencies, and deployment environment.

Verify authentication and scopes

Test protected resource metadata, token audience, minimal scopes, rejected tokens, incremental elevation, and the absence of token passthrough for HTTP-based MCP authentication.

Complete the permission matrix

Decide repository read, write, delete, outbound network, secret access, and production access separately. Document each default, data risk, approval, logging expectation, and launch gate.

Validate with MCP Inspector

Enumerate exposed protocol features, exercise expected allow and deny cases, inspect errors and protocol exchanges, and retain evidence for the reviewed server version.

Prove revocation and incident response

Disable the server, revoke tokens and secrets, remove client access, identify retained records, and confirm who evaluates affected systems before production approval.

Common pitfalls

Calling every control an MCP requirement

Tie normative language only to official MCP evidence. Label human approval, attributable audit logs, read/write separation, and review cadence as KyenAI operational recommendations.

Granting one broad MCP permission bundle

Review repository read, write, delete, outbound network, secret access, and production access as independent capabilities with separate launch gates.

Testing only the happy path

Use MCP Inspector and direct authorization tests to prove denied scopes, invalid audiences, undeclared destinations, and disabled capabilities stay blocked.

Logging secrets in the name of auditability

Record identifiers and outcomes, not token values or unnecessary payloads. Test redaction before launch.

Implementation checklist

Record the server owner, publisher, version, distribution source, and deployment environment.
Classify methods, capabilities, data classes, credentials, network reach, and dependencies.
Validate MCP authentication, token audience, minimal scopes, and denied authorization paths.
Keep secrets and tokens out of prompts, source control, tool output, and ordinary logs.
Separate repository read, write, and delete permissions.
Deny outbound network, secret access, and production access until independently approved.
Require human approval for destructive or production actions as an operational control.
Retain attributable, secret-redacted audit records as an operational control.
Validate resources, prompts, tools, notifications, and allow or deny behavior with MCP Inspector.
Test server disablement, credential revocation, incident contacts, and restoration criteria.

Questions this guide answers

What are MCP tool permissions boundaries?

MCP tool boundaries should be defined at the tool level, not only at the server level: decide which tools are visible, which are callable, which are read-only, and which require explicit approval before write, delete, network, secret, or production access.

What should you review before launching an MCP server for coding agents?

Review authentication, token audience, scopes, read/write separation, secret isolation, network allowlists, audit logs, human approval for high-impact actions, and a tested revocation path before the agent can reach the server unattended.

Who should own MCP security review?

Engineering leaders, security reviewers, platform teams, and developer tooling owners who can inventory the server owner, methods, credentials, deployment environment, and rollback plan before rollout.

MCP Server Security Checklist: 25 Controls for AI Agents

Quick Answer

MCP security threat model

Prompt injection

Excessive permissions or scope

Secret or token exposure

Unsafe writes or deletes

Network reach or SSRF

Third-party supply chain or local server compromise

MCP server security checklist

MCP permission matrix

OAuth, API key, and mTLS comparison

MCP security review template

MCP security review

MCP security config example

Read-only MCP security profile

Review cadence and revocation

Evidence reviewed

Best next step

Methodology and disclosure

Define the trust boundary

Apply official MCP authorization controls

MCP tool permissions boundaries

Compare OAuth, API keys, and mTLS

Add operational launch gates

Recommended play

MCP security launch decisions

Execution steps

Record the server profile

Verify authentication and scopes

Complete the permission matrix

Validate with MCP Inspector

Prove revocation and incident response

Common pitfalls

Calling every control an MCP requirement

Granting one broad MCP permission bundle

Testing only the happy path

Logging secrets in the name of auditability

Implementation checklist

Questions this guide answers

What are MCP tool permissions boundaries?

What should you review before launching an MCP server for coding agents?

Who should own MCP security review?

Next guides

MCP tool discovery debugger

Claude Code hooks and MCP setup

repository instruction files

loop engineering for AI coding agents

Related evidence updates

Visual Studio Agent Mode Adds General Availability and MCP Support

GitHub Copilot Sandboxes Put Agent Execution Behind Policy Boundaries