MCP access control: scoped credentials, allow-lists and audit logs

An SI assistant becomes useful at work when it can act: read a ticket, update a record, query a database, draft a reply in the right thread. Each of those actions runs against a business system with real data and real permissions. Connecting an assistant to a tool is a security decision, and it needs the same care as granting a new employee access.

The Model Context Protocol (MCP) has become a widely adopted way to make that connection [14]. This explainer covers what the protocol does, what it leaves to the people who deploy it, and five controls that keep tool access governed.

What MCP is

Anthropic introduced MCP on 25 November 2024 as "a new standard for connecting AI assistants to the systems where data lives" [1]. The protocol uses JSON-RPC messages between three roles: hosts, the SI applications that start connections; clients, the connectors inside a host; and servers, the services that provide context and capabilities [2]. Servers offer resources, prompts and tools. Tools are functions the model can call [2].

The specification is direct about the risk. "Tools represent arbitrary code execution and must be treated with appropriate caution," it says, and descriptions of tool behavior "should be considered untrusted, unless obtained from a trusted server" [2]. It also says that MCP "cannot enforce these security principles at the protocol level" [2]. Governance is the implementer's job.

How it spread

What can go wrong

Published research describes the failure modes. Invariant Labs showed tool poisoning, where "malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models", and the rug pull, where a server changes a tool's description after the user has approved it [17]. In May 2025 the same team showed a malicious issue in a public repository steering an agent, through an MCP server, into leaking data from private repositories. The researchers described it as an architectural issue in the agent system [18]. Simon Willison named the combination behind such attacks the lethal trifecta: access to private data, exposure to untrusted content and the ability to communicate externally [19].

Isolation failures are concrete too. In June 2025, a work-management software vendor disclosed that a logic flaw in its MCP server had exposed customer data to users in other organizations, an incident affecting roughly 1,000 customers [20]. The OWASP list of risks for LLM applications calls the general problem excessive agency: excessive functionality, excessive permissions and excessive autonomy [21].

Five controls

1. Tenant isolation. No request made for one customer reaches another customer's data or credentials. An isolated server per tenant meets this: each customer gets its own MCP server, with its own runtime, credentials store and network policy, so a logic flaw in one server has no other customer's data to expose. So does a shared server that scopes credentials per call: the customer is taken from the verified token on each request [7], and only that customer's credentials are loaded for that call. Kubernetes guidance recommends starting tenant networks from a default policy that denies pod-to-pod traffic and adding narrower rules from there [23].

2. Scoped, audience-bound credentials. The specification requires clients to name the server a token is for, using OAuth resource indicators, and requires servers to accept only tokens "issued specifically for them" [4]. It forbids passing a client's token through to downstream APIs [4, 7]. Scopes start small and grow through step-up authorization when a privileged tool is first used. The security guidance lists wildcard scopes such as * or full-access among common mistakes [7].

3. Allow-lists. Each tenant gets an explicit list of servers and tools. Under revision 2026-07-28 a server's tool list may vary by the authorization on the request, so a caller sees only the tools its scopes permit [5]. Over HTTP, every request carries its method in a header and every tool call carries the tool name, so a gateway can enforce the list without parsing the body, and servers must reject requests whose headers and body disagree [6]. Tool descriptions are pinned by hash, so a changed description is caught before the model sees it [17].

4. Approval for consequential actions. The specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations" [5]. Which actions need a person's approval is set by the operator's policy. A tool's own annotation saying it is read-only is a hint, and clients "MUST consider tool annotations to be untrusted unless they come from trusted servers" [5].

5. Audit logs that answer the usual questions. Every tool call is logged with what happened, when, where, from which source, with what outcome and on whose behalf, the content NIST SP 800-53 sets for audit records [22]. The specification asks clients to "log tool usage for audit purposes" [5], and the security guidance asks servers to log scope elevations with correlation IDs [7]. Revision 2026-07-28 documents how trace context travels with each request, so one call can be followed across systems [3].

Where enterprises fit

For larger organizations, the Enterprise-Managed Authorization extension makes the company's identity provider "the authoritative decision-maker" for which MCP servers employees can reach. Access policies sit in one place, and revoking an employee's access happens once, at the identity provider [16].

Rillor's platform

Rillor builds and secures agentic SI systems. The tenant isolation tests on Rillor's platform, and what an agentic security engagement covers, are on our agentic security page.

Read the full report

The full report, available as a PDF, maps each control to the MCP specification, NIST SP 800-53 and the OWASP guidance, and sets out the threats, the protocol's security requirements and the adoption record in detail.