ARISE Names the Runtime Layer. Here Is Where Palma Sits, Control by Control.

SACR just published a framework for governing AI agents at runtime. We read it against our repo instead of our pitch deck. Sixteen of twenty controls are already ours. Four are not, and we say which — and why they are last.

On 3 September, Software Analyst Cyber Research (SACR) published ARISE: Agentic Runtime Identity Security Enforcement, written by analysts Paul Webber and Lawrence Pingree. It names a category that everyone running agents in production has been improvising for eighteen months: the layer that decides whether an agent's action should complete, at the moment it is about to.

The report profiles thirteen vendors. Palma is not one of them. That is a good reason to read it more carefully than a vendor who is, so we did the unglamorous thing: every control the report names, checked against our repository, our shipped services and our ticket tracker. Not against a slide.

This post is the receipt.

A valid credential does not make a live agent action valid

That sentence is the whole report. Everything else is scaffolding around it.

For twenty years identity security answered one question: who has access? Provisioning, entitlement reviews, privileged access, secrets rotation. All of it evaluates access before execution or documents activity after it. Both are fine when the actor is a person and the action takes minutes.

An agent takes seconds. A single run selects tools, requests credentials, queries data, invokes APIs and triggers a workflow before anyone has read the alert. The report frames this as a speed asymmetry and backs it with numbers that are hard to argue with: CrowdStrike's 2026 threat report puts average eCrime breakout time at 29 minutes; Google Cloud found the window between vulnerability disclosure and active exploitation collapsed from weeks to days in the second half of 2025; Anthropic disrupted an AI-assisted espionage campaign that ran against roughly thirty organisations with minimal human involvement.

Against that backdrop, "we reviewed the agent's permissions last quarter" is not a control. It is a memory.

ARISE's answer is to move the question. Not who has access, but should this specific action, by this agent, on behalf of this person, complete right now?

Three layers and one test

The framework has three layers. They are worth knowing because they are how buyers will structure evaluations from here on.

Layer 1, deterministic governance. The boundaries. Agent identity, owned credentials, approved tools, RBAC and ABAC policy, just-in-time access. Answers what is this agent allowed to reach?

Layer 2, behavioural and intent analysis. The observation. Prompt-to-action reconstruction, tool-call telemetry, drift detection, sequence analysis. Answers what is the agent doing, and does it make sense?

Layer 3, dynamic runtime governance. The intervention. Allow, block, redact, pause, escalate or require approval before completion. Answers should this proceed, now?

Beneath the layers sits a maturity model, ARISE Control Depth, running from ACD 0 (ungoverned execution) to ACD 5 (autonomous self-healing governance). The line the report draws is at ACD 4, inline pre-completion intervention, which it calls the minimum for any production agent touching sensitive data or critical workflows.

That is the test. Not whether you can see an action. Whether you can stop it before it lands.

Where gateways stop, according to the report

The section most relevant to us is the one on what ARISE is not. Among the things it excludes: AI gateways, which "inspect prompts and responses but lack identity, tool, data and workflow context." Gateway controls are called necessary but insufficient because they run "without visibility into identity, delegation chains, tool usage or business-process context."

We agree with that description of most gateways. It is the reason Palma is not built as one, and it is the argument we made at length in why API gateways do not work for agent MCP.

Every call through Palma carries three identities, kept separate. The subject (who the work is for), the principal (which agent is calling) and the client (which assistant or runtime it came through). A service account tells you a process ran. The three-principal model tells you a person was owed the result, which agent acted for them, through what, and who approved it. That is the delegation chain the report says gateways lack, attached to the call itself rather than reconstructed afterwards. The security page sets out the model in full.

Tool and MCP governance is the core product. Policy is evaluated before the upstream call, and there is no fail-open path: if the policy engine cannot decide, the call does not proceed. That is the Layer 3 posture, and it is the difference between a proxy and a control.

The receipt: twenty controls against the repo

We extracted twenty distinct controls from the report. Sixteen map to something we ship today or have on a named epic. The evidence column below is a service, a file or a ticket. Not a claim.

Eight shipped. Eight planned with an owner and a ticket. Four not built, and covered below.

The four we have not built, and why they are last

A vendor post that maps a framework and finds no gaps is marketing. Here are ours. Every one is a sequencing decision rather than an oversight, so we have said where each sits and why it is not first.

