MCP security: seven questions before connecting an AI agent

Draw the connection before approving it

List the assistant, MCP client, server, downstream API and account used at each boundary. Mark where tokens, retrieved content and action logs travel. A connection described as ‘read-only’ in a demo can still use a service account with broader permissions underneath.

For a local server, review the executable, installation source, update path and access to local files or environment variables. For a remote server, review hosting, authentication, tenant isolation and the operator’s incident contact. These are different deployment questions; do not apply an HTTP OAuth checklist blindly to every local process.

Check tokens and tool authority separately

The MCP specification’s HTTP authorisation guidance requires tokens intended for the receiving server and prohibits passing the client’s token straight through to another API. Confirm the protocol version your implementation follows. [1]

Authentication does not answer whether a particular action is appropriate. OWASP’s excessive-agency guidance supports limiting available functions and privileges and independently approving high-impact actions. [2] Our practical recommendation is to request the smallest tool set that completes the actual workflow, then test denied actions as well as successful ones.

Use these seven questions in the supplier meeting

Ask for evidence from your proposed configuration, not a generic security slide. Record an owner and follow-up date for each unanswered question. A missing answer is a reason to narrow the pilot until the uncertainty is resolved; it is not, by itself, proof that a supplier has been compromised.

A connection register you can use

Run a bounded pilot before expanding access

Our illustrative pilot uses a separate test workspace, synthetic documents and one harmless write operation. Establish a successful authorised request, then check an unauthorised account, a revoked permission and an attempt to reach a resource outside scope. Keep testing within written permission and agreed limits.

Record the requested action, effective identity, approval result and downstream outcome without copying secrets into logs. Practise disabling the connection and confirm that new requests are denied. Cached data and already-issued downstream sessions may need separate cleanup. Define what must be retested when tools, server versions or access scopes change.

Seven questions before approval

1. Who operates and updates this MCP server?
2. Which identity reaches the downstream system?
3. Which records can it read, change, delete or export?
4. How are token audience, storage and expiry handled?
5. Where are consequential actions approved outside model judgement?
6. What evidence is logged, and who can inspect it?
7. How do we revoke access and verify that revocation worked?

Questions buyers ask

Keep exploring

• AI security assessment or penetration test: what should you buy?
• AI-generated code: a security review before you ship