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
credentialthat is short-lived and attested, so a leaked token is a narrow, expiring problem rather than a standing one. - A
delegationlist — which other agents it may call, with scope reduction required on every hop.
{ "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.
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.
| Provider | Protocol | Used for |
|---|---|---|
| Okta | OIDC | Approvers, groups, roles |
| Microsoft Entra ID | OIDC | Approvers, groups, roles |
| Google Workspace | OIDC | Approvers, groups, roles |
