MCP Security Checklist for AI Agents

MCP makes AI agents more useful because it gives them a standard way to reach real tools, data, and workflows.

That is exactly why MCP security matters.

An agent that can only answer from a prompt can still be wrong. An agent connected to MCP servers can read files, query databases, inspect repositories, call APIs, trigger workflows, and sometimes execute commands. The security question is no longer only "did the model say the right thing?" It becomes "what can this model cause the system to do?"

This checklist is for teams connecting AI clients to MCP servers, especially developer tools, internal APIs, SaaS systems, CI/CD workflows, repositories, and local machines.

Executive Summary

The safest MCP setup is boring in the best way:

• every MCP server is inventoried
• every tool has a narrow contract
• secrets are never hardcoded into config files
• local servers are treated as privileged software
• OAuth scopes are minimal and reviewed
• risky actions require confirmation
• filesystem, shell, and network access are constrained
• tool calls are logged with raw arguments and results
• credentials can be rotated quickly
• shadow MCP servers are found and removed

MCP is not dangerous because it is new. It is risky because it makes integration easier, and easy integrations tend to multiply faster than governance.

Anthropic introduced MCP in 2024 as an open standard for connecting AI assistants to the systems where data lives, including repositories, business tools, and development environments. The official MCP architecture overview describes a host, client, and server model where an AI application can connect to one or more MCP servers. Those servers can run locally or remotely.

That architecture is powerful. It also creates a capability surface that needs normal software security controls, plus agent-specific controls.

Why MCP security became urgent

AI agents are moving from demos into daily developer workflows. At the same time, credential sprawl is getting worse.

GitGuardian's State of Secrets Sprawl 2026 reported 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% year-over-year increase. The same report said AI service secrets reached 1,275,105, up 81% year over year.

The MCP-specific finding is even more direct: GitGuardian identified 24,008 unique secrets in MCP-related configuration files across public GitHub, including 2,117 valid credentials.

That is the pattern to avoid.

MCP setup examples often feel small: add a config file, paste an API key, point the client at a local command, and start working. But every convenience choice becomes part of the security model.

If a config file contains a production token, it is now a secret artifact.

If a local MCP server can read the repository and execute shell commands, it is now a privileged local program.

If a remote MCP server can call a SaaS API with broad scopes, it is now an integration account that needs owner, expiry, monitoring, and rotation.

The MCP threat model in plain language

MCP security is easier when you separate the parts.

The MCP tools specification says tools can be invoked by language models and that implementations should keep a human in the loop for trust, safety, and security. It also recommends UI that shows which tools are exposed, indicates when tools are invoked, and presents confirmation prompts for operations.

That is the right default stance: visible capability, explicit action, and review for risky operations.

Checklist 1: inventory every MCP server

Start with a written inventory.

For each server, record:

• server name
• owner
• purpose
• host applications allowed to use it
• local or remote transport
• credentials it can access
• tools exposed
• resources exposed
• write capabilities
• approval requirements
• logging destination
• last review date

This sounds administrative, but it prevents shadow MCP.

OWASP's MCP Top 10 calls out shadow MCP servers as unapproved or unsupervised MCP deployments outside formal governance. That is a realistic risk because developers can spin up local servers quickly while experimenting.

The rule is simple: if an MCP server can reach company data, repositories, customer systems, cloud accounts, or credentials, it belongs in the inventory.

Checklist 2: classify tools by blast radius

Do not treat all tools equally.

Classify every tool before enabling it:

The dangerous tools are not always the dramatic ones. A "read file" tool can leak secrets. A "search tickets" tool can expose customer data. A "post summary" tool can send private context into the wrong channel.

Start read-only. Add write access only after the read path is stable, logged, and understood.

Checklist 3: keep secrets out of MCP configs

An MCP config file is not a secret store.

Avoid putting secrets in:

• MCP JSON config files
• command-line arguments
• example snippets
• README setup blocks
• shared chat logs
• issue comments
• repository-level defaults
• local scripts committed to source control

Prefer:

• environment variables injected by a trusted runtime
• an operating-system credential manager
• a cloud secret manager
• short-lived OAuth tokens
• scoped service accounts
• development-only credentials with low privileges
• separate credentials for dev, staging, and production

The goal is not only to hide the value. It is to make ownership, rotation, and revocation possible.

A secure MCP config should identify how to obtain a credential, not contain the credential itself.

For local development, this pattern is safer:

{
  "mcpServers": {
    "example-api": {
      "command": "node",
      "args": ["./dist/server.js"],
      "env": {
        "EXAMPLE_API_TOKEN": "${EXAMPLE_API_TOKEN}"
      }
    }
  }
}

And this pattern should be avoided:

{
  "mcpServers": {
    "example-api": {
      "command": "node",
      "args": ["./dist/server.js", "--token", "prod_live_secret_value"]
    }
  }
}

The second version turns a tool setup file into a credential leak.

Checklist 4: treat local MCP servers as privileged software

Local does not mean low risk.

Local MCP servers often run near:

• source code
• Git remotes
• SSH keys
• cloud credentials
• package manager tokens
• environment variables
• browser profiles
• local databases
• shell history
• CI/CD config

