top of page
Search

What Is ARISE? The New Category Defining Agentic Runtime Identity Security

Ryan Rowcliffe
8 minutes ago
9 min read

An agent holds a valid token, it calls an approved tool. Every individual step in the chain passes authorization, because every individual step was designed to pass. The chain as a whole does something nobody sanctioned, and by the time the alert lands in a queue, the agent finished nineteen minutes ago.


That gap is why Software Analyst Cyber Research named a new category this month. ARISE, Agentic Runtime Identity Security Enforcement, exists to answer one question: should this agent be allowed to take this action, with this tool, credential, data, and delegated authority, for this purpose, right now?


Read it again and notice what is not in it. Not who the agent is. Not what it was provisioned for at onboarding. What it is doing, this second, and whether anything you own can stop it mid-action.


Most organizations cannot answer that question. Most have not even been asked about it yet.


What SACR actually published


The ARISE report came out of Software Analyst Cyber Research in September 2026, authored by Paul Webber and Lawrence Pingree with the SACR research team. They surveyed roughly thirty vendors, sorted them into six market patterns, and profiled thirteen in depth.


The acronym unpacks as Agentic Runtime Identity Security Enforcement. SACR's own shorthand for it is the runtime enforcement layer for agents in motion, and that last phrase is the part doing the work. Not agents at provisioning, not agents at review time. Agents in motion.


Categories get named all the time, and most of them are a vendor's roadmap wearing an analyst's letterhead. This one is different for a specific reason: it starts from a control gap rather than a product. The question at its center is operational, not architectural. You either have something in the path that can say no while the agent is still mid-sequence, or you do not.


There is a second reason to take it seriously. ARISE sits inside a larger frame SACR calls Unified Agentic Defense Platforms, where AI governance, data security, and threat detection eventually converge. UADP is the destination, ARISE is the part you need before the destination exists, which is to say the part you need now.


One thing to settle before going further, because the agentic security conversation keeps losing it. Nothing in this threat model is new. Least privilege, credential hygiene, segmentation, inventory, continuous verification: every one of those was correct fifteen years ago and is correct this morning. The presence of Agents did not invent a defensive fundamental.


What agents did was invalidate a set of risk acceptances we had been signing for years, and those acceptances were flawed when we signed them. Uninventoried service accounts. Static secrets in process environments. Over-scoped automation credentials nobody wanted to tighten on a Friday. Each carried a compensating control in the margin, and read honestly, the control was almost always the same sentence: a human would probably notice.


That held, barely, because the adversary was also human and therefore slow. Underneath it sat one genuine gap, and it was never a missing product category. We never built the observability to correlate identity correctly, human or non-human, across the domains identities actually operate in. Not to log it. To correlate it, into the story of what one identity is actually doing.


So read the three layers below as the bill for fifteen years of deferred maintenance, arriving now that the adversary stopped being slow.


The stack you already bought cannot answer it


Go down the list honestly.


Identity governance (IGA) answers who should have access, on a certification cycle measured in quarters. Privileged access management (PAM) answers who may check out this credential, then hands it over and looks away. Cloud entitlement tooling answers what this role could theoretically reach, which is a statement about configuration, not behavior. Your SIEM answers what happened, eventually, after correlation, after enrichment, after a queue.


Every one of those is a good control. Not one of them is in the path at the moment of the action.


That was survivable when the actor on the other end was a person, because a person is slow. The 2026 CrowdStrike Global Threat Report puts average eCrime breakout time at 29 minutes, down 65% from the year before, with the fastest observed breakout at 27 seconds. Google Cloud tracked the disclosure-to-exploitation window collapsing from weeks to days across the second half of 2025. Human review cycles did not get 65% faster to match.


The detail from that CrowdStrike report I keep coming back to is different, though, and it is the one that should end the argument. Eighty-two percent of detections were malware-free. The intrusions ran on valid credentials, trusted identity flows, and approved SaaS integrations. There was nothing to find, because nothing was foreign. Somebody logged in.


Agents make that the default condition rather than the clever exception. An agent is supposed to hold credentials. It is supposed to call tools, chain them, and act without a human in the loop, because that is the entire product requirement. Every artifact an intrusion used to leave behind, an agent generates as normal operation.


So the detection question stops being useful. You cannot separate legitimate agent activity from hostile agent activity by looking for the unusual, because at the level of individual events there is no unusual left. Both look like a Tuesday.


Three layers, and why all three are load-bearing


SACR structures ARISE across three layers. They are not maturity stages and they are not a shopping sequence. Take one away and the other two stop working.


Layer one is deterministic governance. Agent identity, scoped credentials, the tools it may call, the APIs it may reach, RBAC and ABAC policy, just-in-time access. This is the boundary drawn before anything runs. It is also the layer most teams assume they already have, usually because they have it for humans and have quietly extended the assumption to agents. Worth checking that assumption before you rely on it.


Layer two is behavioral and intent analysis. Reconstructing the path from prompt to action, instrumenting tool-call telemetry, watching credential use, scoring anomalies, and detecting intent drift across a sequence. Drift is the concept that matters here. A single tool call is almost never the problem. The problem is the eleventh call in a sequence that started somewhere reasonable and arrived somewhere else, one defensible step at a time.


Layer three is dynamic runtime governance. This is the verb list, and I would make anyone selling you an agent security product recite it: allow, block, redact, pause, step up authentication, route to a human, reduce scope, revoke a credential, quarantine, terminate, open a ticket, escalate to the SOC.


