Blast radius is the abstraction, not intent

A vocabulary has been forming in identity security around the word "intent." The pitch goes: legacy identity tools care about who you are; modern identity security cares about what you're trying to do. Authentication says "Sara is allowed in"; intent analytics says "this Sara is acting like an attacker." The word does useful work in talks. It does less work in production.

This post argues that "intent" is the wrong primitive to organize identity security around, and that the right primitive is blast radius — the structurally bounded set of damage any single compromised identity could cause if turned against the org. Blast radius is computable from data the SOC already has. Intent is, in any rigorous sense, not.

The intent framing, fairly stated

The strongest version of the intent argument runs like this: most authentication systems verify identity (who) but not action (what). Once Sara is in, she can do anything Sara is permitted to do. If an attacker is operating Sara's account, the attacker can do anything Sara is permitted to do. The system has no way to distinguish "Sara, doing her job" from "attacker, using Sara's privileges."

The intent-analytics solution is to monitor what the authenticated session does and score the actions against a behavioral baseline. Sara doesn't usually access the financial-reporting database; Sara doesn't usually export 500 documents in an hour; Sara doesn't usually authenticate at 03:00 from a residential IP. Each of those actions has an "intent score." When the score crosses a threshold, intervention follows.

This framing is intuitively appealing, particularly in vendor demos, because it personifies the system: the AI is figuring out what the user is trying to do. It also has real precedent — UEBA tools have been doing variants of this since the early 2010s.

Why the intent abstraction breaks under load

Three problems become obvious once intent-as-a-product-category meets actual SOC operations.

1. Intent is unobservable; what's observable is action. "Sara intends to exfiltrate data" is a fact about Sara's mental state. It is never observed. What is observed is a sequence of API calls. The leap from "Sara called the export API 500 times" to "Sara intends to exfiltrate" is an inference, often a wrong one. Intent-analytics products tend to elide this distinction in marketing language and pay for it in operations: a SOC analyst forced to defend a containment decision cannot say "the AI determined the user's intent." They have to say what the user did. The intent vocabulary obscures the inference chain that the analyst will need to reconstruct anyway.

2. Behavioral baselines decay fast in actual organizations. The intent score is implicitly the answer to "how unusual is this action for this user?" Calculating that requires a stable baseline of what's usual. Real organizations are not stable. People change roles. Teams reorganize. A new project lights up access patterns that didn't exist before. The half-life of a behavioral baseline in a fast-moving company is measured in weeks. UEBA tools that promise to "learn what's normal" routinely surface so many false positives during periods of organizational change that they get tuned down to near-uselessness within a year of deployment.

3. The intent score doesn't tell the analyst what to do. A score of 0.92 fires an alert. Now what? The analyst has to investigate, which means: who is this user, what do they have access to, what could they reach from where they are now, what would be the cost of containment versus the cost of being wrong? The intent score answers none of these questions. It tells the analyst the user is anomalous; it doesn't tell the analyst whether the anomaly matters.

The blast-radius framing

A different abstraction: forget what the user "intends." Compute, for every authenticated identity in the environment, the set of crown-jewel assets reachable through that identity's permissions in K hops, weighted by recency and structural exposure. Call this the identity's blast radius.

Blast radius is observable. It is a function of the identity-permission-asset graph, which exists as a real artifact in the SOC's environment. It does not require modeling user mental states. It does not require behavioral baselines. It does not decay with organizational change — when the permission graph changes, the blast radius recomputes automatically.

Most usefully, blast radius answers the question the analyst actually has to answer at 03:00 when the alert fires: if this identity is compromised, what's the worst case? If the blast radius is small (the user can reach low-value assets through three hops of unused-in-the-last-90-days role grants), the analyst defers to morning. If the blast radius is large (two hops to the financial reporting database, one hop to the production payments queue), the analyst pages the on-call and revokes the session.

Where intent-style signal still lives, properly framed

We are not arguing that behavioral signal is useless. Anomalous action sequences are real signal. The argument is about how that signal should be combined with structural signal to produce decisions.

The right composition: blast radius is the prior; behavioral signal is the trigger. An identity with a small blast radius can do a lot of anomalous things before it justifies a high-cost containment, because the worst-case damage is bounded. An identity with a large blast radius justifies investigation on relatively weak behavioral signal, because the worst-case damage is severe.

Concretely, the score that should drive SOC priority is something like:

priority = behavioral_anomaly_score × blast_radius_score

Either factor near zero kills the priority. Both factors high produces the alerts that warrant 03:00 paging. This is not a deep insight; it's just the basic Bayesian framing the intent-only vendors tend to skip.

What this means for product surface area

Three product implications fall out of taking blast radius as the primary abstraction.

1. Blast radius is computed continuously, not on alert. Every identity in the environment has a blast radius score, recomputed whenever the underlying permission graph changes. The score is queryable in the product (sortable column on the identity list, dashboard widget for "highest-blast-radius identities"), reported to GRC as a continuous risk metric, and exposed to other detection tools as a contextual input. It is not just an investigation-time computation.

2. Blast radius reduction is a first-class workflow. If an identity has a high blast radius, the product has to be able to tell the customer which permission removals would reduce it the most. This is the diffusion-gradient remediation problem — given the graph and the crown-jewel set, which single-edge removals reduce total exposure the most? The answer is operational guidance, ranked by impact, that becomes the customer's quarterly identity-hygiene roadmap.

3. Containment decisions are instrumented with blast radius context. When an analyst takes a containment action ("revoke session," "reset password," "disable account"), the product records the blast radius at the time of the action and the blast radius after. Over time, this becomes a feedback loop: containment actions that materially reduced blast radius are validated; actions that didn't suggest the policy is wrong (the revoked session wasn't the bottleneck, or the underlying permission grants need to change).

Where the intent vocabulary is fine

Some uses of "intent" are genuinely useful and we are not arguing against them.

• "Intent-based access control" in the network security sense (Cisco's framing) — declaring policy in terms of high-level outcomes rather than low-level rules — is a useful pattern in network architecture. Different category of intent.
• "User intent" in the search and recommendation sense — what is the user trying to find or do — is well-defined and useful in product design. Different category again.
• "Intent" as a casual shorthand for "behavioral anomaly score" is fine in conversation as long as the product surface doesn't pretend it's measuring a mental state.

The argument here is narrower: as the organizing primitive for an identity security product, "intent" is the wrong abstraction. Blast radius is right.

Closing

Vendor categories often cluster around vocabulary that sounds smarter than it operates. "Intent" is the latest example in identity security. The word implies the vendor is doing something deeper than they actually are; the product underneath is usually a behavioral baseline with the usual drift problems and the usual lack of operational guidance.

The substrate that does the work is the identity-permission-asset graph. The abstraction the analyst can reason with under pressure is the blast radius computed on that graph. The behavioral signal is real and belongs in the system, but it's the trigger, not the prior.

Build the graph. Compute blast radius continuously. Use behavioral anomalies as triggers conditional on blast radius being non-trivial. The vocabulary sorts itself out from there, and so does the product surface.