Map the client, server, transport, and authority
Model Context Protocol connects clients with servers that expose capabilities such as tools and resources. Start by identifying where each component runs, which user it represents, what data it can read, and which actions it can perform. Record whether the integration uses a local process or a remotely hosted service.
Do not assume that every MCP connection has the same authentication model. The protocol’s authorization specification describes HTTP-based authorization; local standard-input/output integrations typically obtain credentials through their environment instead. Review the transport and implementation version you actually use. The primary references below are the 28 July 2026 specification and security guidance.
Enforce tool and record permissions outside the model
A tool name and description help a model choose an operation; they do not authorize it. Trusted server code should identify the user, validate the requested action and parameters, and enforce access to the particular record or tenant. A client-supplied workspace identifier is not evidence of membership.
Expose the narrow capability a task needs. A read-only document lookup does not need a general command runner or a credential with administrative access. Separate read and write operations, apply payload and cost limits, and determine which actions require the user to review the actual destination or change. Permission checks must still run when a request originates from an AI assistant.
| Operation | Allowed test | Required denied test |
|---|---|---|
| Read a document | A test member reads its own workspace record | A different workspace cannot retrieve that record |
| Create an outbound message | The approved recipient and content are used | A retrieved document cannot silently replace the recipient |
| Run an expensive job | An authorized account starts a bounded job | Repeated or oversized requests are rejected safely |
Validate token audience and avoid token passthrough
For the HTTP authorization flow, the MCP authorization specification requires servers to validate that access tokens are intended for their own resources. A valid token issued for some other service is not sufficient. Apply the relevant issuer, audience, expiry, and resource checks required by the authorization server and protocol implementation.
Do not simply accept a client’s token and forward it to an unrelated upstream API. The MCP security guidance prohibits token passthrough because it undermines the separation between the MCP server and downstream services. If an integration acts as a proxy, design the upstream authorization and user consent explicitly rather than treating every connected service as one trust domain.
Review consent and redirect handling when a proxy connects to third-party services. The confused-deputy scenario in the official guidance shows why an existing upstream session is not sufficient proof that a newly connected client has the user’s intended authority. Protect state and redirect validation in the actual authorization flow.
Treat local MCP servers as installed software
A local MCP server can inherit the permissions of the process that launches it. Review the package source, installation command, executable, updates, and environment variables before enabling it. A short configuration snippet may execute code with access to local files or credentials.
Provide only the directories and credentials required by the task. Separate development and production secrets, avoid printing them in tool output, and review the consequences of adding a shell or filesystem capability. An instruction in a remote document must not be able to expand a local server’s permissions.
Keep retrieved instructions and network destinations untrusted
A document, page, tool response, or tool description may contain instructions that try to redirect an assistant. Keep external content separate from trusted application policy, but do not rely on prompt wording alone. Resource permissions, destination checks, and action approval need enforcement outside the model.
Review URL-fetching and authorization-discovery paths for server-side request forgery. Validate the parsed destination and resolved addresses, control redirects, and restrict access to internal or metadata services according to the network architecture. A URL that looks public in a prompt does not establish that its eventual destination is safe.
Verify an integration with synthetic records
Use an environment you own or are explicitly authorized to assess. Prepare two test identities with different tenant permissions and harmless records. Confirm that legitimate calls succeed, cross-tenant calls fail without side effects, and revoked or expired access is rejected. Do not enumerate real customer data to demonstrate a permission failure.
Check a benign instruction attempt in retrieved content and inspect both the assistant response and the tool-execution outcome. A reassuring sentence does not prove that no action occurred. Conversely, a rejected unauthorized tool call shows an enforcement boundary working even if the model requested the wrong operation.
Record sanitized evidence, the expected permission rule, implementation version, and retest result. Review again when a new tool, server, data source, or privilege is introduced. This worksheet is an integration review aid, not a certification of protocol compliance or complete vulnerability coverage.
WarHoundAI’s planned MCP integration
MCP is one of the planned integration modes for BloodHound by WarHoundAI. The integration and security assessments remain in development. This guide does not publish a working WarHoundAI server URL, installation command, supported-client list, or a claim that BloodHound currently audits MCP implementations.
Primary protocol references
Consult the specification and security guidance for the version you implement. These references are linked to the reviewed version so readers can distinguish protocol requirements from the illustrative application-review examples above.