# Risks A **risk** in Axiad Mesh is a specific, evidenced condition attached to something Mesh watches — an identity, an account, a credential, a non-human identity, an AI agent, or a cryptographic asset. Every risk names the condition, carries a severity, explains why it was raised, and suggests how to fix it. Risks are what the rest of the product is built from: they combine into [risk scores](./risk-scoring.md), translate into financial terms through [risk quantification](./risk-quantification.md), and become work through [remediation](./remediation.md). This page is the map of what Mesh detects and how those detections are organized. ## What Mesh assesses Mesh raises risks against every class of identity and asset it correlates: - **Human identities** — your employees and contractors, correlated across every connected system, together with their accounts and credentials. - **Non-human identities (NHIs)** — the machine actors that hold access: service accounts, service principals, managed identities, workload identities, OAuth apps, devices and IoT, pipeline runners, and RPA and automation bots. In most environments these outnumber people many times over. - **AI agents** — a first-class kind of non-human identity: the autonomous agents operating in your tenant, including the ones nobody told you about. - **Cryptographic assets** — certificates, keys, and the software and machines that use them, assessed for policy compliance and post-quantum readiness. Assets are not identities: an NHI is an actor that holds access, while a cryptographic asset is material an actor uses. Mesh assesses both, with risks appropriate to each. Because Mesh [correlates](./identities.md) all of these before assessing them, a risk on one object is visible from every object it touches — that is what makes blast radius measurable rather than anecdotal. ## The three layers of risk Not every risk answers the same kind of question, so Mesh doesn't force them into one shape. Findings are organized into three layers, and each finding is labeled with the layer it belongs to: | Layer | The question it answers | How it's measured | | --- | --- | --- | | **Inventory hygiene** | What is broken, missing, or weak about this identity or asset? | Discrete findings, each with a severity. Present until the underlying condition is fixed. | | **Policy compliance** | Does this comply with the policies and frameworks my organization has adopted? | Continuous evaluation against [policies](./policies.md), expressed as compliance findings, percentages, and bands. | | **Behavioral correlation** | What patterns across systems, identities, and time reveal something no single source can see? | Signals that carry a **confidence** alongside their severity, and that decay when the evidence isn't seen again. | The layers stay separate deliberately. A dormant account, a deprecated algorithm, and a suspicious cross-system pattern are three different kinds of fact — collapsing them into a single number would hide exactly the distinctions an analyst needs. Where a combined view helps, the [risk score](./risk-scoring.md) provides it; where it doesn't, Mesh shows each layer on its own terms. ## Human identity risks **Lifecycle and offboarding.** The classic identity failure is the account that stayed active after the person left. Mesh compares status across every system a person is correlated into and raises **incomplete offboarding** findings — for employees and for contractors, and at different severities depending on whether the leftover account is still active or merely never cleaned up. **Account hygiene.** Dormant and stale accounts that haven't signed in for a long time; accounts missing identifying information in systems that support it; identities without a manager and system accounts without a sponsor — an unowned account is one nobody will review or deprovision. A weakly correlated account is flagged too, because an association Mesh can't confirm hides risk; see [profiling gaps](./identities.md#profiling-gaps). **Credential strength.** Mesh distinguishes *having* a phishable credential, *using* one, and — most severe — using one when a stronger MFA credential is already available, because that last case is a fixable behavior rather than a missing capability. **Breach exposure.** When an identity's email or principal appears in a publicly known third-party breach, Mesh raises a breach-exposure finding, at a higher severity when the breached data includes sensitive material such as passwords. If the breach could expose reused passwords, the finding fans out to the identity's credentials as a **possible password reuse** risk — a blast radius, not just a flag. Breach findings decay over time as the exposure ages. **Inherited security context.** Findings from the security tools you connect — device compliance state, vulnerability findings, detections, incidents, and authentication anomalies — attach to the identities and assets they concern, so a compromised endpoint or a failing device configuration shows up in the risk picture of the people who use it. ## Non-human identity risks Non-human identities fail differently from people, and Mesh scores for it: - **No owner** — the most consequential NHI condition. An unowned service account is one nobody will rotate, review, or retire, so ownership gaps are flagged wherever they appear: a system account without a sponsor, an NHI without an accountable owner, an owner who has since been disabled. - **Dormant** — an NHI that is still enabled but hasn't been used in a long time: standing access with no active purpose. This applies across NHI kinds, from service accounts to devices. - **Lifecycle drift** — service accounts often live inside your user populations, and Mesh detects them there: an account that looks like a system user but is uncorrelated, unsupervised, or still active past its purpose gets the same lifecycle scrutiny as a person's account. The certificates, keys, and secrets that NHIs authenticate with are **cryptographic assets**, and their conditions — expiry, weak algorithms, policy violations — are assessed under [cryptographic and post-quantum risks](#cryptographic-and-post-quantum-risks) below, then reflected back onto the identities that depend on them through correlation. ## AI agent risks Agents participate in both hygiene and behavioral layers. **Agent hygiene.** Every agent should have an accountable owner and a live definition. Mesh raises findings for agents without an owner, agents whose blueprint — the definition they were created from — is orphaned, agents whose owner account has been disabled, and agents that are disabled or dormant but never cleaned up. **Shadow AI detection.** The agents you don't know about rarely announce themselves in any single system, so Mesh detects them by correlation. It watches for AI-shaped evidence across your connected sources: OAuth grants to agent-orchestration platforms and AI apps, grants approved by administrators for personal apps, AI-related grants by the same person across several providers, unusually broad scope grants, unverified publishers, long-lived refresh tokens, sudden bursts of new grants, and grants that stay active but unused. Individually, each of those signals is weak. Mesh accumulates them per identity, and only when the combined evidence crosses a threshold does it raise a **behavioral correlation** finding — with a confidence value between 0 and 1 shown next to the severity, never blended into it. Evidence that isn't observed again decays, so a stale signal fades instead of lingering forever. When independent sources corroborate each other, Mesh promotes the evidence into a discovered agent — a candidate that becomes confirmed on multiple independent sources, and that you can confirm or reject yourself. The result is an agent inventory that includes the agents nobody registered, plus a per-identity view of shadow AI exposure summarizing the strongest signals around each person. ## Cryptographic and post-quantum risks Cryptographic risk in Mesh is driven by [policies](./policies.md): every algorithm in use is classified as preferred, acceptable, deprecated, or prohibited, and violations raise policy-based findings such as the **PQC noncompliant** tag. Two behaviors are worth knowing: - **Early warning.** When an algorithm is scheduled to become noncompliant at a future deadline, Mesh raises an *upcoming* finding at reduced severity — lead time to migrate before the violation lands. - **Unknowns are findings.** An asset Mesh can't fully evaluate gets an insufficient-data finding rather than a silent pass, and quantum-readiness views report **vulnerable**, **non-vulnerable**, and **unknown** as three distinct states. Alongside policy violations, assets carry their own hygiene findings: expiring, expired, and self-signed certificates; weak algorithms; assets with no owner; and assets with no linked machine or software record — because cryptographic material nobody governs is a liability even before it breaks a policy. Beyond individual algorithm violations, Mesh assesses each cryptographic asset against six composite risk categories, each backed by control-level evidence spanning key lifecycle, algorithm strength, certificate hygiene, access, governance, detection, dependencies, and regulatory mappings: | Risk category | What it captures | | --- | --- | | **Key compromise** | Exposure of key material — weak protection, mishandled access, or missing lifecycle controls around a key. | | **Algorithm obsolescence** | Reliance on algorithms that are weakened, deprecated, or not quantum-resistant, and the migration liability that follows. | | **Certificate or key expiry outage** | Availability risk from certificates and keys that can expire without renewal in place. | | **Regulatory noncompliance** | Cryptography that falls short of the regulatory frameworks your organization is held to. | | **Supply chain crypto dependency** | Cryptographic weaknesses inherited from third-party components and vendors. | | **Shadow or unmanaged crypto** | Cryptographic material that exists outside governance — unowned, untracked, or unassessed. | How compliance percentages, frameworks, and migration deadlines work is covered in [Policies](./policies.md); tracking the migration itself as an initiative is what [Programs](./programs.md) are for. ## Severity, confidence, and decay Every finding carries a **severity** — the ranked low-to-critical scale described in [Risk scoring](./risk-scoring.md) — expressing how bad the condition is if it's real. Behavioral correlation findings additionally carry a **confidence** expressing how sure Mesh is that the signal is real; the two are always displayed as separate facts, because an analyst weighs them differently. Findings also differ in how they end. Condition-based findings resolve on their own when the underlying condition clears — an offboarded account gets disabled, a certificate is reissued, an owner is assigned — on the next collection cycle. Evidence-based findings, such as breach exposure and shadow AI signals, decay over time when the evidence isn't re-observed. ## From risks to action Risks are the raw material; the rest of Mesh turns them into decisions: - [Risk scoring](./risk-scoring.md) combines them into comparable 1–100 scores with blast radius. - [Risk quantification](./risk-quantification.md) expresses them as annual loss expectancy in dollars, so priorities rank by impact. - [Remediation](./remediation.md) turns a finding into an assigned, tracked fix. - [Programs](./programs.md) measure how a whole class of risk trends as an organization-wide initiative. ## Related concepts - [Risk scoring](./risk-scoring.md) — how findings combine into the 1–100 score and roll up across the organization. - [Risk quantification](./risk-quantification.md) — the FAIR methodology that puts a dollar figure on risk. - [Policies](./policies.md) — the rule sets behind compliance findings, including post-quantum readiness. - [Identities](./identities.md) — the correlation that makes cross-system risk visible. - [Remediation](./remediation.md) — how risks get fixed and verified.