Why MCP Tool Access Does Not Replace Runtime Identity
MCP can narrow which tools an agent may call, but it does not replace runtime identity, delegated user access, or downstream system permissions.
Visual explainer
A diagram-led way of understanding the underlying structure.
MCP can narrow which tools an agent may call, but it does not replace runtime identity, delegated user access, or downstream system permissions.
Runtime identity defines the agent as a principal.
MCP defines which tools the runtime may call.
Delegated access is only for user-owned systems, and target systems still enforce their own permissions.
I keep seeing the same confusion in agent system design. Teams notice that MCP can control which tools the runtime may call, then assume that means MCP has solved identity. It has not. MCP narrows the tool surface. It does not define who the agent is, when the agent is acting on behalf of a user, or what the target system still permits once the call gets there.
That separation matters because these layers answer different questions. If I collapse them into one vague idea of access, I get weak audit trails, messy revocation, and no clean way to explain what happened when an agent crosses from platform work into user-owned systems.
warning
Why anyone should care
If your agents will ever do more than a toy demo, this distinction determines whether you can govern actions, revoke access cleanly, and explain who did what across tool calls.
- You cannot audit a principal you never modeled
- You cannot revoke cleanly if runtime and user access are collapsed
- You cannot rely on MCP alone to define downstream permissions
Where the layers actually sit
The simplest way to read the flow is left to right. The runtime acts as the workload. Runtime identity answers who the agent is. MCP answers which tools that runtime may call. Delegated access appears only when one of those calls crosses into a user-owned system. The target system still has the final say over what happens next.
| Layer | Question it answers | What it controls | Why it matters |
|---|---|---|---|
| Runtime identity | Who is the agent? | Machine principal for the running workload | Gives the system a real non-human identity with audit and revocation |
| MCP access boundary | Which tools may it call? | Allowed tool surface and MCP server access | Narrows the runtime's reach without defining the whole identity model |
| Delegated access | Is the agent acting on behalf of a user? | User-scoped authorization for user-owned systems | Keeps consent and revocation tied to the person who owns the data |
| Downstream permissions | What can the target system still allow? | System-specific scopes, ACLs, and resource permissions | Prevents a tool call from being mistaken for unlimited power |
These layers cooperate, but they do not collapse into one thing.
A real example
Take a runtime running in Azure Container Apps. The container can have a managed identity. That identity can obtain a token for an internal MCP gateway. The MCP gateway can expose only a narrow set of tools, such as search_kb or create_ticket_note. Those calls are platform-owned actions, so the runtime identity is enough.
Now compare that with a tool like open_user_drive_file. That action crosses into a user-owned system. I do not want the runtime identity acting alone there. I want delegated user access, because the action should stay inside that user's permission envelope. MCP may still gate the tool call, but the kind of identity behind the call changes.
How the same runtime can cross both boundaries
The runtime starts with its own machine identity
That gives the workload a real principal before any tool call happens.
MCP narrows the tool surface
The runtime can only call the tools the MCP layer allows.
Platform-owned calls stay on the runtime identity
Searching internal knowledge or writing an internal note can remain machine-to-machine.
User-owned calls switch to delegated access
Opening a personal file or mailbox needs user-scoped authorization instead of just runtime identity.
What breaks when teams collapse the layers
What clean separation buys you, and what collapse costs you
When the layers stay separate
- The agent is auditable as a real principal
- Tool access can stay narrow without pretending to solve everything
- User-owned access can be revoked without breaking platform-owned work
When teams flatten them together
- A tool boundary gets mistaken for a full identity model
- Shared credentials creep back in because nobody modeled delegated access
- Post-incident review becomes guesswork about which layer actually failed
That is why I care about this distinction. It is not semantic cleanup. It is operational control. If an agent is going to call tools across enterprise systems, I need to know who the workload is, which tools it may touch, when it is acting for a user, and what the target system still allows after the call arrives.
MCP narrows the tool surface. Runtime identity defines the workload. Delegated access defines when the agent steps into a user's boundary.
takeaway
The short version
MCP sits on top of identity. It does not replace it.
- Runtime identity answers who the agent is
- MCP answers which tools the runtime may call
- Delegated access appears only when the action belongs to a user
- Target systems still enforce their own permissions
Discussion
Responses, reactions, and open questions.
The article stays static. The conversation sits underneath it. Sign in with your email, react to the argument, and join the discussion.
Join the discussion
Use your email to get a one-time sign-in code. First comments may wait in moderation before they appear publicly.
Continue reading