Skip to main content

The agent access problem

An AI agent such as Claude Code works with whatever credentials it is given. Often those are the credentials of the person who runs it. This page sets out why that is hard to govern and how PolicyArc changes it. It is the one place these docs tell that story. The other pages link here.

Three gaps​

The agent has no identity of its own. When an agent uses a person's token or key, every system it touches sees that person. A log can show who ran the agent but not which agent acted, or that an agent acted at all.

Access is decided once, at sign-in. A token issued in the morning still works in the afternoon, for every tool the scope covers. Nothing asks again whether this call, with these arguments, should go ahead.

Every agent gets the same trust. A coding assistant, a scheduled bot and a one-off script all present the same kind of credential. Without an identity for each, a policy cannot give one of them read access and another one write access.

What PolicyArc does about each​

Each agent is a client. An agent registers, or is registered, and gets its own client ID. Policy sees that client on every decision, along with the person when the agent acts for one. Audit rows name the client, and the person when there is one. Agent identity covers how an agent gets its client ID.

Each call is checked. The managed gateway sits between the agent and your tools. Before it forwards a REST call or an MCP tool call to a connected resource, it asks the authorization server at /introspect, and policy decides that one call. Policy sees the scope the call needs, the tool's name and its arguments. A policy change applies to the next call after the policy engine loads it, without a new token. The gateway's two built-in tools, which list and reconnect the caller's own connections, skip this check. Managed gateway explains the flow.

Agents get different trust. Because each agent is its own client, a control can treat them differently. Agent trust tiers puts each agent in a tier you set in a data row. A tier can refuse an agent, limit it to reads, or shorten its tokens.

Risky steps wait for a person. A rule can hold a token request, such as one to write a shared report, until a named person approves it. The hold happens at /token. The gateway never holds a tool call for approval. It allows or refuses it. The approver is the person the rule names, and a /bc-authorize request that names anyone else is refused. Hold an agent's write for a person's approval runs it from start to finish.

Tokens can be short-lived or single-use. A control can shorten how long an agent's tokens last, or make them good for one check. Give an agent single-use tokens shows the second.

Hand-offs stay visible. When one agent hands work to another, it exchanges its token. When it also sends its own token as the actor_token, the new token's act claim names it. Delegation and approval covers it.

Decisions are recorded. The calls the gateway checks, the token requests policy decides and each answer from the approver write an audit row with the client, the user where there is one, and the decision. The approval exchange has gaps. A held token request writes two rows, the request to /bc-authorize writes none, and a poll after the person refuses writes none. No row carries the auth_req_id that ties an approval to its token. Hold an agent's write for a person's approval lists the rows one run left. Audit log explains what a row holds.

Where to start​