Why Visibility Alone Is Not ARISE, And What Runtime Enforcement Actually Requires
I have spent a good part of the last few years arguing that identity observability is the missing layer. I still believe that. This post is about where the argument stops.
SACR's ARISE framework draws a line I want to sit with rather than talk around. On its Agentic Control Depth scale, ACD 1 is static discovery and inventory. ACD 2 is post-event telemetry and alerting. ACD 4, the level SACR names as the production floor for agents touching sensitive data, is inline intervention before the action completes.
Everything I would call pure observability tops out at ACD 2.
That is not a criticism of observability, but a statement about what observability is for. A perfect view of your agent estate, complete inventory, clean baselines, full behavioral analytics, correlated chains rather than isolated events, still does not stop a single action. It tells you, with excellent fidelity, what you failed to stop.
So here is the bar, stated plainly, and AuthMind should be measured against it the same as anyone: if a product cannot interrupt an action in progress, it is not completing ARISE. Give visibility its due first
Before the critique, the honest accounting, because the reaction to this post in some quarters will be that observability is a dashboard and dashboards are decoration. That is wrong, and enforcement built on a blind estate fails in worse ways than no enforcement at all.
You cannot govern what you have not counted. In our own customer environments roughly 65% of the AI and automation identities we surface are unmanaged, and about half were not on the customer's inventory at all before we looked. An enforcement policy applied to the agents you know about, in an estate where half of them are undocumented, produces a compliance artifact and a false sense of coverage.
You cannot define abnormal without normal. Intent drift detection, the thing that makes layer-two analysis worth anything, is a statement about deviation from a baseline. No baseline, no drift, just noise with a confidence score attached.
You cannot enforce selectively without behavioral context. This is the objection that kills inline controls in production, and it is a real one. Enforcement driven by static rules alone blocks legitimate work, generates escalations, and gets switched off within a quarter. Observability is what earns enforcement the right to be selective.
And you cannot answer a regulator, a board, or an incident responder without evidence. Reconstructing which agent did what, under whose delegated authority, with which credential, is an observability function. Enforcement stops the action. Observability is how you explain it afterward, and in a regulated industry that second job is not optional.
Gartner's Innovation Insight on Identity Visibility and Intelligence Platforms, published 24 August 2026, makes essentially this case as a category in its own right. IVIP aggregates, normalizes, and analyzes identities, their access, policies, and IAM control configurations across cloud, on-premises, and SaaS. That is real work and it is foundational.
Foundational is the operative word. A foundation is not a building.
Where the dashboard stops
Three failures, and they compound.
The action already completed. This one is arithmetic, not opinion. CrowdStrike puts the fastest observed breakout at 27 seconds. Mandiant found the median hand-off between an initial access broker and the crew that buys from them collapsed to 22 seconds, from more than eight hours in 2022. At Hugging Face, impersonating one over-scoped connector credential produced cluster admin on two clusters within one second. There is no alert pipeline that beats one second, and there is no roadmap item that will produce one.
The alert was correct and nobody acted on it. This is the failure most people underrate, and Hugging Face published it about themselves, which took some spine. Their LLM-based triage stack correlated ambiguous signals across runtime analysis and SIEM into a coherent attack signal, then failed to rank it critical, so on-call never got paged. Read that again. The analytics worked. The chain was assembled. A severity model looked at it and shrugged, because every constituent event was a pod reading its own service account token or an EC2 role authenticating to EKS, which is to say a Tuesday. Better analytics do not fix this. Ranking is a human judgment encoded once and applied at machine scale, and it was wrong in the only direction that mattered.
Nothing was in the path to say no. Even with a correct alert, correctly ranked, correctly paged, the response still travels through queue, triage, escalation, and change approval before anything happens to the credential. At 2 a.m. that path has a person in it, and the person needs to wake up.
Stack those three and you get the shape of a visibility-only program. It sees everything, ranks some of it, and changes none of it. That program will produce an outstanding postmortem. I have read several. The best ones are written by teams whose telemetry was excellent.
What runtime enforcement actually requires
This is the part that does not fit on a slide, which is why it rarely makes it into a vendor conversation. Six requirements. Each is a real engineering commitment, and a product missing any one of them is doing something else.
A position in the decision path. The control has to sit somewhere the action passes through and waits: an identity provider issuing the token, a gateway fronting the tool call, an MCP server brokering access, a sidecar in the mesh. Consuming a log stream is not a position in the path. A log arrives after the decision was made, by definition. This sounds obvious written down, and it is the single most common thing products get quietly wrong.
A latency budget you can defend. Every inline control taxes legitimate work. Ask for measured p99 in milliseconds under production load, not a claim of real-time. My rough field heuristic: under 50ms is invisible, 50 to 200ms is negotiable for high-value actions, past a second you are building an availability incident and scheduling it for a Monday.
A documented failure mode. When the enforcement point cannot reach its policy engine, does the action proceed or halt? Fail-open preserves availability and silently disables your control exactly when something is wrong with your infrastructure, which is also when attacks happen. Fail-closed preserves the control and takes production down with it. There is no correct universal answer, only a decision that must be made deliberately, per action class, and written down before the outage. Most teams discover their default during the outage.
Revocation that propagates. Revoking a credential means nothing if the agent holds a bearer token valid for another 55 minutes. This is the gap between the revocation event and the credential's actual death, and for most OAuth deployments that gap is the full token lifetime. The mechanisms exist: short-lived tokens, OAuth 2.0 Token Exchange for properly scoped delegation, and OpenID Shared Signals and CAEP for pushing revocation to relying parties in near real time. Ask which of these are implemented, and ask for the measured propagation time. This is where I see the widest gap between marketing and behavior.
Delegation chain reconstruction, live. An agent invokes another agent, which calls a tool, on behalf of a user who approved something adjacent three steps earlier. Enforcement needs to evaluate the full chain of authority at decision time, not reassemble it in an investigation. Most platforms can do this forensically. Very few can do it in the path, and the difference is the entire product.
Selective intervention driven by behavior. The verb set matters because blunt enforcement gets turned off. Allow, block, redact, pause, step up authentication, route to a human, reduce scope, revoke, quarantine, terminate. Redact and reduce-scope are the interesting ones: they let the legitimate 95% of an action proceed while removing the part that should not. Products with only allow and block will be disabled by an operations team within a quarter, and the operations team will be right.
The vendor test
Seven questions. They take fifteen minutes and they sort the market faster than any bake-off.
Where does your enforcement point sit in the decision path, and what waits on its answer?
What is your measured p99 intervention latency under production load, in milliseconds?
When your policy engine is unreachable, does the action proceed or halt, and is that configurable per action class?
When I revoke a credential, how long until an agent holding a live token stops being able to use it? Do you implement CAEP or Shared Signals, or am I waiting out the token lifetime?
Can you evaluate a multi-hop delegation chain at decision time, or only reconstruct it afterward?
Which verbs do you support beyond allow and block? Show me redact and scope reduction working.
Show me a blocked action in a live environment, not a recorded demo, and let me read the audit record it produced.
Question four is where most conversations get interesting. Question seven is where they end.
Ask AuthMind the same seven. I would rather you hold every vendor in this category to a standard than take anyone's alignment claim, ours included, as an answer. SACR named AuthMind a representative vendor with broad alignment across all three ARISE layers, one of a small number among the thirteen profiled, and that is a meaningful third-party read. It is still not a substitute for question seven.
There is a second test worth running, on yourself. The eight-vendor architecture is its own failure mode. If discovery comes from one product, behavior from another, and enforcement from a third, the decision latency becomes the sum of three integrations plus whatever your event bus adds. I have watched teams assemble a technically complete ARISE stack whose end-to-end intervention time was slower than the SOC process it replaced. Count the hops before you count the features.
What I would do Immediately
Audit your own claims before you audit anyone else's.
Open your agent security architecture diagram and mark every component with the verb it performs. Detect. Alert. Score. Report. Block. Revoke. Be strict about it. If you cannot find block or revoke anywhere on the page, you have a monitoring architecture with a security budget attached, and that is worth knowing before a vendor tells you.
Measure your revocation propagation this week, because it is the cheapest of these tests and it embarrasses almost everyone. Take a non-production agent, revoke its credential, and time how long until it can no longer act. Not how long until the revocation event appears in a log. How long until the action fails. If that number is measured in tens of minutes because you are waiting out a token lifetime, you have found a problem that no new purchase fixes and that shorter token lifetimes fix this quarter.
Decide fail-open or fail-closed per action class, deliberately, and write it down. Financial transactions and credential issuance probably halt. Read operations against public data probably proceed. Someone has to own that call, and the worst version of this decision is the one your infrastructure makes for you at 3 a.m.
Pick one high-value action class and put a real gate in front of it. Not the whole estate. One class, one gate, measured latency, documented failure mode. Six weeks of that teaches your organization more about enforcement than a year of evaluations, and it gives you a defensible number for the next budget conversation.
And stop counting ACD levels for your pilot. Score production. The pilot is not what will be running when something goes wrong.
The foundation and the building
None of this makes observability the loser in an argument with enforcement. That framing is a vendor's framing, usually one who has enforcement and no discovery, and it produces the other failure mode: a gate in front of the agents you knew about, in an estate where half of them were never written down.
The relationship runs one direction and it is not symmetric. Enforcement without observability is blind, blunt, and switched off within a quarter. Observability without enforcement is accurate, articulate, and too late. The first fails loudly. The second fails in a postmortem, which is why it survives budget cycles longer than it should.
This is the honest reason ARISE is structured as three layers rather than a maturity curve. Deterministic governance draws the boundary. Behavioral analysis earns the right to intervene selectively. Dynamic runtime governance does the intervening. Take any one away and the other two degrade into something you would not buy on purpose.
It is also worth saying plainly what this series is not arguing. None of this is a claim that the fundamentals stopped working. Least privilege, credential hygiene, inventory, segmentation, continuous verification are the same controls they were fifteen years ago, and they are still the ones that matter most. Agents introduced no new defensive principle.
What they did was retire a compensating control nobody wrote down. Every risk acceptance behind an unenumerated service account or an over-scoped automation credential was signed against the assumption that exploitation runs at human speed and a human will notice in time. That was a flawed acceptance when we made it, and it is now demonstrably void.
The gap that was genuinely ours, and the only one that was never a fundamental we skipped, is this: we never built the observability to correlate identity correctly, human or non-human, across the domains those identities actually work in. Everything else on the remediation list is deferred maintenance. This one was a real hole.
AuthMind's own path here ran through observability first, and I am not going to pretend otherwise. Discovery, behavioral baselines, and posture across human, non-human, and agentic identities is where the platform started and it remains the foundation the rest stands on. What changed is that a foundation stopped being sufficient, because the thing being built on top of it now moves in one second. SACR's ARISE report and Gartner's IVIP Innovation Insight, three weeks apart, are two research houses describing the two halves of the same problem.
So the test is simple, and it is the only one I would put in a board deck.
When an agent in your environment takes an action it should not take, does anything you own get a vote while it is happening? Or do you find out later, in a well-formatted report, with excellent fidelity, about a decision nobody was there to make?
Sources
ARISE: Agentic Runtime Identity Security Enforcement, Software Analyst Cyber Research, September 2026
Gartner Innovation Insight: Identity Visibility and Intelligence Platforms, 24 August 2026
M-Trends 2026, Mandiant / Google Cloud
Gartner does not endorse any vendor, product or service depicted in its research publications. Representative Provider and representative vendor designations do not constitute endorsement.
Comments