Governing MCP agents: identity, permissions and logging

Until recently, connecting an AI agent to a system required a custom integration for every combination of model and tool. The Model Context Protocol (MCP) defines a standard way for an AI application to discover tools, learn their parameters and invoke them. The same tool (look up a ticket, read metrics, open a change) can then serve several agents without being rewritten.

It also forces you to get governance in order. The easier it is to connect tools, the easier it is for an agent to end up with access to systems nobody reviewed. MCP solves the "how it connects"; the "who can use what, on whose behalf and with what evidence" is still the organization's responsibility. Here we propose the minimum controls for taking MCP agents into production.

What MCP solves and what it leaves to you

The MCP specification (revision 2025-06-18) distinguishes three parts: the host, which is the AI application; the client, which is the connector inside the host; and the server, which exposes tools, resources and prompt templates. Messages use JSON-RPC over a local transport (stdio) or HTTP.

The specification is explicit about security in several points that matter for governance:

• It recommends always having a human in the loop able to deny tool invocations, and that the client ask for confirmation on sensitive operations.
• It requires servers to validate inputs, implement access controls and rate limit invocations.
• It recommends that clients log tool usage for audit purposes.
• It warns that annotations describing a tool's behavior (for example, whether it is read-only) must be treated as untrusted unless they come from a trusted server.

The protocol, however, cannot enforce these principles on its own; the specification itself leaves consent flows, access controls and data protection to implementers. That is why we recommend not connecting agents directly to any server, but through a control point (an MCP gateway or proxy, or the equivalent layer in your platform) where identity, policy and logging are handled centrally.

Identity: on whose behalf the agent acts

The first governance question: when the agent calls a tool, who is acting? There are two models, and you should choose one deliberately for each use case.

• Delegation from a user. The agent acts on behalf of a specific person and with, at most, that person's permissions. This is the natural model for assistants working alongside an analyst.
• The agent's own identity. The agent acts as a dedicated service account, with permissions defined for its function. This is the usual model for agents that run without a person in front of them, such as a monitoring or triage agent.

In both cases, the log keeps both identities when they exist: the agent's and the user's who started the task. Without that, an audit cannot tell what a person decided from what the model decided.

For HTTP transports, the MCP authorization specification builds on the OAuth 2.1 draft and related standards. The points that matter most for governance are these:

• Authorization is optional in the protocol. Over HTTP, implementations should follow the specification; over a local transport (stdio), credentials come from the environment. A server without authorization is a decision your policy should explicitly allow or forbid.
• The MCP server acts as an OAuth resource server and must publish its metadata according to RFC 9728 (OAuth 2.0 Protected Resource Metadata), which states which authorization server protects it. This ties token issuance to your corporate identity provider.
• The client must state which server the token is for (resource indicators, RFC 8707), and the server must reject tokens that were not issued for it.
• The server must not forward the token it received (token passthrough). If it needs to call an API, it uses a separate token issued for that API. The specification forbids passthrough because it breaks traceability and lets callers bypass controls.
• The client must use PKCE in the authorization flow, and short-lived access tokens are recommended.

Put as a rule of thumb: each MCP server is a protected resource with its own audience, and each hop between systems carries its own credential. If a server accepts "any valid token from the organization", access control ends up in the agent's hands.

Permissions: least privilege per tool

The OWASP Top 10 for LLM Applications 2025 describes the risk of Excessive Agency and attributes it to three causes: excessive functionality, excessive permissions and excessive autonomy. Ungoverned, MCP makes all three easier, because a server usually exposes many tools and it is tempting to connect the whole server.

OWASP's mitigations carry over well to MCP: expose only the tools that are needed, prefer granular tools over open-ended ones (one that "runs any command"), grant minimum permissions in the target systems and enforce authorization in those systems, not in the model's judgment.

That is why the unit of governance is not the MCP server but the tool. These are the controls we recommend defining for each one before enabling it.

Control	What to define	Illustrative example
Owner	Team responsible for the tool and the system it touches	Platform team for "restart_pod"
Type of effect	Read-only, reversible write or irreversible write	"get_incident": read-only
Identity	Delegated from the user or the agent's own account	Triage agent with a dedicated service account
Scope	Specific permissions and resources in the target system	Only one service's resource group
Approval	When human confirmation is required, and from whom	Production changes: approval from the on-call lead
Limits	Allowed frequency, volume and time window	Maximum invocations per hour set by the owner
Data	What data it may return to the model and what is masked	No customer personal data in the response
Logging	Which fields are kept and where	Parameters, result and related ticket

MCP annotations that declare whether a tool is read-only or destructive are descriptive, not a control. Your review determines the type of effect, and the target system's permissions enforce it.

Consent and human approval

The MCP specification states that users must consent to and understand data access and operations, and that the host must obtain explicit consent before invoking tools. In a desktop assistant that means a confirmation prompt; in an operations agent running in the background, it has to be designed.

We recommend tying approval to each use case's level of autonomy: read-only tools are authorized when they are enabled; reversible write tools may require per-execution approval until they build a track record; irreversible ones always require approval from an authorized person other than whoever started the task, recorded together with the call. We cover this in guardrails for AI agents.

The MCP server that acts as an intermediary to a third-party API deserves special attention. The specification describes the "confused deputy" problem: if the server uses a static client ID with the third party, an attacker can gain access without the user's real consent. That is why it requires obtaining user consent for each dynamically registered client before forwarding the request to the third party.

Logging and auditing every call

An agent that uses ten tools in a task produces ten actions someone may have to explain in an audit. To reconstruct the chain, we recommend recording for each call:

• Agent identity, user identity (if any) and the originating session or task.
• Server and tool invoked, with their version.
• Parameters sent and result returned, with sensitive data masked according to your policy.
• Policy decision applied (allowed, denied, pending approval) and, if approved, who approved it.
• A correlation ID linking the call to the incident or change ticket.

The log is stored outside the agent's write reach, with the same retention as other operational records. With a single control point it comes naturally; if each server logs on its own, correlation becomes much harder. Our article on incident triage with agents shows what evidence to keep at each step.

Inventory of approved servers and third-party servers

Installing an MCP server is usually trivial, so the inventory must be the condition for connecting, not an afterthought. We recommend a catalog of approved servers with owner, origin (internal, vendor or community), version, enabled tools, systems touched, type of authorization and date of last review. Anything not in the catalog is blocked at the control point.

Third-party servers deserve the same treatment as any software component from a vendor:

1. Origin and code review. Who publishes it, how it is maintained and what permissions it asks for. A local server runs with the privileges of the process that launches it.
2. Pinned versions. An update can change the tools or their descriptions. Review changes before accepting them.
3. Descriptions as untrusted input. The model reads them; malicious text there works as prompt injection.
4. Vendor risk. If the server processes data outside your infrastructure, apply your third-party management process.

All of this fits into the security work on AI we discuss in the CISO and AI.

How it fits your AI governance

None of this requires a new framework. The NIST AI Risk Management Framework organizes AI risk into four functions: Govern, Map, Measure and Manage. The inventory belongs to Map; per-tool policy and human approval, to Govern and Manage; the call log feeds Measure. With ISO/IEC 42001, these controls are documented in the AI management system, as we explain in ISO/IEC 42001 in practice.

To get started, we recommend three steps: inventory the MCP servers already in use (including those teams installed on their own), put a control point in front of those that touch production, and complete the controls table for each enabled tool. Before enabling tools that process personal data or affect regulated controls, validate the policy with Security, Risk and Compliance.