The First Analyst Framework for AI Agent Security Just Named Britive's Key Differentiators: Runtime Action Governance for AI Agents

SACR's ARISE research asks whether an agent's action should be allowed right now. Most of the market answers with a credential. Britive answers by removing the reason the credential exists. 

Software Analyst Cyber Research (SACR) has published the first analyst framework built for AI agents in production. It is called ARISE, Agentic Runtime Identity Security Enforcement, and it reduces agent security to one question: should this agent be allowed to take this action, with this tool, this credential, and this delegated authority, right now? 

Britive is one of thirteen vendors profiled. The profile grades the platform's deterministic governance as "strongest alignment," its agent identity and credential issuance as "very strong," and puts the differentiator in one sentence: "Britive's clearest moat is the just-in-time, zero-standing privilege model applied across identity types." 

This post covers what the framework says, why the category is forming now, what SACR found in Britive, and what to ask of any vendor who claims to secure agents. 

The Category is Forming as Terms Continue to Evolve 

Six months of deals tell the story. Delinea acquired StrongDM. Cisco acquired Astrix. Snowflake acquired Natoma. Silverfort acquired Fabrix. Palo Alto Networks folded CyberArk into Idira. Each transaction bought one piece of the runtime problem: a proxy, a discovery engine, an MCP gateway, an analysis layer. SACR profiles thirteen vendors in this report and its analysts track dozens more. Consolidation is underway, and it is happening around a question nobody had written down until now. 

ARISE writes it down. SACR defines the category as "the runtime enforcement layer for agents in motion" and sorts controls into three layers: 

1. deterministic governance (what is the agent allowed to access), 
2. behavioral and intent analysis (does what it is doing make sense), 
3. and dynamic runtime governance (should this continue, be narrowed, or be stopped right now). 

It adds a maturity scale, ARISE Control Depth, and states a hard floor: for any production agent touching sensitive data, credentials, or critical workflows, the minimum is ACD 4, inline pre-completion intervention. A control that decides in the path before the action completes, not a log that explains it afterward. 

When you read the thirteen profiles side by side, a pattern appears. Most of the market decides whether an agent may use privilege that already exists: a credential in a vault, a token from an exchange, a role a gateway can always assume. The credential is isolated, rotated, scoped, handed off, and watched. 

But the credential is never completely gone. 

Britive was built on the other answer. Privilege should not exist until an authorized action requires it, and it should be gone when the action ends. That was the platform's founding principle for people and ephemeral cloud workloads before agents arrived. It's why the report's authors could write the sentence they wrote.

What SACR Found in Britive 

Direct from the published profile in the report: 

• Layer 1, deterministic governance: "Strongest alignment." Human, service, and agentic identities are first-class; ownership, scoped profiles, allowed tools, MCP authorization, just-in-time access, least privilege, default-deny policy, and human-in-the-loop controls run through one common policy model. 
• Agent identity and delegation: "Very strong." 
• Credential issuance or use: "Very strong." "Ephemeral credential/profile checkout is central," and temporary credentials reach downstream MCP servers "without creating standing credentials there." 
• Runtime enforcement, tool and MCP governance, and evidence and audit: each "Strong." 

The profile also records what happens at runtime: default deny on every tool call, per-identity tool visibility, checkout-triggered privilege elevation, human approval that blocks the call until it is given, Britive-mediated sessions that cannot proceed without an active checkout, and inbound Shared Signals Framework events that "can revoke an active checkout mid-task." 

That last line answers a test the report itself poses: can a compromised agent keep acting with a token it already holds? 

With Britive, the privilege behind the token was created at checkout and is removed with it. There is nothing left to flush from a downstream system, because nothing standing was ever placed there. 

Measured against the report's own definition, the Britive architecture is ACD 4: in the path at tool selection, at credential issuance, and at execution, evaluating live signals before the action completes. It was ACD 4 for humans and non-human identities before the scale existed. 

Everyone Else Secures the Credential. Britive Removes the Reason It Exists. 

The whole difference is structural, not just another feature. 

In a vault model, the credential is permanent and rotated. In a proxy model, the role the gateway assumes is permanent and always assumable. In a token-exchange model, disabling the connection does not recall the tokens already issued. Every one of those models leaves something durable behind for an identity, or an attacker, to use, and every one of them spends its engineering guarding that durable thing. 

Britive creates the privilege inside the target system's own access model at the moment of the authorized action and removes it when the action ends. An AWS role assignment, an Azure role, a Snowflake grant, a Kubernetes binding, a database user, a local administrator on a laptop: created for the task, gone after it. Between tasks the agent holds an identity with no privileges. So does the workload. So does the person. One policy engine decides for all three, and one audit stream records all three. 

Britive ARC™ extends that model to agents: an AI identity with a named human owner, every tool call authorized at runtime, dangerous commands blocked before they reach the system, the prompt and the agent's stated intent recorded with the call, and access that ends when the task ends, the timer expires, or a signal revokes it. 

SACR's closing line states where the market is going: "The future of agent security is runtime action governance, not access approval." Britive has been there since the company was founded. 

Three Questions to Ask Any Vendor You’re Evaluating 

SACR closes with a buyer's checklist. Three of its questions separate the market fastest. 

Can access be scoped, short-lived, and revoked? Ask what exists in the target system between tasks. If the answer is anything other than "an identity with no privileges," the product is managing standing privilege, not removing it. 

Can the product block, restrict, revoke, or terminate before completion? Ask where the decision happens and what it decides against. A gateway that decides against a static credential leaves that credential's full power sitting on the resource. A decision that creates the privilege can also take it back. 

Can the product reconstruct the action chain for audit and incident response? Ask what the record contains. For an agent, the useful record is the identity, the person it acted for, the prompt, the stated intent, the tool, the arguments, the decision, and the outcome, captured while the action happens, not assembled afterward. 

The report also names what remains difficult across the market: connecting actions to owners, applying policy at the level of the individual action and resource, and preserving an audit trail that explains both the action and the decision. Those are the problems Britive was built to solve. 

Where Britive Stands 

Britive governs millions of identities across thousands of environments and has eliminated tens of millions of static permissions for customers including Toyota, Procore, Marqeta, and other enterprise customers. 

KuppingerCole names Britive a Product Leader in NHI Management and writes that the platform's differentiator is not just-in-time access, "an increasingly common capability across the PAM market," but "its commitment to a ZSP architecture." 

Britive ARC™ launched in August 2026, alongside launch partnerships with AWS Security Hub Extended and AWS IAM account access manager. 

Read SACR's ARISE research online and review their profile on Britive here. Thank you to Lawrence Pingree, Paul Webber, and the SACR team for a framework that asks the right question. 

Privilege is temporary. Control is continuous. Proof is captured throughout. 

See it in your own environment: request a demo to see Britive in action.