The Six ARISE Capabilities the SACR Report Points To - And How to Evaluate Whether a Vendor Has Them

SACR has published its research defining ARISE, Agentic Runtime Identity Security Enforcement. That is good news for enterprises trying to govern enterprise AI agents. The problem is real, the investment is warranted, and a shared standard now exists to measure vendors against.

It is worth being precise about what SACR said. It does not describe ARISE as a finished category. It describes a control plane pattern that is becoming one, positioned inside the broader Unified Agentic Defense Platform architecture. For buyers, that distinction is the whole point: you cannot shortlist by label, because the label does not yet tell you what a product does.

Which brings us to the less convenient part. Every vendor in the adjacent space will now claim ARISE. Some are right. Most are not. SACR anticipated this, telling vendors not to claim the category on visibility alone and telling buyers to test enforcement claims inside a live workflow.

The gap ARISE exists to close is not visibility, though visibility is part of the answer. It is not permissions, though permissions are part of the answer. It is the absence of a layer that, at the moment of execution, evaluates whether an AI agent is doing what it was authorized to do, against the organizational intent that established the authorization.

Below are six capabilities that are required at the implementation level, and the question that reveals whether a vendor has each one.

1. Discovery Without Prior Knowledge

Finding every AI agent in the environment without waiting for AI agents to register or IT to submit lists. Shadow agents, built by employees, enabled by SaaS updates, deployed outside procurement, consistently make up the majority of the real population. Real discovery works through infrastructure already in place: EDR, MDM, CASB, identity providers, enterprise browsers, SaaS platforms.

One caveat, and it is why discovery is first on this list rather than most important on it. SACR found discovery approaching table stakes, and inventory alone does not establish ARISE alignment. If a vendor's strongest answer in an evaluation is a discovery answer, you are looking at an inventory tool.

Ask: "Show me how you discover an AI agent an employee built in a workflow tool last Tuesday and never registered with IT. How long from AI agent creation to appearance in your platform?"

A vendor with real discovery answers precisely. A registration-dependent vendor hedges, talking about submission processes and coverage for known frameworks. The hedge is the answer. They govern the AI agents they know about.

2. Organizational Intent Capture

Every discovered AI agent needs a structured, machine-readable definition of what it was built to do. Not a description, a specification: authorized systems, data types, actions, behavioral scope. This becomes the baseline for everything you evaluate. Without it, runtime evaluation has no standard.

Organizational intent is not permissions. Permissions tell you what an AI agent is allowed to do. Intent tells you what it was built to do, a tighter and more useful standard, because AI agents routinely hold permissions well beyond their purpose.

Ask: "How do you capture organizational intent, and how is it represented? Natural language, or machine-readable and enforceable without AI interpretation?"

If it is natural language interpreted by a model against observed behavior, ask about the error rate. Interpretation introduces error that compounds. Genuine intent capture uses structured, role-based definitions evaluated deterministically.

3. Runtime Behavioral Governance

This is what makes ARISE distinct. Every tool call, API invocation, and data access is evaluated against the intent baseline before it completes. Not logged and reviewed afterward. This requires the enforcement layer to be inline, between the AI agent's decision to act and the system it is about to act on, at the latency of the execution path. A layer reviewing logs asynchronously is post-hoc monitoring.

Buyers now have an external standard here, and it is the most useful thing in the research. SACR's Agentic Control Depth model runs from ACD 0 (blind execution) to ACD 5 (autonomous self-healing). ACD 4 is inline pre-completion intervention: the control plane sits in the path and can allow, block, redact, pause, step up, or narrow scope before impact. SACR sets ACD 4 as the minimum for any use case involving sensitive data, credentials, or critical workflows. Below it, you are remediating after a machine-speed blast radius has already formed.

Ask vendors for their ACD level. Then ask them to prove it.

Ask: "When an AI agent is about to take an action technically within its permissions but inconsistent with its organizational intent, can you stop it before it executes? Walk me through how, technically."

This reveals inline enforcement versus monitoring. One prevents the action. The other alerts afterward. Both have value. Only one meets the standard.

4. Intent Drift Detection

