Oracle explains how to control access to MCP servers with OCI IAM

Oracle has published a guide on its corporate blog titled Managing Access to MCP Servers with OCI IAM. It explains how to use Oracle Cloud Infrastructure's identity service to decide who can connect to an MCP server and what they can do on it. It came out late this week and reached us because we follow Model Context Protocol news closely.

The starting point is simple. A local MCP server, declared in `claude_desktop_config.json` or added from Claude Code, runs with the permissions of the user who starts it. A remote MCP server, on the other hand, offers its tools over the network to any client that knows how to reach it. In that case the question is no longer what a tool does, but who is allowed to use it.

What Oracle proposes

Judging by the title and context, the idea is to rely on OCI IAM, Oracle Cloud's identity and access system, to control access to MCP servers deployed on its cloud. OCI IAM already handles identity domains, groups, policies and federation with external providers. It makes sense to reuse that layer instead of having every MCP server build its own user system. For the configuration details, the original guide is the place to go. Here we are more interested in what this step by Oracle says.

Why it matters

Since 2025, the MCP specification has included an OAuth-based authorization system, designed precisely for remote servers. In theory, that lets a client such as Claude get a token and present it to the server. In practice, many companies are missing the key piece: the identity provider that issues those tokens, sets permissions and keeps an audit record. That is where the big cloud providers come in.

Oracle publishing guides like this points to two things. First, there are corporate customers deploying MCP servers on their infrastructure and asking how to protect them. Second, MCP is no longer just something individual developers play with and is entering company security processes. There the questions are different: who approved an access, how it is withdrawn and what gets recorded.

Who it helps

Teams already working on OCI who want to give agents access to internal tools without building a separate authentication system.
Security leads, who need agent access to go through the same policies as any other application.
Integrators building MCP servers for clients with regulatory compliance obligations.

If you work on another cloud, the idea still holds: an agent's identity should be managed in the same place as the rest of the organization's identities.

What to review

Whatever the provider, on the MCP projects we build we always check a few basics:

That the remote server does not accept anonymous requests, not even in test environments open to the internet.
That tokens only give access to the tools that are needed and expire quickly.
That every use of a tool is recorded along with the identity behind it.
That there is a clear procedure for withdrawing access from a specific client or agent.
That tools that write data are kept separate from read-only ones, each with its own permissions.

None of these measures is specific to MCP. They are long-standing security practices applied to a new kind of client. The difference is that this client is a model that chooses on its own which tool to use, which makes an overly broad permission easier to exploit, even by accident.

At ElephantPink we think MCP needed documentation like this: fewer demos and more integration with the identity systems companies already audit. Cloud providers publishing it is a good sign that the protocol is maturing.