Learn IAM
Learn IAM

Model Context Protocol (MCP): Identity for AI Tooling

Model Context Protocol (MCP): Identity for AI Tooling

Model Context Protocol (MCP) is a standard way to connect an AI model (or an “agent”) to external tools—APIs, databases, internal services, and automations.

Instead of every AI app inventing a custom “plugin” format, MCP aims to standardize:

  • how tools are described (capabilities + input schemas)
  • how tools are invoked (requests/responses)
  • how context is shared (resources, prompts, files)
  • how you can govern access (identity, authorization, auditing)

This article focuses on MCP from a modern IAM perspective: who is calling what, under what identity, with what scope, and how do you investigate it later?

The cast of characters (mental model)

In real deployments you’ll usually have four roles:

  • User: the human making a request (“summarize this doc”, “rotate these keys”, “open a ticket”).
  • Agent runtime: the application that orchestrates tool use (often called “the agent”).
  • Model provider: the LLM that suggests tool calls (can be local or remote).
  • MCP server(s): tool endpoints that expose capabilities to the agent.

Think of MCP servers as tool gateways. They describe tools and execute them.

How the communication works (high-level)

1) Discovery: tool catalog

An agent connects to an MCP server and retrieves a list of tools and their schemas.

2) Planning: the model proposes tool calls

The model decides (based on the user request + context) which tools to call and with what inputs.

3) Execution: the agent calls tools via MCP

The agent executes the tool calls by sending structured requests to the MCP server(s), gets responses, and feeds results back into the model.

4) Output: final response to the user

The agent composes the final result.

Diagram: end-to-end tool call flow

Diagram

Where IAM fits: identities and trust boundaries

MCP introduces a deceptively important question:

When a tool is called, whose identity is being used?

There are three common patterns:

Pattern A — “User delegated” (best for user-driven actions)

The agent calls tools on behalf of the user.

  • Pros: strong accountability (“Mike did X”), least privilege per user, aligns with audit.
  • Cons: requires token delegation, refresh strategy, revocation, and careful scope design.

Pattern B — “Agent service identity” (common, but risky if overused)

The agent calls tools using its own service account.

  • Pros: simpler for infra automation.
  • Cons: weak attribution (everything looks like the agent), big blast radius if stolen.

Pattern C — “Split identity” (recommended)

  • Read actions use agent identity (with narrow scopes)
  • Write actions require user-delegated identity or explicit approval

Authorization: what should be allowed?

MCP itself doesn’t magically solve authorization. You still need a policy model.

At minimum you should define:

  • Which tools can be used (allowlist per environment)
  • Which inputs are allowed (schema validation + business rules)
  • Which data can be accessed (row-level / object-level controls)
  • Which actions require approval (step-up)

A helpful way to model this:

  • PDP (Policy Decision Point): decides “allow/deny”
  • PEP (Policy Enforcement Point): enforces it

In MCP systems:

  • the agent runtime is often a PEP (it decides which tools to execute)
  • the MCP server should also be a PEP (never trust the client)

Diagram: PDP/PEP placement

Diagram

Key point: don’t rely on the model to “do the right thing.” The model proposes; your enforcement points decide.

Token and secret strategy (modern best practices)

Tool usage almost always implies credentials. Treat this like any other machine identity problem.

Prefer short-lived credentials

  • short-lived access tokens
  • refresh token rotation (if refresh tokens exist)
  • avoid long-lived API keys in prompt context

Bind tokens when possible

Sender-constrained tokens reduce replay:

  • DPoP (bind token to a client key)
  • mTLS (bind token to a TLS channel)

Related: /topic/specifications/dpop-and-sender-constrained-tokens

Never let the model see raw secrets

  • The model should not receive bearer tokens, private keys, or vault tokens.
  • Only the agent runtime / MCP server should handle secrets.

Logging and audit: your incident response lifeline

If an agent can take actions, you need logs that answer:

  • Who requested the action? (user id)
  • Which agent executed it? (service identity)
  • Which tool was called? (name + version)
  • What inputs were provided? (careful: avoid sensitive data)
  • What was the result? (success/failure + identifiers)
  • What downstream calls happened? (request id / trace id)

Recommendation:

  • generate a correlation id at the agent entry point
  • propagate it through MCP server logs and downstream API calls
  • emit structured audit events for tool calls

Concrete example: a tool schema + invocation

Example tool: tickets.create

A tool definition is typically a name + JSON schema for arguments.

json
{
  "name": "tickets.create",
  "description": "Create an incident ticket",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" },
      "severity": { "type": "string", "enum": ["low", "medium", "high"] },
      "system": { "type": "string" },
      "details": { "type": "string" }
    },
    "required": ["title", "severity", "system"]
  }
}

Example invocation

json
{
  "tool": "tickets.create",
  "arguments": {
    "title": "Rotate leaked OAuth tokens for Drift integration",
    "severity": "high",
    "system": "salesforce",
    "details": "Detected suspicious token usage from new IP range"
  }
}

Where the auth happens

  • the agent runtime attaches an access token to the MCP call (or uses mTLS)
  • the MCP server verifies and authorizes the call
  • the MCP server calls the downstream API with the appropriate identity

Common failure modes (what breaks in production)

  • Over-permissioned agent identity: everything works… until a token is stolen.
  • No separation of duties: the agent can both request and approve high-risk actions.
  • No replay defenses: stolen tokens get reused from attacker infrastructure.
  • Missing audit trail: you can’t prove what happened when a tool performs damage.
  • Prompt injection path to tools: untrusted input convinces the model to call a dangerous tool.

Where to go next