That is why local MCP servers should be reviewed like developer tooling, not like harmless plugins.

For each local server, ask:

• Which directories can it read?
• Can it write files?
• Can it execute commands?
• Can it access environment variables?
• Can it reach the network?
• Does it run with the user's full OS permissions?
• Does it log sensitive tool inputs or outputs?
• Can a malicious prompt cause it to use a risky tool?

If the server only needs one project directory, do not give it the whole home directory. If it only needs read access, do not expose write tools. If it only needs to inspect logs, do not let it run shell commands.

Checklist 5: use least privilege for OAuth and API scopes

The latest MCP authorization specification is built around OAuth patterns for HTTP-based transports and explicitly discusses least-privilege scope selection.

The practical rule is simple: request the smallest scope needed for the current operation.

Bad scope design:

• one token can read and write everything
• all users share the same service account
• staging and production use the same credential
• scopes never expire
• there is no owner for the token

Better scope design:

• separate read and write scopes
• separate user-facing and automation scopes
• separate dev, staging, and production credentials
• short-lived tokens where possible
• owner and rotation date for each secret
• step-up authorization for sensitive actions

For example, a repository MCP server might expose:

• repo:read_files
• repo:search
• repo:read_pull_requests
• repo:create_branch
• repo:write_files
• repo:open_pull_request

Do not grant repo:write_files just because the agent sometimes needs repo:search.

Checklist 6: require approval for side effects

Approval prompts should show the actual action, not only the agent's summary.

A weak approval prompt says:

The agent wants to update the issue.

A stronger approval prompt says:

Tool: jira.update_issue
Issue: PAY-1842
Fields:
  status: Done
  assignee: nikesh
  comment: "Marked complete based on deployment log..."

For email, chat, CRM, billing, deployments, file writes, and repository changes, the user should see:

• tool name
• target system
• exact record or path
• raw arguments
• requested permission
• expected side effect
• whether the action can be undone

Approval is not a magic shield, but it breaks many failure paths where the model misreads context, follows injected instructions, or chooses a tool too eagerly.

Checklist 7: validate tool inputs and outputs

Every MCP tool should have a strict schema, but schema alone is not enough.

Validate:

• required fields
• allowed enum values
• maximum string lengths
• path boundaries
• URL allowlists
• ID formats
• query limits
• pagination limits
• forbidden commands
• sensitive output fields

For file tools, validate paths with resolved absolute paths and an allowlisted workspace root.

For HTTP tools, validate destination hosts and block internal metadata endpoints unless explicitly required.

For database tools, use parameterized queries, read-only accounts where possible, and row limits.

For shell tools, avoid generic command execution. If a tool must run commands, expose narrow commands with fixed arguments rather than a free-form shell.

The best MCP tools are boringly specific.

Bad:

run_command(command: string)

Better:

run_unit_tests(packageName: string)

Best:

run_unit_tests(packageName: ApprovedPackage, testFilter?: SafeTestFilter)

Checklist 8: defend against prompt and context injection

MCP servers often bring outside content into an agent workflow. That content can include docs, tickets, web pages, repository text, emails, logs, issue comments, and tool output.

Any of those can contain malicious instructions.

OWASP's LLM application work identifies prompt injection and excessive agency as core LLM risks. OWASP's MCP Top 10 also calls out context injection and intent flow subversion.

The practical defense is layered:

• label retrieved content as untrusted data
• separate instructions from retrieved text
• strip or flag instruction-like content from tool outputs
• avoid giving untrusted content direct access to tool decisions
• require approval for side effects triggered after retrieval
• keep memory scoped to the user, task, and system
• log which context influenced a tool call

Do not assume a prompt can permanently tell the model to ignore malicious instructions. Treat prompt injection as something to reduce, detect, and contain.

Checklist 9: secure remote MCP servers like APIs

Remote MCP servers need normal API security.

At minimum:

• TLS everywhere
• authenticated access
• authorization on every request
• tenant isolation
• exact redirect URI validation for OAuth flows
• CSRF protection where browser flows are involved
• rate limits
• request size limits
• audit logs
• secret redaction
• dependency monitoring
• incident response ownership

The MCP security best-practices documentation discusses confused deputy risks in proxy-style authorization flows and recommends per-client consent, clear consent UI, redirect URI validation, and state parameter validation.

That matters because MCP servers may sit between an AI client and a third-party API. If the proxy authorizes the wrong client or sends tokens to the wrong redirect URI, an attacker can turn a helpful integration into a credential theft path.

Checklist 10: log raw tool calls

You cannot secure what you cannot reconstruct.

For every meaningful tool call, log:

• timestamp
• user identity
• host application
• MCP client
• MCP server
• tool name
• raw arguments after redaction
• approval decision
• result status
• affected object ID
• error details
• correlation ID or trace ID

Do not log full secrets, access tokens, private keys, or large sensitive payloads. But do log enough to answer:

• What happened?
• Who initiated it?
• Which model or host requested it?
• Which tool executed?
• What did it change?
• Was the user shown the real action?

