The Agent Access Problem
Right now, an agent on your team has the keys to everything
When a developer on your team uses Claude Code, the agent is running as them — with their SSH key, their GitHub token, their AWS credentials, their database password. There is no identity for the agent. There is no audit trail of which tools it called. There is no policy between the agent's decision to act and the action landing on production.
This is not a theoretical concern. It is the default configuration of every MCP-enabled coding assistant shipping today.
Three gaps in your current access model
1. No identity for the agent
The agent inherits the user's identity. When your auditor asks "which agent read this row," there is no answer — the logs show the human who ran the agent, not the agent itself. Delegation is invisible.
2. No policy at the tool-call boundary
Your IAM policies govern who can touch what when humans are the actors. An agent does not announce itself as a different actor type, so the same rules apply. That means the agent inherits the union of its user's grants — including grants the user never intended to expose to a machine.
3. No differentiated trust between agents
A security scanner, a CI bot, a long-running planner, and an ad-hoc Claude Code session all hit your systems with the same credential shape. Your policy has no way to say "the planner can read, the ad-hoc session can write, the scanner can do neither beyond its scope."
Why RBAC and traditional OAuth do not fix this
RBAC assumes one actor. Roles are assigned to users. Agents acting on behalf of users create composite identities that RBAC cannot express cleanly.
Traditional OAuth clients are trusted at registration, not at call time. Once a client has a token, scope checks happen at the resource server if they happen at all. There is no place to say "this tool call, right now, with this input, should be denied."
Per-application authorization code is brittle. Even if one of your apps enforces strong policy, every other app has to enforce the same policy on its own. The agent can pivot to a different backend and avoid your controls.
What a safe model looks like
Every agent call goes through one enforcement point. That enforcement point:
- Authenticates the agent, not the human behind it. Agents register with a software statement that identifies their provider, model, and trust tier.
- Authorizes every tool call, not every login. Scope checks happen on the call itself — not on the session that opened hours ago.
- Re-evaluates policy on every call. When policy changes, the next tool call reflects the change — no token reissue, no agent restart.
- Logs every decision with the agent identity, the tool, the scope, the outcome, and the reason.
That is what the PBAC Gateway is. It sits between the MCP client (Claude Code, OpenCode, Cline, Continue, anything else speaking MCP with OAuth) and your actual backend APIs. Every tools/call is introspected against the PBAC Authorization Server, which consults OPA for the decision.
Concrete failure modes this prevents
| If you don't have policy at the agent boundary | What can happen |
|---|---|
| Claude Code runs as the developer | Agent reads production secrets the developer has occasional access to, not realizing the tool should not have been invoked |
| CI bot shares a service account with deploys | Bot gets prompted into creating a merge request that self-approves and deploys |
| Security scanner gets a long-lived token | Compromised scanner token becomes a read-all credential for days |
| Autonomous planner persists across sessions | Planner accumulates privilege over time — each new tool added widens the agent's surface without review |
| Developer grants a broad OAuth scope once | Scope persists; every future agent and future tool can invoke it |
Each row corresponds to a policy rule you can write in PBAC and enforce at the gateway — without touching the agent, the backend, or the user's IAM.
What to do next
- Read the MCP Gateway overview — understand where the gateway sits and what it does.
- Run through the dashboard onboarding — five steps. From sign-in to Claude Code hitting a policy-enforced gateway.
- Connect your own MCP client — integration walkthroughs for Claude Code, Claude Desktop, Cursor, VS Code, OpenCode, and Windsurf.
- Talk to us — map this to your environment.
The shortest path to a demo that will convince your security team is the dashboard onboarding — you end up with a live 403 on a merge attempt and a 200 on a read, with the same token, enforced by policy. That is the artifact to bring to the review.