MCP Security for AI Agents: What to Test Before You Connect Tools

MCP host, client, and server roles, tool exposure risks, transport security, least privilege, prompt injection via tool outputs, Agnostics testing for tool-using agents, and Release Gate before production connections.

Model Context Protocol connects agents to tools through hosts, clients, and servers. That wiring adds trust boundaries, transport risks, and injection via tool outputs. Test tool-using targets with Agnostics attack packs and read Release Gate before you connect production MCP servers.

What MCP is: host, client, and server

Model Context Protocol standardizes how AI applications discover and call tools. Three roles matter for security testing.

The host is the application that runs the agent experience: your product shell, session handling, and policy enforcement.

The client inside the host negotiates capabilities with MCP servers and routes tool calls the model requests.

The server exposes tools, resources, and prompts to the client. Each server is a trust boundary. Treat it like an API you did not write unless you did.

How traffic flows between host, client, and server

The model proposes tool use. The client validates and forwards requests to the correct server. Results return as structured content the model reads on the next turn.

That loop means untrusted tool output becomes trusted context unless you sanitize and scope it.

Multiple servers compound risk. One read-only docs server and one write-capable ops server in the same session require separate permission stories.

Tool exposure risks when MCP servers go live

Overbroad tool catalogs let models pick destructive actions for benign-sounding user requests.

Servers that reuse admin credentials for every session turn least privilege into theater.

Resource endpoints may leak files, tickets, or configs the user should never see through the agent UI.

Third-party MCP servers inherit supply chain risk. You are trusting their code, updates, and logging behavior.

• Destructive or high-cost tools reachable from standard sessions
• Shared credentials across users or environments
• Resource reads that bypass normal app authorization
• Unreviewed third-party server updates

Transport security and session integrity

MCP deployments vary by transport: local processes, remote HTTP, or hosted bridges. Each has different eavesdropping and impersonation risks.

Use TLS for remote servers. Pin authentication between client and server where the protocol allows.

Rotate tokens and scope them to sessions. Long-lived secrets on the client device become theft targets.

Log transport failures separately from tool failures. Silent downgrade to insecure channels is a launch blocker.

If you would not expose an HTTP API with the same powers as your MCP server, do not connect that server through the agent first.

Least privilege for MCP servers and scopes

Split servers by sensitivity. Billing writes and document reads should not share one credential soup.

Expose the minimum tool set for each agent role. Remove experimental tools from customer-facing hosts.

Require human approval for irreversible MCP actions even when the model insists urgency.

Review server manifests on every deploy. New tools often arrive quietly in dependency updates.

• Map each MCP tool to data stores and side effects
• Assign credentials per role and environment
• Remove unused tools from production hosts
• Add confirmation gates for irreversible actions

Prompt injection through tool outputs

MCP servers return text the model treats as ground truth on the next turn. Hostile content in a ticket, webpage, or file can instruct the agent to ignore policy.

This is indirect prompt injection with extra steps. The user never typed the attack. The tool fetched it.

Sanitize outputs where possible. Separate user-visible summaries from raw tool payloads the model consumes.

Test with prompt injection and unsafe tool actions packs on targets that include MCP-backed tools.

Testing MCP-connected agents with Agnostics

Configure a staging target that mirrors your MCP wiring: same servers, same tool allowlists, same auth, same confirmation rules.

Run unsafe-tool-actions to pressure high-impact calls. Run permission-abuse for fake roles and scope expansion. Run prompt-injection when tools return external content.

Read findings with tool invocation evidence and model reasoning, not only the final user-visible message.

API-only agents without chat UI still qualify. If MCP tools sit behind an endpoint, configure the target to hit that path.

Release Gate before you connect production MCP servers

Findings on unauthorized tool use or injection via MCP outputs should map to Fix or Blocked under most launch policies.

Ready means this target with these servers met your bar for the workflows you plan to expose.

Monitor documents accepted gaps when stakeholders agree to ship with known limitations and a retest date.

Export release reports when security or platform teams need evidence before enabling new servers in production hosts.

Checklist before enabling a new MCP server

Document owner, data classes touched, and rollback plan for the server.

Verify transport auth and TLS for remote connections.

Confirm tool allowlists match the agent role, not the developer laptop.

Run Agnostics scans on staging with the server enabled. Retest after server version bumps.

• Owner and data classification documented
• Transport and token scoping verified
• Tool allowlist matches least privilege
• Staging scan clean or findings triaged with retest scheduled

Honest limits of pre-launch MCP testing

Scans pressure your configured target. They do not audit every line of third-party server code.

Novel server bugs and zero-day issues in dependencies remain possible after a Ready gate.

Production traffic will combine tools in ways staging did not simulate. Treat incidents as new test cases.

MCP is moving quickly. Recon and rescans belong in your release rhythm, not only launch week.

A Ready Release Gate means this scan met your policy for this target at this time. It is not a certificate for every future MCP server you add.

What Agnostics does not claim

Agnostics does not replace MCP server code review, dependency pinning, or vendor due diligence.

Agnostics does not guarantee MCP sessions cannot be abused after launch.

Sample Demo Data demonstrates findings on tool-using targets without connecting to your MCP credentials in demo mode.

Questions

What is MCP in plain language for security teams?

Model Context Protocol is a standard way for AI hosts to connect agents to external tools and resources through clients and servers. Each server is a new trust boundary with tool and data exposure.

What are the biggest MCP security risks?

Overbroad tools, shared admin credentials, insecure transport, third-party server supply chain risk, and indirect prompt injection through tool outputs that become model context.

How do you test MCP-connected agents before launch?

Configure a staging target that mirrors production MCP wiring and run Agnostics attack packs such as unsafe-tool-actions, permission-abuse, and prompt-injection. Review findings with tool evidence and read Release Gate against your policy.

Can prompt injection happen through MCP tool results?

Yes. Hostile text in fetched tickets, files, or web content can instruct the agent on the next turn. Treat tool outputs as untrusted input unless sanitized.

What MCP findings should block launch?

Repeatable critical unauthorized tool use, data export, or injection paths on launch-critical workflows, according to your release policy.

Does Agnostics scan MCP server source code?

No. Agnostics pressure-tests runtime behavior on your configured target. Pair scans with server review, least privilege, and dependency management.

When should we retest after MCP changes?

After adding or upgrading servers, changing tool allowlists, rotating credentials, or altering confirmation flows. Retest with the same attack coverage.