An agent that can reach everything is a liability. An agent that can reach exactly what it needs is a colleague you can trust.
The Problem in One Sentence
A single chat with an AI assistant can touch several systems: it fetches a sales report, then drafts follow-up tasks in another app. Every one of those hops needs its own yes or no from an identity system. Oracle Cloud Infrastructure IAM now offers building blocks that handle this for Model Context Protocol (MCP) servers.
Why MCP Needs a Gatekeeper
MCP is the common language agents use to find and call tools in databases, APIs, and business software. That convenience cuts both ways. Without guardrails, a well-meaning agent can wander into places it should never go. OCI IAM acts as the gatekeeper: it approves which clients are allowed, narrows which resources they can touch, and signs off on actions that happen downstream.
How the Handshake Works
- Discover. The MCP client reads the server's Protected Resource Metadata and learns where the authorization and token endpoints live. No hard-coded settings needed.
- Identify. The client presents its identity through a metadata document (explained below).
- Authenticate. The user signs in using the authorization-code flow with PKCE.
- Receive a scoped token. OCI IAM issues an access token matching the requested MCP resource and scopes.
- Verify. The MCP server checks validity, audience, and scopes before running any tool.
Client Onboarding Without the Paperwork
With Client ID Metadata Documents, an application simply hosts a small JSON file at a public HTTPS address and uses that address as its client ID. OCI IAM retrieves and validates the file, so nobody has to register the same client over and over.
Two Locks, Two Keys
| Allowlist | Where it lives | What it decides |
|---|---|---|
| Metadata locations | Identity domain | Which sources of client documents are trusted |
| Approved clients | Resource application | Which clients may call that specific protected resource |
The result: a client can be cleared for sales reporting and still be locked out of every other application.
Tokens That Know Their Limits
For interactive use, a public client runs the authorization-code flow with Proof Key for Code Exchange. After the user logs in and the client submits its code challenge, OCI IAM returns a token whose audience and scopes fit the requested MCP resource. Read-only report access stays separate from the right to modify data, and the token never exceeds what the administrator set up.
When One App Is Not Enough: Cross-App Access
Suppose the agent must now act in a second system. OCI IAM handles this with an Identity Assertion JWT Authorization Grant:
- A confidential client in the source domain trades the user's ID token for a signed intermediate grant.
- A second confidential client redeems that grant at the target domain.
- The target domain maps the user, applies its own policies, and issues a brand new access token for its API.
Two things stand out. The interactive client never handles confidential credentials, and each domain keeps full authority over its own rules. The sales app, for example, still decides which tasks that user may create.