AI agents do not stay static. Workflows evolve, environments change, model updates shift behavior. An AI agent inside its intent at deployment drifts out of it through accumulated small decisions. Catching this requires continuous comparison against the baseline at two levels: session, where individual deviations surface, and trend, where accumulating drift is caught before it becomes an incident.

Ask: "If an AI agent's behavior has shifted gradually over six weeks, where each session looks reasonable but the pattern represents meaningful drift, how do you detect that? What signal surfaces it, and when?"

A vendor with real drift detection names the signals, the baseline, and the time horizon. A vendor without it describes session-level anomaly detection, which catches dramatic deviations and misses the gradual drift that compounds.

5. Cross-Chain Authorization Integrity

Enterprise AI deployments are chains. Supervisors delegate to workers, which invoke sub-agents, producing outcomes no single AI agent was authorized to produce. Authorization context has to survive the chain: the original human authorization travels with it, scope only decreases across hops, and every action traces back to its origin.

This is the capability most ARISE-claiming vendors lack, because it requires governing the chain as a unit rather than AI agents one at a time. SACR found the same thing, naming pre-completion intervention across distributed and multi-agent workflows as an open market gap.

Ask: "If a supervisor delegates to a worker that invokes a sub-agent accessing a sensitive system, can you trace that action to the original human authorization? What does the audit trail look like, and how do you prevent scope expanding across hops?"

If they describe per-agent governance without addressing chain-level accountability, they are governing individual identities. For multi-agent deployments, that is where exposure accumulates.

6. Incident-Ready Accountability

Control that cannot prove itself is not control. The audit trail has to record not just what the AI agent did, but what it believed it was authorized to do, in what context, and whether that was consistent with its intent baseline. Structured for SIEM ingestion and regulatory review, not a raw log requiring reconstruction.

The test is the incident. When something goes wrong, can you answer from the trail alone whether the action was authorized at the intent level, not just the permissions level?

Ask: "Walk me through your audit trail after an AI agent incident. Can you show the chain from the action back to the human authorization, including the intent baseline at the time? Or does it only show what the AI agent did?"

Most platforms can tell you what happened. Fewer can tell you why the platform allowed it.

One More: Cost as a Control Question

SACR treats token cost and model selection as a control question rather than a finance one, and flags attribution as an open market gap. It belongs in an ARISE evaluation for a practical reason: an AI agent that has drifted from its intent usually shows up in the cost data before it shows up in an incident. Consumption is a behavioral signal, not a line item.

Ask: "Can you attribute token consumption to a specific AI agent, its owner, and the invoking workflow? Native, integration, or roadmap?" Those are three different products.

How to Use This

Ask every vendor claiming ARISE, including aizome. These questions are built to reveal capability, not to favor anyone. A vendor that answers all six with specificity and architectural detail is doing ARISE. A vendor that hedges on two or more offers adjacent capabilities that are useful but insufficient.

Questions 3 and 5 are the most revealing. They demand the most distinct architectural investment, and they are where the gap is widest between real capability and a label applied to something adjacent. SACR's own finding points the same way: deterministic boundaries are the most consistently represented layer across the market because they extend familiar IAM and PAM practice, while changing the outcome of a live action is the clearest differentiator.

If a vendor cannot demonstrate inline enforcement before execution, they are a monitoring platform. Monitoring platforms are valuable. They are not ARISE.

If a vendor cannot demonstrate cross-chain accountability, they are an AI agent identity platform. Also valuable. Also not complete ARISE.

One last question, taken from SACR: ask which capabilities are GA today, which are beta or limited preview, which are on the roadmap, and which need professional services. The research found that the line is blurred across the market. It is the cheapest question on this list.

The ARISE Playbook

The SACR research names the pattern and describes the problem. The ARISE Playbook is the practitioner's guide to implementing what it requires: what each capability demands at the architecture level, how to sequence implementation, and how to evaluate against the standard.

🔗 Download it for free at aizome.ai

Chen Pipek is CPO and Co-Founder of aizome, an Enterprise AI Agent Identity Fabric Platform. He previously co-founded and led AxoniusX within Axonius and has held product and security leadership positions for over 20 years.