OWASP's MCP Top 10 calls out lack of audit and telemetry as a risk because weak logging makes investigation and incident response harder.

For production systems, logging is not optional. It is part of the permission model.

Checklist 11: build a permission review cadence

MCP permissions decay over time.

A server starts with read-only access, then gets write access for one feature, then inherits an extra scope for a demo, then someone adds a local shell helper, then the original owner moves teams.

That is how scope creep happens.

Run a lightweight review every month for active MCP servers:

• Are all servers still needed?
• Are all tools still used?
• Are any write tools unused?
• Do any tokens have broader scopes than necessary?
• Are local path allowlists still correct?
• Are old credentials still valid?
• Are any servers missing owners?
• Are logs capturing raw tool calls?
• Are users approving actual actions or agent summaries?

Kill unused servers quickly. Remove unused tools. Rotate old credentials. Shrink scopes before they become incident material.

A practical MCP rollout plan

If you are introducing MCP into a team, do not start with a fully autonomous agent that can do everything.

Use a staged rollout:

Stage 1: read-only exploration

Expose one or two read-only tools:

• search documentation
• list repository files
• fetch ticket metadata
• inspect API schemas

Log every call. No writes. No shell execution.

Stage 2: narrow internal actions

Add low-risk write tools:

• create draft ticket
• create draft pull request
• prepare a report
• generate a config file in a sandboxed folder

Require approval before the write.

Stage 3: controlled operational tools

Add higher-value actions:

• update ticket status
• run tests
• create a branch
• call a staging API
• trigger a non-production job

Use tighter scopes, approval prompts, and alerts.

Stage 4: production access

Only add production actions when the team already has:

• mature logging
• rollback paths
• owner approval
• incident playbooks
• secret rotation
• permission review
• tested prompt-injection defenses

Production access should be earned, not assumed.

Common MCP security mistakes

Mistake 1: hardcoding API keys in config

This is the easiest mistake to make and one of the easiest to avoid. Keep secrets out of config files, command arguments, docs, and examples.

Mistake 2: giving one server too many jobs

One giant MCP server with every tool is hard to reason about. Prefer smaller capability surfaces: repository tools, docs tools, ticket tools, analytics tools, and deployment tools can be separated.

Mistake 3: trusting local servers by default

Local servers can reach local secrets. Review them like privileged developer tools.

Mistake 4: hiding raw actions behind friendly summaries

Approval prompts should show the raw operation. The agent's natural-language summary is not enough.

Mistake 5: skipping logs until after the first incident

If you wait for an incident to add logs, the first incident will be much harder to understand.

Mistake 6: treating MCP as only an AI engineering decision

MCP is also an identity, secrets, API, and developer-workstation security decision.

MCP security checklist

Before enabling an MCP server for a real team, confirm:

• The server has an owner.
• The server is in an inventory.
• The server purpose is clear.
• All tools are documented.
• All resources are documented.
• Secrets are not stored in config files.
• Credentials are scoped and rotatable.
• Development and production credentials are separate.
• Local filesystem access is restricted.
• Shell execution is disabled or narrowly constrained.
• Remote HTTP access is authenticated and authorized.
• OAuth scopes follow least privilege.
• Risky side effects require approval.
• Approval prompts show the raw tool call.
• Tool inputs are schema-validated and policy-validated.
• Tool outputs are redacted where needed.
• Prompt and context injection risks are documented.
• Tool calls are logged with correlation IDs.
• Logs redact secrets.
• Tokens can be revoked quickly.
• Permission reviews happen on a schedule.
• Shadow MCP servers are actively searched for.

That is the baseline. Teams with customer data, regulated data, production deployment access, or financial actions should add stronger controls.

FAQ

What is the biggest MCP security risk?

The biggest practical risk is over-capability: too many tools, too much local access, broad credentials, and weak approval flows. MCP makes integration easy, so the security model has to keep up with the speed of integration.

Are local MCP servers safer than remote MCP servers?

Not automatically. A local MCP server may avoid some remote network exposure, but it often runs near sensitive files, environment variables, source code, cloud credentials, SSH keys, and package tokens. Treat local MCP servers as privileged software.

Should MCP tools require human approval?

Risky tools should. Read-only tools may be safe to auto-run after review, but tools that write files, modify systems, send messages, deploy code, access sensitive records, or spend money should require explicit approval.

Where should MCP secrets be stored?

Use environment variables from a trusted runtime, operating-system credential managers, cloud secret stores, OAuth tokens with narrow scopes, or short-lived credentials. Avoid MCP config files, command-line arguments, README snippets, shared tickets, and chat logs.

How should teams start with MCP securely?

Start with one or two read-only tools, a named owner, narrow credentials, raw tool-call logging, and a review date. Add write tools only when approval prompts, scopes, logs, and rollback paths are ready.

References

• Anthropic: Introducing the Model Context Protocol
• Model Context Protocol: Architecture overview
• Model Context Protocol: Tools
• Model Context Protocol: Authorization
• Model Context Protocol: Security best practices
• OWASP MCP Top 10
• OWASP Top 10 for Large Language Model Applications
• GitGuardian: The State of Secrets Sprawl 2026