The first thing IT asks about an agent is what it can touch if something goes wrong. For most agent deployments nobody can answer that, because the agent holds credentials a person set up once and never scoped. That doesn't pass a security review, and it shouldn't.
On PetroBench an agent is a principal like any other. It authenticates like a user, it's scoped like a user, and it shows up in the audit log like a user. This article covers each layer, because the mechanism is what your security team will want to check.
One permission model, three surfaces
The platform has three surfaces: the browser, the REST API and the MCP server. All three run on the same permission model. A user has roles and permissions scoped across organization, division and region. A token carries abilities that can't exceed what its owner can do. An agent connecting over MCP holds a token, so the agent's ceiling is the token's ceiling, and the token's ceiling is the owner's.
There's no separate agent permission system to review. If your security team has approved how users and API tokens are scoped, they've already reviewed the agent path.
Personal and service tokens
A personal access token belongs to a user and carries a subset of that user's abilities. It fits an engineer trying an agent on their own wells: the agent sees what the engineer sees, at most.
A service token belongs to a division. It survives offboarding, carries only the abilities granted when it was created, and can be restricted to specific source IP addresses. Use it for anything shared or scheduled: a team agent, a warehouse pull, an automation. When the engineer who set it up leaves, the token keeps working and their personal access ends.
Both kinds are created in the admin panel, both carry an expiry, both can be revoked in one action, and admins see both in one list.
Tool visibility
The MCP server doesn't expose every tool and reject calls afterwards. It builds the tool list from the token. A token without simulation read access produces an agent with no simulation tools: nothing to call and nothing to probe. The agent can't ask a question the token can't answer.
The same rule covers writes. An agent can search wells, read equipment and geometry, pull production data and simulation results, run simulations and update well data, and each of those is a separate ability. A token that can't update equipment produces an agent that never sees the equipment write tools. You decide per token how far an agent can go.
Organization boundaries
Every call is scoped to the token's organization. Divisions, regions and groups bound what a user sees in the browser, and the same tree bounds what an agent sees through MCP. A token scoped to one division returns that division's wells and nothing else. Organization isolation is enforced below the tool layer, so there's no cross-tenant query for a tool to get wrong.
The audit log
Agent calls are logged the same way user actions are: which token, which tool, which target, when. An admin reading the log sees agent activity next to browser activity with no gap. This is what turns the security conversation from assurance into evidence. Run the agent for a week, then read its trail.
Identity and sign-in
SSO, SCIM, RBAC and MFA apply to agents the same way they apply to people, because the agent acts under a person's or a division's access.
Claude, ChatGPT and other MCP-compatible tools authenticate over OAuth 2.1. The person signs in, consents to the scopes, and the tool holds a credential tied to that person's access. There's no static secret in a config file, and the access ends when the person's does. Tools that only accept a static token use a scoped service token in the Authorization header, which does the same job with one more thing to rotate.
Revoking access
Remove the connector in the tool, revoke the token in the admin panel, or deactivate the user. Any one of those ends the agent's access. Tokens also expire on the date you set.
The four claims for your security review
Agents authenticate with tokens that can't exceed their owner's access. Tool visibility, reads and writes alike, is gated by token abilities. Organization, division and region isolation applies below the tool layer. Every call is in the audit log.
None of those claims asks anyone to trust an agent. Our bet is that this is the only agent access model that survives a real security review: the reviewer checks the same controls the platform already applies to people, and nothing else.
Related: How to Connect Claude to the PetroBench MCP Server. Trust documentation: docs.petrobench.com/trust.