RBAC and Audit Logging for MCP
A platform that exposes dozens of tools to LLMs has the same access-control problem as any internal API : Not everyone should be able to call everything, and what happens needs to be traceable. The I-Machine MCP platform implements both at the layer where it matters most : The dispatch layer that sits between the agent and the tool. This article describes how role-based access control and the audit trail are wired.
Where access control lives
Tool dispatch in the agent runtime goes through a ToolBridge. The bridge is the only path by which an agent invokes an MCP tool, and it is the only place where access decisions are made. Every session opens with a set of allowed prefixes assigned to it ; A tool call whose name does not match any allowed prefix is rejected before any network or plugin code runs.
Prefix-based ACLs map naturally to the way MCP tools are named. A plugin owns the prefix of its tools (the AssistantPlugin owns assistant_*, the trading plugin owns trading_*, and so on). Granting an agent access to a plugin is granting access to a prefix ; Revoking is removing it. There is no per-tool ACL to maintain, and adding a new tool to a plugin does not require updating every role.
The MCP server enforces the same policy on its side. The bridge is the fast path that fails locally without spending a round trip ; The server is the authoritative path that enforces regardless of how a client was constructed.
Where roles are defined
User identities and the prefixes they are allowed to call live in a configuration file (user_permissions.json) that the server loads at startup and watches for changes. A user has a role, a role declares the allowed prefixes, and the runtime resolves the effective set at session open.
The platform ships with at least one administrative role for operations and one default test user. Adding a plugin to a running deployment is two steps : Drop the plugin’s .so into the plugin directory (see Plugin Hot-Reload in C++ : Three dlopen Constraints), then update user_permissions.json to grant the new prefix to the roles that should reach it. Forgetting the second step is the most common cause of “tool not found” errors after a fresh deploy.
How sessions inherit policy
When an agent session opens, two things happen :
- The user identity is authenticated against the platform’s credentials
- The mission template the agent runs is resolved through the
TemplateService
The allowed prefixes for the session are the intersection of what the user can do and what the mission template requires. Neither side can be widened by the agent at runtime ; The intersection is computed server-side and the brain never sees a tool it is not permitted to call. See Mission-as-Template : Declarative AI Agents in Production for the template side of this contract.
The audit trail
Audit is not a separate logging layer bolted onto the system. Every agent session writes its entire run to a conversation store : Each user message, each brain response, each tool call, each tool result, each proposal and its outcome, all timestamped and keyed by the session identifier. A compliance auditor reconstructing an incident reads from one place and sees the full causal chain.
The conversation store is the same one the agent uses to resume an interrupted session (see Building a ReAct Agent on Top of MCP). The audit story and the resume story share the same data structure, which is what makes the audit story actually reliable : The audit log is not a parallel write that can drift from reality ; It is the reality.
What this gives a security team
- One enforcement point per access decision. The ToolBridge for the fast path, the server for the authoritative path. Both reference the same configuration.
- Coarse-grained ACLs that scale. Prefix grants instead of per-tool grants. New tools inside an existing plugin do not require role changes.
- Deterministic replay. A conversation identifier plus the conversation store recreates the full run, including which tools were called with which arguments and what they returned.
- A single audit narrative. The agent loop writes the audit trail in the same operation that it runs ; The two cannot diverge.
For the broader platform context, see Self-Hosted MCP Infrastructure for Enterprise. For the deployment that delivers these capabilities to a private network, see Deploying MCP in a Private Network.