Skip to content
Browse documentation

Agents & identity

Every governed agent has a workload identity, an accountable owner, and a scope. Here is how that identity is issued, attested, and used in policy.

Agents typically inherit whatever credential is lying around — a developer's token, a shared service account. When something happens, the trail says a human did it, and the blast radius is that human's entire access. An agent identity exists to make the trail say what actually happened instead.

What an identity contains

  • A stable agent_id, bound to attested properties of the workload it runs as — not a string copied into an environment variable.
  • An owner — the person or team accountable for it, which is what gives escalation a destination.
  • scopes — the specific permissions it may be granted, evaluated by policy per call, not a blanket grant.
  • A credential that is short-lived and attested, so a leaked token is a narrow, expiring problem rather than a standing one.
  • A delegation list — which other agents it may call, with scope reduction required on every hop.
Agent identity documentJSON
{  "agent_id": "agt_7Q2X9F",  "name": "pr-triage",  "owner": { "type": "user", "id": "u_4821", "email": "priya@example.com" },  "runtime": { "framework": "claude-code", "version": "2.1.x" },  "scopes": ["repo:read", "issues:read", "slack:post"],  "environments": ["staging"],  "credential": { "type": "short-lived", "ttl_seconds": 900, "attested": true },  "delegation": { "may_invoke": ["agt_1B4K7C"], "scope_reduction": "required" }}

Attestation

Identity is only as strong as the platform underneath it. On a developer laptop the identity is bound to a device-held key; in a managed cluster it can be bound to hardware-rooted attestation, which is materially stronger. Cirvix labels which kind an identity has rather than presenting both the same way.

Warning
A laptop-bound identity is weaker than a cluster-attested one, and the console says so. Treat agents running on unmanaged developer machines as a narrower trust tier when writing policy for production resources.

Ownership and the trust graph

Every agent has one accountable owner, and delegation between agents is declared explicitly rather than discovered from behaviour. That declared graph is what the A2A Gateway enforces: a delegated call's scope can only narrow, never regain privilege by going one hop deeper.

Federating with your identity provider

Human approvers, groups, and roles come from the directory you already run. Cirvix does not become a second source of truth for who works here.

ProviderProtocolUsed for
OktaOIDCApprovers, groups, roles
Microsoft Entra IDOIDCApprovers, groups, roles
Google WorkspaceOIDCApprovers, groups, roles
Note
Cirvix does not replace your identity provider. If a person's directory account is compromised, their approval authority is compromised with it — that risk sits with your IdP's own hardening, not with Cirvix.
Edit this page on GitHub
Was this page helpful?