Notice the grammar of that list. Those are all things done to an action in progress. Not findings. Not recommendations. Not a dashboard tile that turns amber.


The dependency runs in both directions, which is the part people miss. Layer three without layer two is a blunt instrument that blocks your own automation and gets switched off inside a month. Layer two without layer one has no baseline to measure drift against, because you cannot call behavior abnormal without a definition of normal. And layer one on its own is a policy document with good intentions, which describes most agent governance programs I walk into.


SACR rounds this out with eight capability requirements spanning runtime enforcement, agent identity and delegation tracking, tool and MCP governance, behavioral analysis, evidence and audit trails, organizational context, AI-driven policy scoring, and multi-model support. Delegation tracking is the sleeper on that list. When an agent invokes another agent which calls a tool on behalf of a user who approved something adjacent three steps back, somebody has to be able to reconstruct that chain of authority afterward. Most shops cannot reconstruct it during, let alone after.


Agentic Control Depth, and the line at ACD 4


The most useful thing in the report is a six-level scale called Agentic Control Depth. It measures one variable: how deep into an agent's action your controls actually reach.

SACR's position is that ACD 4 is the minimum operational threshold for production agents touching sensitive data or critical workflows. I would go further and say the line between ACD 3 and ACD 4 is the only boundary on that ladder that changes your risk position. Everything below it is a description of the incident you will write up later.


ACD 2 is where the honest majority sit, and it is a comfortable place to be because it generates artifacts. Dashboards populate. Alerts fire. Quarterly metrics improve. None of it touches the action. Post-event telemetry against an adversary operating at 27 seconds is a very well-instrumented way to find out what happened to you.


ACD 3 feels like progress and often is, for a while. Static guardrails catch the obvious and the careless. They also assume you enumerated the bad paths in advance, which is exactly the assumption agentic systems exist to violate. An agent's value comes from composing steps you did not script. Your rules cover the compositions you imagined.


One caution on ACD 5, because I do not want to oversell a level nobody has operationalized. Autonomous policy adjustment means a system changing your controls without a human approving the change, and that is a governance question as much as a technical one. The audit and rollback story has to exist before the automation does. Treat ACD 5 as a direction, not a Q4 objective.


Run the assessment on your own estate this week and be unkind about it. Not the pilot. Production. Most programs I see score ACD 2 for human-facing applications and ACD 0 for the agents nobody registered, which in our customer environments runs to roughly 65% of AI and automation identities unmanaged, about half of them absent from the inventory entirely before we looked.


What I would do Immediately


None of this needs a budget cycle to start.


Count your agents, including the ones nobody told you about. Not the approved platform. The copilot somebody wired into a ticketing queue, the scripted LangChain job in a business unit, the MCP server a developer stood up to save an afternoon. Shadow agents are this decade's shadow IT with credentials attached, and you cannot govern a population you have not counted.


For each one, document its delegated authority in a sentence. Whose permission is it acting under, which credential does it present, and what is the widest thing it could reach if the prompt went sideways. If that sentence takes a meeting to produce, that is the finding.


Score yourself against ACD honestly, per workload, and separate what production does from what the pilot demonstrated. The gap between those two numbers is usually the whole story.


Inventory your tool and MCP surface the way you would inventory an API estate. Every tool an agent can call is an entry point with the agent's authority behind it, and the Model Context Protocol spec is moving fast enough that a server approved six months ago may not resemble what is running now.


Then ask your vendors the enforcement question, and hold the line on the verb. Not whether they detect, not whether they alert, whether they can block, redact, or revoke mid-action, and what the measured latency of that intervention is. A control that intervenes in four seconds against an adversary breaking out in 27 is a control in name only. Ask for the number.


Last, agree on the human-in-the-loop boundary before an incident forces the conversation. Which action classes always pause for a person, which get stepped-up authentication, and which run free. Write it down. Get the business to sign it. Doing this at 2 a.m. during an incident produces a policy you will regret and probably reverse.


Where this goes


Thirty vendors in one inaugural report is a market telling on itself. Most of them solve one layer well, and the honest read of SACR's six patterns is that buyers assembling ARISE from parts right now will spend the next eighteen months integrating rather than enforcing. Consolidation is coming, and UADP is the shape it will take.


SACR named AuthMind a representative vendor with broad alignment across all three ARISE layers, one of a small number so identified among the thirteen profiled. The capabilities behind that are shadow agent discovery, agentic identity threat detection and response, agent governance and posture management, and non-human identity and secret usage monitoring. Three weeks earlier, Gartner named AuthMind a Representative Provider in Innovation Insight: Identity Visibility and Intelligence Platforms, published 24 August 2026. Two research houses, two different categories, one underlying argument: policy intent and actual identity activity have come apart, and the gap between them is where agents operate.


That argument is not new to anyone who has run identity at scale. What is new is the clock. We spent twenty years building identity controls that assume a human is on one end and a review cycle is on the other. Both assumptions are now wrong, and they went wrong faster than any refresh cycle can absorb.


Here is the part I would take to a board. Your network telemetry scales with your adversary's throughput, which means it scales past your budget the moment they point agents at you. Your identity inventory does not move. A finite number of agents, service accounts, delegated authorities, and tool surfaces, and that number holds still no matter how many actions per second arrive. It is the one layer where the denominator stays fixed.


So the question is not whether you will govern agents at runtime. The agents are already running. The question is whether you find out what they did from your own controls, or from somebody else's disclosure timeline.


Sources



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

bottom of page