An employee asks an AI agent to investigate a customer issue. The agent retrieves internal technical context, prepares a plan of action, and attempts to send it through an external tool. The employee has permission to investigate, and the tool is available. But should an agent that has just handled sensitive customer material be allowed to send its work through that service?
Answering requires context about the employee, the task, the data, and the agent’s activity. A security team needs to connect those details while there is still an opportunity to influence the outcome.
That challenge is reflected in Software Analyst Cyber Research’s ARISE market map, which breaks the emerging agentic security landscape into distinct but increasingly connected areas. WitnessAI is included across four:
- Gateway and Prompt-Control ARISE
- MCP and Tool-Governance ARISE
- Runtime Behaviour and Agent Detection
- Emerging Full-Stack ARISE Contenders
These four areas trace the path a single task travels: the prompt in, the agent’s behavior in between, and the tool call out. WitnessAI’s perspective is that security policy has to follow that activity across employees, models, applications, and agents.
Permission is only part of the decision
ARISE stands for Agentic Runtime Identity Security Enforcement. SACR published the report on September 3, 2026. Authors Paul Webber and Lawrence Pingree built the framework around one question: “should this agent be allowed to take this action, with this tool, credential, data, and delegated authority, for this purpose, right now?“
One sentence in the report captures why existing controls can’t answer it: “A valid credential can still be used for an invalid action.”
The agent in our example is authorized. Its credential is valid, its tool is approved, and every access check passes. What fails is the action. For WitnessAI, this is why the policy decision has to bring three signals together. The Identity acting traces to a person or agent through your identity provider. The Intent behind the request is read from the interaction by behavioral models, and the Information being touched is identified by data classification. Each establishes something the others cannot.
In the customer-support example, the employee’s role establishes accountability. The request to resolve a customer issue supplies purpose. The internal material may still contain data that shouldn’t reach an external service. A legitimate task can involve sensitive data, so the decision needs all three readings before the transfer completes.
The bar is intervention before completion
The report’s most useful artifact for buyers is its ARISE Control Depth (ACD) maturity model. SACR sets the production baseline at ACD 4: inline enforcement that can allow, block, redact, pause, step up, or restrict a live action before it completes. Detection and alerting sit at ACD 2, and SACR writes that anything below the baseline “leaves the enterprise reliant on post-event remediation after a machine-speed blast radius has already been established.”
The report is equally direct with vendors: “do not claim ARISE based on visibility alone. Prove where the product can decide, intervene, and generate evidence.” We encourage buyers to run that test live on every vendor, including us. WitnessAI deploys in the traffic path, where it evaluates prompts, Model Context Protocol (MCP) connections, and tool calls inline. WitnessAI blocks an unapproved MCP server or tool call there before it executes.
Running the test also means matching the deployment to the workflow. Protection depends on the integrations in place and the traffic passing through the controls. In the customer-support example, a team should establish which interactions are inspected and where a policy can affect the attempted external transfer. An input check alone doesn’t establish control over every later tool action.
Multiple control points need consistent governance
SACR notes that no single control point covers the entire ARISE problem, and its market map shows vendors approaching runtime governance from six different architectural starting points. A CISO may choose specialist tools for particular requirements. The difficulty arrives when each system carries a separate version of policy and a separate account of what happened. When an employee delegates work to an agent, investigators need the connection between the person, the AI interaction, and the tool. Reconstructing that connection across separate systems adds work at exactly the moment there’s no time for it.
WitnessAI brings employee and agent governance together with runtime security for models, applications, and agents through Observe, Control, and Protect. Human and agent activity share one console, one policy framework, and one audit log. WitnessAI records the connection investigators need at the moment of the action, so no one has to reconstruct it afterward.
The agent, and the person who commands it
SACR frames ARISE as a sub-discipline of Unified Agentic Defense Platforms (UADP), the market’s longer-term destination. The report ties demand to the risks of agentic identities “and the users that command AI agents.” That phrasing matches how work actually moves. When the employee in our opening example delegates the customer issue to an agent, the company’s obligations follow the work: sensitive information still needs protection, and actions still need an accountable owner.
SACR’s UADP research also names what the destination requires: “The winners will be those who can best correlate identity (who/what is acting), data (what is being touched), and intent (why is it happening).” Identity, intent, and information are the coordinates the WitnessAI policy engine already evaluates on every action it governs, human or agent. Security teams should be able to extend governance to new AI workflows without rebuilding policy and accountability around each new application or agent.
Read SACR’s ARISE research. Then bring your own version of the scenario above to a WitnessAI demo and evaluate the platform against the report’s ten buyer questions.