MCP security and governance defines which servers an AI application may use, what information and authority each interaction may carry, and how tool operations are authorized and verified across the host, client, server, and destination.
This operational definition connects protocol choices to the enterprise resources behind a tool. The guide uses the MCP specification revision of July 28, 2026. Implementations may use other revisions; establish the version and behavior of the components under review before applying a protocol requirement. AI agent security supplies the broader threat model.
What MCP changes
MCP provides a common interface through which an AI application can obtain context and use capabilities exposed by servers. In the cited architecture, the host manages clients, consent, and context; each client interacts with one server. A server can be a local process or a remote service. This revision is stateless: requests carry protocol and capability information, and servers advertise capabilities through server/discover. A business workflow can still maintain state outside those protocol exchanges. MCP architecture, 2026-07-28.
Consider a hypothetical task: retrieve an equipment inventory record for one permitted site. The application selects asset_lookup, exposed by a configured remote MCP server. That server queries an inventory API using a credential that can access several sites. These are invented conditions for examining a design, not a real integration, incident, or executed test.
The requested site, selected tool, configured server, and downstream credential describe different relationships. A broader credential does not prove that an unauthorized record was retrieved. It does require an explanation of where the permitted site is enforced.
| Relationship in the example | Question to resolve | What the answer does not establish |
|---|---|---|
| Application to configured server | Which endpoint and operator are approved for this task? | What every operation implemented there will do |
| Selected tool to server | Which server receives this asset_lookup request? | That another tool with the same name is equivalent |
| Client to protected MCP service | Which identity and access conditions admit the request? | Permission to retrieve every downstream inventory record |
| Server to inventory API | Which credential acts, and where is the permitted site checked? | That the requested lookup actually occurred |
| Tool response to application | Which source produced the returned record, and how will it be used? | Authority to expand the task or query another site |
The table is a review map for this example. The agent governance architecture guide explains the broader component boundaries; this guide examines the MCP relationships inside them.
Establish server trust before enabling access
For the remote inventory server, identify the operator, endpoint, supported use, and person responsible for changes. Review how it obtains downstream access and who can modify its implementation or configuration. An encrypted connection to the intended endpoint does not establish that the service's behavior meets the organization's requirements.
A local server introduces a different execution boundary. Review the executable or package being started, its arguments, source, update process, and effective access to files, network, and credentials. MCP's security guidance recommends restricting local server privileges and addresses consent before one-click configuration executes commands. STDIO communication does not itself create process isolation. MCP security best practices, local server compromise.
Assign change review to the person who can act on the changed component. Replacing an endpoint requires reviewing the new service; changing a local startup command requires reviewing the new execution. A previously approved display label should not silently carry those approvals forward. The mechanism for holding or reapproving a change depends on the actual host and deployment controls.
Distinguish tool discovery from permission to use it
MCP tools describe a name, an optional display title, a description, an input schema, an optional output schema, and annotations. Schemas describe expected structure; annotations provide behavioral hints. Clients must treat annotations as untrusted unless the server is trusted. Tool names have server scope, so aggregated tools can collide; serverInfo.name is not guaranteed globally unique either. MCP tools, 2026-07-28.
For asset_lookup, the application needs an unambiguous association with the server selected for the inventory task. An operator reviewing a permission or event should be able to resolve that association without relying on the visible tool name alone. A claim that the tool only reads records still needs implementation and permission evidence relevant to the actual server.
Keep the reviewed interface connected to the installed configuration. If a tool gains a new argument that selects a different data source, the previous review may no longer answer where information can go. A schema-compatible change can also alter behavior behind the interface. Determine which changes require renewed assessment and how the owner learns about them; discovery is an input to that process, not its approval outcome.
Separate MCP access from downstream tool permissions
The cited authorization specification defines an optional HTTP authorization framework. HTTP implementations supporting authorization should follow it; STDIO implementations should not use that flow and instead obtain credentials from the environment. Do not apply the HTTP OAuth design to every MCP connection. MCP authorization, applicability.
For the protected HTTP flow, an MCP server must validate that the access token was issued for it. When accessing an upstream API as an OAuth client, it uses a separate token for that service rather than passing through the token received from the MCP client. These restrictions keep token audiences and access relationships distinct. MCP authorization security considerations.
That separation still leaves a business decision in the inventory example. Does the downstream operation run under the requester's identity, a delegated identity, or a service identity? If the service credential reaches several sites, where does the server or destination verify that this request may retrieve this record? The task's site restriction needs a control connected to the operation; text in the agent's instructions does not narrow the credential.
MCP's Tools specification requires server input validation and access controls. A deployment review must establish how those controls apply to its resources. Valid syntax for a site identifier does not make that site authorized, and permission to invoke asset_lookup does not answer which records it may return. Tools requirements.
Trace context and data exposure in both directions
Separate the information sent to the server from what it retrieves and what the application subsequently consumes. In the example, the outbound arguments might contain a site identifier and equipment reference. The returned record might contain fields that the task does not need. Review the actual fields and recipients rather than assuming that a small prompt produces a small disclosure.
The application owner should determine what context the server needs to perform the lookup. The inventory owner should determine which records and fields may be returned for this purpose. The owner of the receiving application should establish whether the response can enter model context, be retained, or be shared onward. These decisions concern separate copies and processing steps.
A remote server does not inherit the filesystem or network restrictions placed on a local agent process. Review its own runtime and downstream permissions. Restricting the agent's local workspace cannot establish that the inventory service is limited to the same resources.
Keep returned content from becoming delegated authority
An inventory response can be legitimate task data while containing text the application should not treat as instructions. OWASP describes indirect prompt injection as externally sourced content altering model behavior and recommends separating untrusted content and limiting privileges. Those measures reduce exposure; they do not establish guaranteed prevention. OWASP prompt injection guidance.
In a hypothetical variation, a record includes text urging the agent to retrieve equipment from another site. Its presence does not prove that the agent follows it. If it influences a new lookup, however, that proposal requires authorization on its own facts. The content's arrival through an approved server does not authorize a different destination or purpose.
Preserve the source and role of returned material when assembling context, and assess resulting tool proposals against the task's permitted scope. A server can be approved to provide inventory data without being authorized to redefine the workflow. The security review should examine both influence on the agent and the authority available if it follows that influence.
Evaluate policy against the resolved operation
A useful policy decision concerns the real server, operation, target, and acting identity. For this lookup, the decision needs enough reliable information to connect the selected tool to the inventory service and the requested record to the permitted site. A rule based only on asset_lookup cannot distinguish the intended server from another implementation using that name.
Determine where each fact becomes available. The host may know the user's task and configured endpoint; the server may resolve the equipment reference; the inventory API may hold the record's authoritative site assignment. Place each check where it can use trustworthy context and still constrain the relevant access. No single component should be credited with information it does not receive.
If the host evaluates one target but the server later resolves another, review how the applicable restriction reaches that resolution step. The pre-execution governance guide develops this match between a proposal and the effect it can authorize. Here, the MCP-specific concern is preserving the scope across a protocol boundary and a server's downstream call.
Make approval identify the actual access being requested
An approval should let its reviewer identify the selected server, tool operation, requested site, and data involved. The relevant reviewer must also have authority over the proposed exception. A dialog that merely asks to use asset_lookup may leave the site's access decision unanswered.
Distinguish permission to configure or connect a server from approval for a particular lookup. Likewise, consent in the client does not grant a permission absent at the inventory API. If the task changes to another site, resolve that site's authorization through the appropriate owner and control before proceeding; do not treat an earlier click as transferable permission.
The application needs a defined pending state while an approval is unresolved. When approval arrives, check that it applies to the server, operation, and scope now proposed. A changed endpoint or target requires that relationship to be checked again. These are requirements to establish in the workflow, not guarantees supplied by MCP or by an approval label.
Observe requests, responses, and destination activity separately
Observation should answer which configured server received the call, what operation was requested, and what response was available to the application. Where destination evidence exists, relate it to the specific downstream attempt. An application event showing a tool selection does not establish that the inventory API received a request.
The Tools specification distinguishes protocol-level errors from tool-reported errors such as downstream API or business failures. Preserve those meanings when interpreting the response. A client timeout leaves the request's outcome unresolved unless other evidence establishes it; it is not proof that the server made no downstream call. Tools errors.
For the inventory workflow, decide in advance who can investigate an unresolved lookup and where the necessary records reside. Correlation can connect records for review, but a matching time window alone does not prove which attempt retrieved a record. Avoid turning a missing response into an automatic success or failure classification.
Build an audit record that preserves each identity
An auditor needs to distinguish the person or system requesting the lookup, the client admitted by the MCP service, and the identity acting at the inventory API. Preserve their relationship where it is established, and mark absent mappings as unknown. Using one convenient actor label for all three can conceal where authority changed.
Keep the configuration and policy evidence relevant to the operation: the selected server association, target scope, applicable decision, approval if required, and available records of the attempt and result. The AI agent audit trail guide explains the fuller evidence model, including limits of timestamps, correlation, integrity, and completeness.
The inventory record itself may be sensitive. Prefer the minimum evidence that answers the review question, with controlled references to protected material when necessary. Do not put access tokens into the audit record to demonstrate which credential was used. Recording a credential's identity or purpose does not require retaining its secret value.
Verify runtime controls at their actual boundary
Before enabling this workflow, establish where a disallowed lookup can still be withheld: in the host before invocation, in the MCP server before the inventory call, or at the inventory API. Those locations can enforce different facts. A host decision cannot by itself prove that a remote service constrained later work, and stopping a later call cannot retract data already returned.
Define the behavior when configuration cannot be resolved, evaluation fails, approval is pending, or the destination response is missing. Verify these conditions against the implementation used for the workflow. This is proposed acceptance work for the hypothetical design; no such test results are asserted here. Runtime AI governance explains how decision validity and application depend on those contracts.
In the Claude Code adapter implementation reviewed for this guide, KonaSense associates matching MCP-prefixed tool names with available server configuration for policy evaluation. The association can include a configured URL or command; missing configuration can leave only a parsed name. This is configuration context, not server attestation or proof of downstream authorization.
In that implementation's PreToolUse path, policy decisions can produce deny or ask responses for the host. Evaluation failure falls back to Allow. The response affects execution only if the host applies it; the code does not establish universal MCP coverage or confirm the inventory system's outcome. Assess Kona for Agents against the particular host, event path, server, and enforcement boundary required by the workflow.