Identities & Risk Scores
Every developer and agent that connects through AIControls becomes a tracked identity. The Identities page (Inventory → Identities) shows who is active, their behavioral baseline, risk score, and token usage — giving you a clear picture of your AI estate.
Identity types
AIControls recognizes two identity types:
| Type | Description |
|---|---|
| Developer | A human using an AI coding tool (Claude Code, Cursor, Copilot). Identified by email address from the OIDC token or PAT. Grouped by team. |
| Agent | An automated agent or CI pipeline. Identified by SPIFFE SVID, Kubernetes service account, a named PAT, or, for a Microsoft Entra agent trusted through an agent identity provider, its Entra application ID. Labeled with the agent type (e.g. claude-code). An agent running in Kubernetes also carries its pod identity and the workload it runs as. |
Identities are created automatically on first request — no manual enrollment required.
Governed agents sharing a delegator
A governed agent authenticated via Okta Cross-App Access (XAA) acts on behalf of a delegating human — the identity AIControls records for the underlying request is always that human. When you configure Per-agent identities mode, each governed agent gets its own Okta AI Agent identity and credential, and AIControls tracks it as its own identity — labeled with the agent's name (e.g. "Per-Agent Demo") — with its own request count and audit history.
On the Identities page, a delegating human's governed agents are grouped under the human's row: the parent row shows the human's email, team, and totals, and expands to list each governed agent with its own request count and last-seen time. Token usage and cost are attributed to the delegating human and shown on the parent row — a per-governed-agent token/cost breakdown is not recorded, so those cells show — on the nested agent rows. A governed agent whose delegating human has no other identities on the page renders as a single flat row instead.
Two governed agents sharing the same delegating human are always tracked as distinct identities under Per-agent identities mode. Under Shared identity mode, every governed agent behind one deployment shares a single Okta AI Agent credential, so they cannot be distinguished from each other — only from ordinary human traffic — and are grouped as one identity.
Verified identity
Every identity carries a verified flag, separate from its type. Verified means the identity was established cryptographically or by credential lookup — not just asserted:
| Verification method | How it's established |
|---|---|
| Kubernetes ServiceAccount / OIDC JWT | The bearer token's signature, issuer, and audience were validated against the cluster's OIDC/JWKS issuer |
| VirtualKey | A proxy-issued key was resolved via hash lookup to a known agent record |
An identity is unverified in every other case: a validationMode: none caller, an identity built from unsigned JWT claims (validationMode: passthrough), or any self-declared identity that was never checked against a signing key or key store. Unverified doesn't mean untracked — the identity still appears in the audit log and the Identities page — it means the proxy took the caller's word for who it is.
By default AIControls lets unverified traffic through like any other identity. Administrators can flip on a stricter mode that hard-blocks any request from an unverified identity and records the attempt in the audit log (Policy: unverified-identity). This is a deployment-level setting — see Agent Identity for how to enable it and how it interacts with the identity validation mode.
Risk scores
Each identity carries a continuously updated risk score (0–100). The score reflects these signals over the last 7 days. Attack-pattern contributions use the first detection time, so repeated background scans do not renew an old detection. Patterns are attributed to the executing identities in their recorded execution evidence, not to the session owner; unavailable execution evidence is not inferred from ownership. Legacy detections without captured attribution require their original audit rows:
| Signal | Weight |
|---|---|
| Violation rate — requests denied or flagged by policy | High |
| HITL rate — requests routed for human approval | High |
| Recent activity | Up to 15 points |
| Content-safety findings | Up to 20 points |
| Unverified external-source access | Up to 20 points |
| Attack patterns — attack pattern matches attributed to this identity | Additive, up to 25 points |
Attack patterns add points directly to the score: 20 per Critical match, 10 per High, 5 per Medium, capped at 25 points in total. If the optional LLM judge escalated a match, it counts at the next severity up; if the judge downgraded it, it counts for half. Exempted matches don't count. The same evidence chain detected at both identity and session scope counts once. Each contribution is scoped to the executing identity and namespace captured with its execution evidence. A recently detected pattern can contribute even after its original calls leave the seven-day activity window; its contribution expires seven days after first detection.
High- and critical-band calls feed the separate impact surface and impact band, alongside elevated-tool breadth and datasource reach. They do not add points to the composite risk score: two high-band calls weigh the same as one critical-band call, and the factor reaches its full weight at 20 points of exposure (for example, 10 critical-band calls).
Elevated-tool breadth counts distinct tools this identity called that are classified Elevated Privileged — destructive or arbitrary-code tools always count, and write or read tools count once the datasource behind them is classified confidential or restricted. This replaces an older heuristic that only looked for write-sounding words in a tool's name (a tool named apply_filter no longer counts just because it contains "apply", and a tool named remove_dataset now counts even though it doesn't contain the word "delete"). A call against a restricted-classification datasource also counts toward this identity's blast radius and is called out explicitly in its risk breakdown.
Identities are ranked on the Security Posture page. A rising score triggers an admin alert; a score above the configured threshold can trigger auto-pause when anomaly detection is enabled.
An identity's Safety tab shows each factor next to the score: violation rate, HITL rate, blast radius, Attack patterns (match count and the points they added), High / critical-band calls, and Skill risk when the identity invoked any skills.
When the AI Analyst is enabled, administrators can select Generate AI Analyst explanation on an identity's Safety tab to explain what's driving its score. Opening the tab does not generate a narrative or trigger a provider call; the risk-band description remains available without generation.
Skill risk
An agent's detail page also shows skill risk — the risk band of the riskiest skill the agent invoked in the last 7 days, and how many invoked skills fall in the review or blocked bands. This is a separately-labelled signal, shown beside the composite risk score, never summed into it — a low-violation agent that invoked a blocked-band skill still shows a low composite score with a visible skill-risk flag, so the two facts stay distinguishable.
Behavioral baselines
AIControls learns typical call rate, token volume, tool mix, and active hours using the deployment-configured baseline window and learning requirements. Baseline alerts appear in Security Events. Detection controls and risk scoring remain separate settings.
The identity view distinguishes learning, established, and anomaly states from disabled detection, insufficient samples, stale comparisons, and unavailable runtime status. Available comparison data requires all returned comparisons to be fresh and at least one signal to have enough samples for evaluation; it does not establish coverage for every signal or proof of compliance. Baseline history is keyed by agent ID and does not establish workload or cluster isolation.
Disabling baseline alerts preserves learning and policy measurements only while the baseline worker is available. Disabling the worker in deployment configuration stops those measurements. Existing findings remain subject to normal retention. See Configure detection thresholds for the control and startup prerequisite.
Developer detail view
Click any identity to open its detail page, which has a breadcrumb back to Identities above the title: token usage and cost, active sessions, recent audit events, the risk score trend, team membership, and issued PATs. Admins can add or revoke PATs directly from that page. A revoked PAT stops working immediately on the replica that handles the revoke and within 30 seconds on other replicas. Per-developer spend limits are user-scope budget rules on Budgets → Rules.
Pod and workload
An agent running in Kubernetes presents a projected service account token. AIControls reads the pod identity out of that token's claims and records it on the identity and on every audit event:
| Field | What it tells you |
|---|---|
| Pod | The pod the agent last ran as |
| Pod UID | Which pod, unambiguously. Two agents that share a service account have the same agent ID, so the pod UID is the only thing that separates them. |
| Node | The node the pod was scheduled on |
| SA UID | UID of the service account the pod ran as |
The claims are cryptographically bound to the pod. AIControls never infers pod identity from the request source address, because anything in front of AIControls can set X-Forwarded-For.
When AIControls observes your cluster, it follows the pod's ownerReferences to the workload that owns it — Deployment, StatefulSet, CronJob, an unowned Job, or the pod itself — and shows that workload on the agent's detail page along with:
- Discovery: what kind of AI workload it is, whether that is
Confirmedor onlySuspected, whether the AI workload inventory still sees it, the signals behind the verdict, and the container image. - Protection: the workload's independent Registration, Runtime, Enforcement, and Verification statuses, plus the reason behind its current condition.
View workload opens the workload's detail page, so you can move from an agent to its Deployment and current protection evidence without searching for it.
The agent detail page shows this section only for agents that presented a projected service account token. If the workload is missing, pod-to-workload attribution needs AIControls to be observing the cluster — see Workload Protection.
See also
- Delete or Block an Identity — remove a stale identity row, or generate a scoped deny policy to cut off a misbehaving one
- Assign Autonomy Tiers
- MCP Governance — access types, Elevated Privileged tools, and data classification
Identity security findings
The Security tab in an identity profile shows a fixed last-24-hour window, the recorded finding count, and the newest three findings. Open a finding to review its evidence in Security → Activity, or select View all findings. Browser Back restores the profile's Security tab and original time window. Findings are ordered by time; the preview is not a risk score.
The preview uses the identity's supported recorded agent or developer key. Governed clients, Kubernetes identities, and other identities without a supported key show Identity security scope unavailable. They do not fall back to a broader search.
Observer user findings match the recorded developer ID. Audit, content-safety and baseline records stored under an email may be omitted, so the preview displays an attribution warning even when the selected sources were read successfully. Counts describe matching records, not the user's complete security history. Source-read details disclose unsupported or unavailable evidence. An empty result does not establish safety, and failed or denied reads are not shown as zero findings.