Understanding agent identities and scoped access
The core idea behind Bursar is simple: an AI agent should have exactly as much access as the specific task in front of it requires — no more. This article explains how identity and scoping work together to make that possible.
One agent, one identity
Every agent that authenticates through Bursar receives its own certificate-based identity, distinct from every other agent's. This matters because it makes accountability precise: if a "research-agent" makes a request, the certificate that authorized it belongs to that agent and no other. Compare this to the common pattern of a single shared API key wired into multiple scripts, services, or agents — when something goes wrong, a shared credential can't tell you which caller was responsible, and revoking it to contain one bad actor takes down every other legitimate caller too.
Access is brokered per-request, not blanket
Having a distinct identity is only half the picture. The other half is that Bursar brokers access per-request rather than handing an agent a standing, broad credential at issuance time. In practice, this means an agent's certificate proves who it is, but a separate grant determines what it's currently allowed to touch — the same grant-based model used by Broker for network access (see Granting and revoking access) applies to agent access to resources.
A concrete example: a "research-agent" might be granted read-only, scoped access to one specific resource — say, a single knowledge base or a single reporting endpoint — rather than full access to your organization's account or data estate. If that agent is later repurposed, compromised, or simply no longer needs that access, the grant can be revoked without touching the agent's underlying identity or any other agent's access.
Why this matters for AI agents specifically
AI agents are increasingly given the ability to call tools, hold credentials, and act semi-autonomously — which means the blast radius of a single over-privileged or manipulated agent can be large. Scoped, per-request brokerage limits that blast radius by construction: even a fully compromised agent can only do what its current grants allow, and every one of those actions is recorded (see Reading the access ledger).
Setting up scoped access
Scoped grants are configured the same way network grants are — through your organization's console, by an administrator with the appropriate permissions. When provisioning a new agent, it's worth deciding up front what the narrowest set of resources is that the agent actually needs, and granting only that, rather than defaulting to broad access "to be safe" — narrow access is what makes the security model effective in the first place.
For a plain-language tour of what a Bursar-connected agent can actually do once it's scoped, see What can Bursar do?.