1. Model-selection governance — half of it. We already govern where the model and client axis meets tools. Tool entitlement is scoped per client and per model, so the same team can be allowed a tool inside Copilot Studio and denied it in a different assistant, and a given model can be restricted to a subset of tools. What we do not do is the other half ARISE names: approved-model policies, model allowlists, and routing a request to a model by cost, risk or data sensitivity. In the enterprises we work with, model choice itself sits with a central AI platform team upstream of us, while the tool boundary is the part nobody owns — so that is where we built first. As that ownership consolidates we expect to govern both ends. Where models run on your own infrastructure, sovereign AI is the closest we come today.
2. A maturity ladder you can place yourself on. We track conformance as a binary — AARM Core or Extended — not as a 0 to 5 ladder. On ARISE's scale we would self-place at ACD 3 to 4. That ladder is the most immediately useful thing in the report for a buyer, it is cheap for us to publish, and we will. The exception is ACD 5, self-healing and dynamic policy recalibration, which is not on any plan of ours and which we are not yet convinced by: a control that rewrites itself is a control your auditor cannot pin down. We will build it when someone can show us how to keep it explainable.
3. Prior decisions as a live policy input. Our access graph is an ownership and access graph. ARISE's context graph goes further and feeds earlier policy decisions and approvals back into runtime evaluation, so precedent shapes the next decision. We store approvals. We do not evaluate against them. This is a roadmap item, and it is behind the deterministic controls on purpose: a regulated buyer has to be able to say why a call was allowed, and "because a similar one was approved in March" is a harder answer to defend than a rule you can read. Precedent makes governance smarter and it makes it less legible, so it comes after the part that has to hold up in an audit.
4. AI-assisted policy authoring. The report bundles author, recommend, simulate, tune, explain and score into one capability. We have simulate and tune, through observe mode. We have no policy recommender and no action-risk scoring at authoring time. Also roadmap, also sequenced: security teams adopt AI in their own workflow last, and a recommender is only useful once the team already trusts what the engine does with the rules they wrote themselves.

None of these is a permanent no. Enterprise governance gets adopted in a particular order — deterministic before adaptive, attributable before autonomous, explainable before clever — because that is the order a security review can approve. We build in that order deliberately, and we expect three of these four to land as the category matures. If one of them is the thing your evaluation hinges on, you should know that before a demo, not after a contract.

The harder framework

ARISE is a market framework. It is a good one, and it will shape RFPs. It is not a specification: there is no published test protocol, no normative language, no conformance registry.

There is one that has all three. AARM, Autonomous Action Runtime Management, published in February 2026 by Herman Errico, is an open specification with nine requirements written in RFC 2119 language, a technical working group that includes Vanta, Elastic, Darktrace and Truist, and a public conformance process. We have tracked Palma against AARM since April, requirement by requirement. On the two that ARISE also stresses, pre-execution interception (R1) and identity binding (R6), we meet the spec; on the five authorisation decision types (R4) we currently implement three of five.

We mention this for a reason. When a category gets a name, the next thing it gets is a wave of vendors claiming to be in it. A framework with a test protocol is how you tell them apart. Ask for the conformance mapping. Ask for ours.

What to ask every vendor, including us

SACR's own advice to buyers is the best part of the report, and it applies to Palma as much as to anyone. Five questions:

1. Where does enforcement happen? Before the action completes, or after it is logged?
2. What does the system see? The prompt, or the identity, the tool, the data and the delegation chain behind the call?
3. What authority does it hold? Can it block, pause and escalate, or only alert?
4. What happens when it cannot decide? Fail open, or fail closed?
5. Can the decision be reconstructed later, by someone who does not trust you? Signed, tamper-evident, exportable to your SIEM, verifiable offline?

Our answers, in order: before; all of it; block, pause, escalate and require approval; closed; yes, and the verifier is a standalone binary you can run without us in the room.

If the regulatory framing is what you are evaluating against, our CIO deep dive on SOC 2, GDPR, the EU AI Act and DORA covers the evidence side in detail.

The takeaway

• ARISE moves the identity question from who has access to should this action complete now. That is the right question and it has been the design centre of Palma since the first wave of MCP.
• The report sets inline pre-completion intervention as the production minimum. Palma enforces before the call with no fail-open path.
• The report's critique of gateways, that they lack identity and delegation context, is correct for most gateways and is the reason Palma attaches three identities to every call.
• Sixteen of twenty named controls are shipped or on a named epic. Four are not built, and we have said which and why they are sequenced last.
• A framework without a test protocol will attract claims. Ask for a conformance mapping. Ours is against AARM and we will share it.

Running agents in production and evaluating against ARISE? Palma gives you one governed connector for every tool and Skill, enforcement before the call, identity that survives delegation, and an audit trail your auditor can verify without trusting us. Book a demo and bring the control list. Or put the questions above to your own assistant first — ask your own AI about Palma.

Source: SACR, "ARISE: Agentic Runtime Identity Security Enforcement", 3 September 2026. AARM v1.0: arXiv 2602.09433, aarm.dev.