Agent identity

Governance → Agent Identity is the security team's portfolio view of every agent identity across the organization: what each agent is (its attestation posture), what it can reach (grants and delegated principals), and the lifecycle controls for taking one out of service. It is visible to org admins and security admins.

Attestation levels

Every agent identity sits at one of three attestation levels — the answer to "how strongly can the platform prove this running workload is the agent it claims to be":

The page opens with the distribution across these three levels, so the headline posture metric — how much of the fleet is not yet workload-attested — is the first thing you see.

Control enforcement state

Below the distribution, each identity control shows its real enforcement state as a badge, sourced from the platform's live configuration rather than its designed intent:

• Enforcing — the control is live and denying.
• Shadow — observing only: the control logs what it would deny without denying it. Would-deny records land in the event stream so you can assess impact before turning enforcement on.
• Not wired — the control exists but its integration isn't configured; no data flows yet.
• Not available — not shipped yet; shown as the upgrade target, not something achievable today.

The controls tracked here are workload identity (whether per-agent workload identities are provisioned at all), cross-agent isolation (the control that stops one agent using another agent's grant — it ships in shadow), workload attestation (the attested:workload upgrade), and trust-mode floors (how many floors are authored).

The identity table

The table lists every agent identity in the org. Columns:

• Agent — display name plus the agent's stable URN.
• Attestation — the level chip (asserted red, placement amber, workload green — the color is the posture read).
• Workspace, Cluster, Owner — where it runs and who owns it.
• Status — the agent's lifecycle state; a killed agent shows killed, a terminally revoked identity shows revoked.

Filter chips narrow the table to All, Not workload-attested (the remediation backlog), Asserted, Placement, or Workload, and a search box matches name, URN, workspace, owner, and cluster.

The identity drawer

Selecting a row opens the identity drill-down:

• Why this level — a one-line explanation of the attestation level (for example, "SA-token attested: pod + namespace + per-agent ServiceAccount (placement). NOT which build").
• Binding — the logical agent URN, its workload identity reference, and the identity mode.
• Attested selectors — the service-account subject, SPIFFE ID (when present), cluster, workspace, and owner.
• Reach — what the identity can act on and who it can act for (below).
• Lifecycle actions — Kill/Resume, Revoke identity, and Delete (below).

Reach — grants and delegated principals

The Reach section answers the incident-response question "if this identity is compromised, what can it touch?":

• Grants — the governed tools the identity can reach, each with its operations. Where an operation runs under a delegated identity, it is marked as user (the agent acts as a person, via their connected account) versus as agent (the agent acts as its own service identity).
• Acts for — the human principals the agent can act on behalf of, as identity-provider users distinct from the agent's own identity. "None — acts only as itself" is the least-privilege baseline.
• Mandates — delegated authority chains; the inventory for these is not yet available, and the drawer says so rather than showing an empty list.

Lifecycle actions

Lifecycle actions live at the bottom of the drawer and are available to org admins and security admins. They sit on two deliberately separate axes — runtime and authentication — so the reversibility of each is unmistakable, and every action states its blast radius before you act:

• Kill agent (reversible) — cancels the agent's in-flight work and scales its workload to zero. Takes an optional reason, recorded in the audit. The same kill switch is available on the agent's detail page; here it is the governance-side control, usable across every workspace in the org.
• Resume agent (the inverse) — scales the workload back to its pre-kill replicas and re-registers it for dispatch.
• Revoke identity (terminal) — the agent's workload identity can never authenticate again. Reinstating the agent requires a new identity via a redeploy. Revocation does not stop the running workload — pair it with Kill when you need both — and it is enforced only where a workload-identity mode is live. Because it is irreversible, the console requires typing the agent's name to confirm, plus an optional recorded reason.
• Delete agent (terminal) — tears down the agent's cluster resources (deployment, service, network policy, secrets). The record is kept for audit. Also a type-the-name confirmation.

A revoked identity is labeled in the table and drawer, with who revoked it; the corresponding kill and revocation events land in the event stream (agent_killed, agent_kill_restored, admin_killed).

Who can see this page

The Governance group — including Agent Identity — is shown to org admins and security admins; other members don't see it in the sidebar and get a not-found response if they navigate directly. Hiding the navigation is a convenience for the role, not the security boundary: the platform enforces authorization on every read and every lifecycle action regardless of what the console displays.