Start with the integration that creates authority

Consider a customer-support agent connected to a ticketing system and a refund tool. A read-only knowledge connector and a tool that moves money need different test objectives. Inventory deployed MCP clients, servers, exposed tools, connected resources, transport types, and downstream services.

Useful buying triggers include a new connector, an enterprise customer enabling integrations, a server moving from local development into a shared environment, or a tool gaining write permission. Record which parts your team operates and which need third-party authorization for testing.

Map identity and authorization end to end

Document the user, tenant, client, server, and downstream service identity for each workflow. Identify where consent is recorded, tokens are issued or exchanged, scopes are requested, and permissions are enforced. An agent’s application login does not by itself explain the identity a tool uses downstream.

The official MCP security guidance addresses risks including confused-deputy behavior, token passthrough, session hijacking, and scope minimization. Use the guidance relevant to your deployed transport and authorization flow; document the version and assumptions.

Ask the assessor to validate whether one user or tenant can inherit another’s authority, whether consent reflects the requested action, and whether a downstream service applies the intended authorization. Avoid treating a successful connection as proof that delegation is correct.

Test tool and data boundaries together

  • Tool permissions: compare declared capability, requested scope, and actual permitted actions.
  • Untrusted context: assess how documents, tool descriptions, and tool responses influence tool selection and arguments.
  • Action approval: validate that sensitive actions remain bound to the approved identity, object, and parameters.
  • Sessions and tenants: check isolation for connection state, cached results, credentials, and replayed requests.
  • Downstream handling: review how generated arguments and returned data are validated before use.
  • Connection destinations: include relevant outbound-request and local-server risks where those paths exist in the agreed architecture.

The result should describe concrete boundary failures and their preconditions. A list of installed MCP servers or an automated protocol check is only one input to this assessment.

Prepare test access without using live customer data

Provide a diagram, a tool inventory, test tenants, role-specific accounts, and synthetic records with known ownership. Include both an allowed and a denied action for important tools. Document service identities, audit events, approval screens, and any asynchronous execution.

Agree the permitted environment, rate and action limits, stop conditions, evidence storage, and escalation route. High-impact tools should use controlled resources or an agreed simulation. The DevBrows methodology explains engagement and reporting expectations.

Commission evidence, remediation, and a retest

Request a report that identifies the tested client/server versions, configurations, authorization flow, tools, and excluded integrations. Each validated finding should show the identity and starting state, the unauthorized outcome, reproduction limits, and a control-focused recommendation.

Reserve engineering time for changes and one scoped retest. Rechecking a fixed boundary may need both a permitted workflow and a prohibited workflow; a fix that blocks all tool use is not a useful production result.

Choose a one-time assessment or an annual plan

MCP is scoped within the AI Application & Agent Security Assessment , with a starting engagement range of $12K–$20K USD depending on the complete AI surface. It is not a blanket price for every connector or server. Specify workflows, tools, identities, environments, and tenant models in the proposal.

If tools, permissions, and servers change frequently, define review triggers through Continuous AI Assurance . A new server, broader scope, changed authorization flow, or newly privileged tool can require review before the next scheduled test.