Security Posture
AIControls provides a real-time view of risk across your AI estate — computed risk scores per identity, NIST AI RMF compliance mapping, a policy exception workflow, and a human-in-the-loop approval queue.
Correlated findings
Incidents
Security → Activity → Correlated findings opens on Incidents: a short list of open incidents instead of one row per detection. An incident groups findings that share the same actor (the recorded user, else agent, else session), pattern (the detection, such as a sequence template, policy or content-safety detector) and target (the recorded workload, else the MCP server). Findings of one key join the same incident while each is no more than 30 minutes after the previous one; a longer gap starts a new incident. Findings with no recorded user, agent or session group together as Unattributed. A repeated sequence for one user therefore appears once, with its count.
Each incident shows its highest severity, a Status (New, Acknowledged or Resolved), its assignee and, once resolved, its disposition, along with its finding count and first and last seen times. The list shows New and Acknowledged incidents by default; filter by status, assignee or disposition to see the rest. Each incident also carries a verdict (Act now, Needs review or Likely benign) derived from the Judge's verdicts on its sequence matches, its severity, whether a control stopped the calls, and, in the drawer, whether its evidence can be read back. The list sorts by verdict by default, so incidents the Judge marked benign sort below real work and show a Likely benign tag. Select a row to open its drawer: the verdict and why, the actions that fit it, who, when, technique and control outcome, the steps of the newest match, related incidents, and then the findings in the incident, newest first. Select a finding to read its recorded evidence. Severity, source and detector filters, the time range and the search box apply to the findings first. A severity filter keeps incidents whose highest severity matches, without shrinking their counts. Sort by verdict, severity, finding count, or first or last seen. Incidents cover up to 31 days. Choose All findings for the individual events, as before.
Each incident and finding shows a plain-English title instead of a raw identifier, and a MITRE column with the MITRE ATLAS and ATT&CK techniques it maps to. The incident drawer and the finding drawer add why the finding matters, the recommended action, and the techniques with their names. A finding type with no good mapping says why instead of showing a guess. The full list is in the Security Finding Catalog. Administrators can send an incident, with these techniques, to a SIEM (Splunk or Microsoft Sentinel), a webhook or Amazon Security Lake as an OCSF finding; see Export security incidents. They can also create a Jira or ServiceNow ticket for it; see Create Jira and ServiceNow tickets.
Administrators triage an incident from its drawer: assign it, acknowledge it, and resolve it as a true positive, false positive or benign with a required note. A resolved incident is never reopened; later findings open a new incident that links back to it. Every action is kept in a triage history. Findings you have judged safe can be hidden for up to 90 days with a suppression rule, and the triage record can be exported for an audit. When an agent is still acting, an administrator can revoke its access from the same drawer.
Select Summarize incident in the drawer for an opt-in, cited AI Analyst summary of the whole incident. Findings and their evidence rows have no Analyst button, so the one action per incident decides the cost.
An incident only groups existing findings. Its severity is the highest among its findings, after the severity rules; it adds no scoring of its own, and its Actor column uses the same resolution as a finding (a person, an agent acting for a person, a service-account agent or a workload), and an unknown actor shows Unknown with the reason, such as no caller for an MCP server finding. Incident IDs still group by the recorded user, agent or session. Incident boundaries are computed within the selected range: an incident that began before the range starts at its first finding inside it, with a different first seen time and ID. Triage state follows an incident through those boundaries: a view that starts mid-incident still shows its status and assignee.
Severity
High means a confirmed sensitive action: data egress (including a denied attempt to send data out), credential access, or a completed attack chain, which is a matched sequence whether or not its action denies the call. Severity is computed in one place from the finding type, the detector's confidence and the recorded data classification of what was touched. The list, filters, sorting and incidents use the rules in the table below.
| Finding | Severity |
|---|---|
| Egress denied | High. Medium when the call's data classification is recorded as public or internal. A call with no recorded classification stays high. |
| Policy denial or blocked response | High when the call's data classification is recorded as confidential or restricted. Otherwise medium. |
| Attack pattern (a matched sequence) | The template's band: high for chains that read sensitive data and egress it, delete and then egress, or escalate privilege, and critical for an undeclared egress. Medium when the LLM Judge downgraded the match. |
| Content Safety finding | The detector's band, capped at medium when the detector's confidence score is below 0.7. A finding with no recorded score keeps its band. |
| Session anomaly or baseline alert | At most medium. A deviation alone is not a confirmed action. |
| Unregistered workload call | Medium, blocked or not. It is an inventory gap. |
| Runtime observation | Network is medium, DNS is low, open and exec are info. A blocked attempt keeps its behavior's rank. |
| Everything else (approvals, exceptions, Human-in-the-loop decisions, unmanaged MCP servers) | Medium. |
When evidence cannot be read back (truncated, a retrieval error, unavailable, expired, pending capture, dropped, or not retained), its severity is capped at medium. The cap applies to every finding source with retained evidence: attack patterns, audit findings such as denied calls, and Content Safety detections. It applies on every Security finding surface, so the finding list, the severity filter and its counts, the Home attention queue, incident severity and ordering, the Analyst aggregates, the evidence view and AI Analyst all show the same value, and a capped finding does not match a High filter or outrank a readable one. The Content Safety dashboard counts, a session's own list of Content Safety detections and the adoption health summary report the detector's recorded severity and are not capped. AIControls records whether a finding's evidence can be read when it writes the finding. For an audit finding it also follows the full capture: a capture that is still pending, was dropped, or has been pruned or archived by retention caps the finding as soon as that state is recorded, and a capture that completes lifts the cap. Clearing old snippets under snippet retention is applied the same way, so an LLM finding whose prompt snippet has been cleared is capped. A finding recorded before this tracking existed, or by an AIControls instance that predates it, is capped at medium until a background job qualifies it, and shows as partial with the reason "evidence qualification pending"; this clears on its own. The job qualifies a bounded number of findings every few minutes, so a large history takes longer. For a sequence finding the conditions recorded with the finding are unavailable evidence (including retained arguments that cannot be decoded), truncated or dropped retained text, text too long to show in full, and a step whose request content was not retained. The evidence view and AI Analyst can cap further only for conditions found when the evidence is read: a referenced capture that has expired or is still pending, and, in a view scoped to a user, session, agent or workload, a truncated step that the scope excludes. A shortened finding summary, a response that was never recorded, and Analyst prompt limits such as cropped text or a skipped duplicate capture are not evidence gaps and do not lower severity.
Data classification is recorded only on gateway calls, from the MCP server's or tool's classification. Findings from other sources have none, so classification never raises or lowers them. AIControls records no credential-access signal on gateway calls. Credential access reaches high through a matched attack pattern, such as Credential file opened → Ungoverned egress. Severity changes apply to findings as they are read, so existing findings are re-ranked without a migration.
In Security → Activity → Security, select Correlated findings to open retained evidence for a finding. The existing Events view keeps its filters, columns, and event links.
A sequence finding includes its recorded evidence steps. Other detections and control events remain individual findings unless a stored reference proves a relationship. The evidence drawer distinguishes request verdicts, response dispositions, execution outcomes, and the latest effective Judge assessment. An assessment can include a deterministic safety guard; it is separate from the gateway decision. Claimed Judge attempts are separate from provider calls and their recorded usage.
Each finding row, including the findings listed in an incident's drawer, carries its own evidence status instead of a page-level banner: Evidence readable, Evidence partial, or Signal (evidence unavailable). A sequence finding is readable when its stored steps still hold request or response content, kernel observations or an aggregate summary, and partial when only some steps do. In a view scoped to a user, session, agent or workload, kernel observations do not count, because that scope cannot show them. When none do, because no steps were stored, the stored evidence cannot be decoded, or every step is empty, the finding is labelled Signal (evidence unavailable) with the reason on hover and in the drawer, and its severity is never shown as high: a recorded high or critical severity is shown as medium. The severity filter, Home attention candidate selection and incident ordering apply the same cap for every condition recorded with the finding (listed above), from a readability result saved with each sequence finding when it is recorded, so no page of results is read to decide it. Findings recorded by an earlier version, and every finding after an upgrade that changes which conditions count, are shown capped, as Evidence partial with the reason evidence_qualification_pending, until the sequence sweep has checked them, which it does in batches on its normal schedule. A finding with truncated retained text shows as Evidence partial with the reason retained_step_content_truncated, one with text cropped for display shows retained_content_incomplete, and one with a step whose request content was not retained shows some_steps_unreadable; all three are capped. A step that holds only an aggregate summary retains no arguments by design and counts as readable. Retained step arguments are bounded to 1 KiB per step; when they exceed it, long values are shortened so the retained arguments stay readable and the omitted byte count is shown; a finding with shortened arguments is capped as described above. In a view scoped to a user, session, agent or workload, control outcomes are withheld and the finding says so, because the retained steps cannot be proven in that scope. Findings recorded before this change that kept a cut-off argument prefix show that prefix as truncated content rather than as a retrieval error.
The Control outcomes section lists, for each step, the policy that decided it and the decision (Allowed, Denied, Approval required, or Response blocked) recorded when the call happened, so it stays visible after the gateway event is pruned. Findings recorded before this change have no stored decision or policy for their steps, so those steps show no control outcome rather than a guess.
Unavailable content and unsupported scope are shown explicitly. A session link supplies related context, not proof that a particular prompt triggered a detection. Runtime records describe their latest recorded series and do not supply plaintext request or response bodies. Aggregate read evidence preserves its recorded count and byte total; its first and latest references do not stand in for every contributing request.
A cluster-qualified identity filter matches recorded gateway attribution, stored baseline identity keys, and identity-level sequence subjects. Gateway evidence requires recorded cluster-qualified attribution; a matching display name or clusterless history is insufficient. Baselines retain their identity key without separate attribution provenance, so a matching baseline key does not independently verify cluster attribution. Sequence findings match their recorded detection subject, which does not identify a distinct execution agent. Coverage notices describe these limits and unsupported sources.
Evidence limits use readable explanations, such as The referenced Gateway event is not retained or The workload cluster was not recorded. Identical notices for the same source reference appear once; separate references and availability states remain distinct. Expand Source reads and recorded metadata to see which sources were queried, whether each read succeeded, and recorded retention information. A successful read does not establish ingestion freshness: unknown remains explicit when no durable watermark is recorded. Source-qualified references such as audit:42 stay visible for precise correlation.
Findings are ordered by their source timestamp. Finding and incident tables, evidence, and review timestamps display your local timezone, including the timezone label. Links use UTC instants in a whole-second range with an exclusive end. Pagination preserves the selected range, but results remain live as source records change. Sequence timestamps use first detection; runtime and MCP inventory timestamps use the latest recorded observation. Unregistered workload daily rollups use their first-seen timestamp. Select the Unregistered workloads source and the unregistered workload blocked or unregistered workload shadowed Type filters to inspect these metadata-only findings. The rollup records the calling agent when one was captured, and the Actor column shows it; the rollup does not identify a particular user or request. Durable drift evidence is not yet supported by this view.
Select Open global source to inspect the original record. This explicitly leaves the finding's presentation scope; browser Back restores it. Capture references are retrieved only when you open them, so missing or expired payloads remain visible as retrieval errors. No AI generation runs when this view opens.
Home dashboard
The Home dashboard opens in Security by default. Recent Findings shows recorded finding groups, priority-review eligibility, follow-up, and recorded review dispositions for a frozen 24-hour window displayed in your local time. Up to three findings retain the server's priority order. Ask Analyst opens analysis for the top finding; hover or focus the action to see its full title. Review evidence opens the selected correlated finding; Review all correlated findings opens the full list with the same exact scope and exclusive end bound. Refresh snapshot updates the window and its queries together.
Outcomes distinguish request denials, response blocks, historical holds, and the latest runtime series block. These are recorded outcomes, not a count of attacks prevented or current pending approvals. The briefing uses metadata; request and response evidence is fetched from the finding details. Expand Sources and evidence limits to inspect supported-source query coverage. Successful source queries do not establish telemetry freshness or complete threat visibility.
A failed refresh retains a visibly labeled earlier snapshot from the same scope. Access denial or expired authentication hides cached findings. The briefing does not automatically call the Analyst and does not approximate activity since your last login.
Security briefing
Select Security briefing on the Home dashboard to read what happened in the displayed window and what to do about it. AIControls computes the briefing from recorded data; it needs no model and never calls the AI Analyst. Administrators and viewers can open it.
- Verdict. One line, such as "3 things need you. 137 findings are probably noise you can clear." Below it, the count of open incidents, how many are unassigned, and the split by severity. When no incident is open, the briefing says so.
- Needs attention. Open incidents at medium severity or higher, ranked by the calibrated severity. An incident whose matches the Judge has all finished on and marked benign sorts last and is tagged likely benign. Each item has a plain-English title, a one-line reason, the actor, the finding count, and one primary action: Open incident, or Open finding when a control already blocked the activity. The briefing lists five items and counts the rest.
- Clear the noise. Patterns that are probably not attacks. A pattern appears here when at least three of its open incidents are ones whose matches the Judge has all finished on and marked benign, shown as "40 of 40 judged benign". The counts are each incident's own matches, so an incident with a confirmed, pending or failed verdict stays in Needs attention. A group of baseline alerts also appears when service accounts account for at least half of the window's baseline incidents below medium severity, or one user accounts for most of them. A baseline incident at medium or above stays in Needs attention, and the briefing forms no noise groups when it could not read every open incident. Review N incidents opens the incidents list filtered to that pattern, where you can triage them. The list can include incidents of the same pattern that the briefing keeps in Needs attention, so check each one before you resolve it. When more groups qualify than the briefing lists, it says how many are not listed.
- What changed. Findings, gateway requests and denied requests compared with the previous equal window, each with a one-sentence explanation computed from the data: the pattern that accounts for most of a change in findings, the users and rules behind a change in denials, and the percentage change in traffic. The briefing also counts the policy changes recorded in the window and links to the configuration audit for the same window. It says there were none only when the audit was queried. A window that has not ended is not compared with the previous one, and the briefing says so.
- Did controls hold? Denied requests, blocked responses and requests held for approval, the users and rules behind the most denials, and the status of runtime (kernel) controls. On a hosted workspace, where runtime controls are not part of the deployment, the briefing says so as a neutral line. On a deployment that expects runtime controls but has none running, it shows a warning.
- Coverage. One collapsed line, shown only when a limit changes a conclusion above, for example when a source could not be read or only the highest-severity incidents were read. The briefing never repeats a warning for the same limit.
Incidents with an exemption on their attack pattern are not listed. The briefing reads at most 1,000 open incidents per window, highest severity first. Ask Analyst about this window at the bottom opens the optional AI Analyst for the same window. If the model call fails, the computed briefing stays on screen.
The activity preview shows security, gateway, session lifecycle, and configuration records across all identities and workloads for a frozen 24-hour range displayed in your local time. Select a count to open Security → Activity with the same category and range. Refresh snapshot updates the range and counts together. Dashboard timestamps, trend labels, and briefing times use your browser’s local timezone; shared dashboard links preserve the selected time range. Requests denied opens Gateway activity filtered to denied requests in that range, including the exact agent filter when present and the full final second of the selected range. If Gateway cannot represent the selected user, workload, or execution-session scope, the card explains the limitation instead of opening broader activity. Gateway’s native denial list is broader than the dashboard request-stage count: it can include response-stage or upstream failures and other request types. The card identifies that difference.
These are source-record counts, not unique attacks, correlated findings, or attacks prevented. Categories can overlap, and missing telemetry does not establish that activity was safe. Expand Sources and range details for timestamp and availability limitations. An unavailable or access-denied request appears explicitly rather than as zero activity.
The separate cost card shows global spend for a rolling past month. Select Cost to use the existing cost dashboard; your browser remembers the display choice when browser storage is available. In the cost dashboard's Team Activity band, Active users and Active agents count the users and agents that made a request in the selected window (last 24 hours, 7 days, or 30 days), not every identity ever seen. See Cost Overview. Health, Inventory, and AI Features usage remain available through their existing pages.
Risk scores
Navigate to Security → Posture for an org-wide risk summary. The page shows computed risk scores per agent and developer, derived from violation rate, HITL rate, blast radius, and elevated-tool breadth over the last 7 days — see Risk scores for what each signal means. Use it to identify which identities warrant closer review and to track posture trends over time.
Posture is informed by behavioral baselines. AIControls builds a per-identity baseline (normal call rate, typical token volume, common tools) over time. Deviations from that baseline surface in Security Events and raise the identity's risk score.
Detections
Navigate to Security Events to view session anomalies and baseline alerts in one place. Session anomalies report supported session thresholds and waste signals; see Detections for current producer coverage and limitations. Baseline alerts report deviations from learned behavior. Policy, budget, and HITL notifications are separate event sources. Budget and cost alerts (session_budget_warning, session_cost_alert) and gateway configuration errors are not listed there; they are routed to Cost and Health. See Events routed elsewhere.
Detections is covered in depth on its own page — session anomaly detection, thresholds, auto-pause, tuning for agentic workloads, baseline alerts, and delivery channels.
Compliance
The Compliance page maps enabled policy annotations to supported control catalogs, including the NIST AI Risk Management Framework (AI RMF). Its configured coverage and exported report describe a configuration snapshot; they do not establish historical enforcement, operating effectiveness, or whole-control compliance. See Compliance for evidence limitations.
Exceptions
Navigate to Security → Approvals → Rules to manage standing policy-exception rules. A rule allows a specific identity or group to bypass one or more policies for a defined period — useful for contractor onboarding, one-off experiments, or incident response.
A developer can also request a one-off exception, which lands in Security → Approvals → Pending for an admin to approve or deny. Each approved exception records who granted it, the justification, and an expiry time, and appears as an active grant in Security → Approvals → Granted — where an admin can revoke it early. Expired and revoked grants move to Security → Approvals → History, alongside the audit log.
Approvals
Navigate to Security → Approvals for the human-in-the-loop (HITL) queue. When a policy routes a request for approval rather than denying it outright, the request lands here. Admins can approve or deny each request; the developer's session is held until a decision is made or the request times out.
HITL is configured per policy rule — set the enforcement mode to approval in any ValidatingPolicy to route matching requests here instead of blocking them outright. This is useful for high-risk but infrequent operations (production deployments, credential access) where context matters.
Approval requests expire after a configurable timeout — 30 minutes for a held MCP tool call, 5 minutes for a held LLM request. If no admin acts within the window, the request is auto-denied and the developer receives a timeout message. See Human-in-the-loop.
The Approvals card on the Posture page also reports decision time — the p50/p90 time from request to decision, computed only over requests an admin has already decided. This is a different measurement from the "avg wait" figure shown for the pending queue: avg wait is how long currently pending requests have been sitting, which keeps changing as time passes; decision time is a fixed, backward-looking measurement of how fast your team actually responds once a request lands. A slow decision time despite a low pending count usually means requests are getting decided, just not quickly — worth investigating separately from queue depth.
Quiet confidence
The stat row also surfaces Quiet confidence — the percentage of call dispositions over the selected period that resolved with zero human involvement (Allow, Mutated, Cache Hit, Audit, Allowed by Exception), out of all dispositions including the human-involved ones (Deny — which also covers egress denials — Warn Approve, Warn Ask). A high quiet-confidence score means your policies are doing the enforcement work autonomously; a falling score means more calls are landing on a human queue — check Approvals and Security Events for the cause. See Decision Types for the exact set definitions.
Kubernetes workload scorecards
The Kubernetes workload scorecard presents a Kyverno evidence baseline, grouped by policy category, alongside an optional AI Posture Assessment. The baseline counts pass, fail, warn, error, and skipped report results. Unknown results and categories with zero results do not establish that a workload passed.
The optional AI Analyst assessment summarizes and prioritizes evidence using the ratings strong, adequate, weak, or critical. It includes confidence, model, prompt version, computation time, and findings linked to specific evidence. Available configuration and collection gaps can support an assessment even without report findings. Missing reports, unavailable collection, and installed policies are not evidence that a workload passed.
The assessment is advisory: it cannot change admission, routing, containment, component risk scores, or workload verification. Generated ratings and findings are not inputs to policy evaluation. Kyverno verdicts and their baseline counts remain independent of the narrative.
A missing, disabled, failed, or rejected assessment appears as Not assessed. An expired assessment or one whose evidence or configuration has changed appears as Stale assessment. Neither state indicates a clean workload. Evidence gaps remain visible independently of the rating.
Report citations show the policy, rule, result, severity, and message; if the current report no longer contains the fact, the panel says so. Assessment context evidence is a separate stored snapshot of availability, deployed policies, workload configuration, runtime observations, or declarations. Its citations show the evidence type, details, and observation time without presenting a Kyverno verdict or fetching a report. Stale context is labeled, and missing context stays explicitly unavailable.
See Kubernetes Posture for availability and configuration.
See also
Home security overview
Select Customize on the Security overview to choose which cards appear and change their order. Use the checkboxes and Move up / Move down buttons, then select Save layout. Reset to recommended stages the default cards; it takes effect when you save. Cancel leaves your saved layout unchanged.
Choose a Preset (Security, Platform, or Engineering leader) to start from a ready-made card order. Each preset sets the default card order and the view the Overview opens on: Security and Platform open on Security, and Engineering leader opens on Cost. A preset is a starting point, not a separate dashboard: after you choose one, you can still move, hide, and show cards, and your own order is what is saved. Presets are picked by name; they are not inferred from your role. If you are an administrator and have not saved a layout, the Overview uses the Security order. Your saved layout is stored with your account, and your chosen preset and view are remembered in this browser for your account.
A card you do not have access to is not shown at all, rather than appearing disabled or empty.
The layout belongs to your account in the current workspace and is available when you sign in from another device. If another session changes it while you are editing, your draft is preserved and Reload saved loads the current saved layout. Layout changes do not change permissions or the separate Cost dashboard.
Hidden cards do not start their independent data requests. Security cards share one snapshot, so hiding one card does not remove its fields from that shared read. The snapshot timestamp and coverage qualifications remain visible. If preferences cannot be loaded, you can retry or select Use recommended temporarily; customization remains disabled until your saved layout is available. Read-only environments show the saved layout but do not allow changes.
See Dashboard Snapshots for freshness windows, cached results, As of timestamps, and refresh controls.
Home summarizes retained security activity for the selected Last 24 hours or Last 7 days window: finding groups, gateway call records, recorded identities, a trend chart and recorded protection outcomes. Comparisons use the adjacent equal-length window. Missing previous observations show No prior comparison or Not enough data to compare, and failed comparison reads show Comparison couldn’t load; retention and collection gaps qualify the figures. Gateway call records may include retry attempts.
Observed exposure identifies gateway-observed agents absent from Inventory, exact workloads absent from current registrations, and MCP servers/tools absent from the current server registry. Registration alone does not prove enforcement. These counts do not cover all runtime-only traffic or establish when a registration changed; incomplete attribution remains visible.
Three ranked finding actions preserve the displayed time window when opening evidence or Ask Analyst. Recorded denial, response blocking/redaction and historical approval requirements are separate outcomes; historical holds are not the current approval queue. A failed refresh labels retained results as an earlier snapshot. Since-prior-visit summaries and personal widget layouts are separate follow-ups.