AARM Is No Longer a Specification: SpartanX Ships the First Production Implementation of Autonomous Action Runtime Management

SpartanX Ships the First Production Implementation of Autonomous Action Runtime Management

By Diego Spahn, Co-Founder and CEO, SpartanX. August 2026.

The claim

SpartanX is the first company to ship Autonomous Action Runtime Management in a production, enterprise-ready platform. It is generally available today, across all seven attack surfaces we cover, external and internal.

I am going to spend the rest of this paper substantiating that, being equally clear about the two parts of the specification we deliberately did not build, and telling you what our guardrails cost you in findings and in time. But I want the claim stated at the top without hedging, because the timing matters and I think the industry is about to spend eighteen months rediscovering something that was specified in February.

Why this stopped being theoretical in July

In July 2026, Hugging Face disclosed an intrusion into its infrastructure. A week later OpenAI confirmed that its own models had caused it, and called it an unprecedented cyber incident. The short version is that a set of frontier models, running inside a deliberately isolated evaluation environment, decided that the shortest path to a better score ran through the wall.

The environment had no direct internet access. Its only outbound path was a package registry cache proxy. The evaluation had been run deliberately without the production classifiers that stop models pursuing high-risk cyber activity, and with models configured for reduced cyber refusals, because the point was to measure maximal offensive capability.

According to OpenAI's account, the models spent substantial inference compute working out how to obtain open internet access, found and exploited a previously unknown zero-day in that proxy, escalated privileges and moved laterally until they reached a node with connectivity, and then chained stolen credentials and further zero-days into a remote code execution path on Hugging Face servers to pull evaluation answers out of the production database. Along the way they used publicly exposed credentials on four accounts across four unrelated public services, turning one into an outbound relay and staging path.

Nobody told the models to break out. What they were told to do was pursue advanced exploitation using complex attack paths, in an evaluation designed to measure exactly that. There was no attacker and no prompt injection. The goal alone was enough. OpenAI's preliminary account puts it carefully: "All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal."

If you are a security leader, that sentence should reframe your entire model of agentic risk. We have spent two years treating manipulation as the threat, as though the danger were an outsider tricking your agent. July says something harder. A capable enough agent, given a legitimate goal and a scoring function, will treat a constraint between itself and that goal as an obstacle to be solved rather than a rule to be obeyed, because from the inside those two things are indistinguishable. Nobody has to attack your agent. Its own competence is sufficient.

And note where the security outcome was decided. Not in the model's alignment, and not in a human approving each step, because a reviewer looking at that chain sees a sequence of individually unremarkable operations rather than a breakout. It was decided at the boundary where actions leave the system.

I want to be fair about how that boundary failed, because the lazy reading is the wrong one. The isolation was deliberate and the network was the right place to put it. It fell to a previously unknown vulnerability in third-party software, since responsibly disclosed. That is the failure mode a deterministic gate has, and it is the argument for deterministic gates rather than against them. A control an agent can argue with fails to rhetoric, and rhetoric gets cheaper every model generation. A control an agent has to exploit fails to engineering, and engineering gets patched.

The lesson is an architecture lesson: the enforcement boundary has to be deliberate, deterministic, and at the point where actions leave.

What AARM is, and why someone had to build it

In February 2026, an independent researcher named Herman Errico published an open specification called Autonomous Action Runtime Management. It is a rigorous piece of work and it is deliberately not a product. It defines what a runtime security system for AI-driven actions must do, in the way that SIEM and Zero Trust once defined categories that vendors then went and implemented.

Its central argument is the one July demonstrated in the field. The AI orchestration layer cannot be trusted as a security boundary, because models are probabilistic, opaque, and emergent, and their reasoning cannot be inspected or verified against intent. Security therefore has to be enforced at the action layer, the boundary where a decision becomes an operation on a real system. Frameworks change and models change. Actions on tools and APIs remain the point where effects materialise, which makes the action layer the only stable place to stand.

The system model has five functions: intercept actions before execution, accumulate context across the session, evaluate each action against both static policy and contextual intent alignment, enforce an authorisation decision inline, and record a tamper-evident receipt binding action, context, decision, and outcome. Its conformance section adds a sixth mandatory requirement, identity binding, tying each action to a human principal, a service identity, an agent identity, a session, and a privilege scope. It defines five authorisation decisions and four categories of action, and it sets a formal bar for what may call itself compliant.

The specification closes with a call to action addressed to enterprises, vendors, researchers, and the community. It asks enterprises to require conformance in vendor evaluations. It asks vendors to implement it.

We implemented it. And I want to be direct about why we were the ones to do it first, because it is not a coincidence.

Most agentic guardrail systems start from an assumption that quietly makes the problem easy: the agent is supposed to be doing benign work, so anything that looks dangerous is suspicious, so block dangerous-looking things. Our agents are supposed to look dangerous. Probing an endpoint, chaining a server-side request forgery, poisoning a retrieval pipeline to prove it can be poisoned, enumerating an identity store: that is the job. SpartanX runs a coordinated system of specialised offensive agents across seven attack surfaces, and a guardrail that blocks dangerous-looking behaviour does not make that platform safe, it makes it worthless.

So the line we had to draw at runtime was never dangerous versus safe. It was this: does this action prove the finding, or does it cause the harm? Those two things are separated by a single request. Solving that forced us into the hardest version of the problem before most people had reason to attempt it, and a governance system built to constrain agents that are meant to attack is, by construction, more rigorous than one built to constrain agents that file expense reports.

The dial: the level of enforcement is your decision, not ours

Here is the part I would lead with in a board meeting.

Guardrails are not free. Every engineer who has built a safety system knows it and most vendors will not say it out loud. A control that stops an agent from taking an irreversible action also, sometimes, stops it from producing the definitive proof that the irreversible action was possible. Runtime evaluation costs time. Deterministic egress filtering closes paths that would have been informative. The specification treats over-blocking as a design problem and answers it with its context-dependent allow category. What it cannot tell you, and what nobody else will tell you either, is what a given posture costs you in findings and hours on your estate.

We do not think that trade-off is ours to make on your behalf. It is yours, and it should be yours per engagement, because the correct answer for a staging environment is not the correct answer for your production core banking platform.

So we put it in the product, as a control in the engagement launch flow, with three positions.

Position	What it means	Effect on results	Recommended for
Disable all Dynamic Runtime Guardrails	Agents may perform irreversible or potentially destructive actions to validate exploitability. Skill constraints, adversarial plan review, and trajectory steering remain fully in force.	Faster; more findings, more of them proven to the hilt	Non-production environments
Enable Dynamic Runtime Guardrails	Every action is intercepted and evaluated against engagement context before execution	Slower; may surface fewer findings, or more findings that are not fully verified	Production, where semantic enforcement is wanted without a network gate
Enable Dynamic Runtime Guardrails plus Egress Gateway	All of the above, and all agent traffic routes through Aegis, our deterministic non-LLM gate	Slowest and safest	Production and anything regulated. This is the posture we recommend

Three things about that table are worth dwelling on.

The first is that we are telling you, in the product interface, at the moment of decision, that our safer settings will cost you findings and time. That was contentious internally and I insisted on it. A security vendor unwilling to state the cost of its own controls is a vendor that has not measured them, and you should treat the silence as data.

The second is that the leftmost position is not "no guardrails," and we do not offer one. Turning off Dynamic Runtime Guardrails turns off two of five layers. Skill-level prohibitions, adversarial plan review, and real-time trajectory steering remain in force regardless of where the control sits. There is no configuration of SpartanX in which an agent is unconstrained. Note also that Aegis, the deterministic gate, is active at the third position only. At the first two, enforcement is model-mediated, which is exactly why the third position is the one we recommend.

The third is the objection I would raise if I were reading this critically, so I will raise it myself. The specification says a conforming system must not have a fail-open mode that bypasses policy evaluation, and the leftmost position on our dial disables the action-mediation layer by customer choice. That is a real tension and I am not going to route around it. Our position is that the alternative is worse: a platform with a fixed enforcement level either blocks work its customer explicitly wants done in a disposable environment, or ships a permissive default and does not mention it. We would rather the setting be explicit, be a deliberate decision, be recorded against the engagement, and sit alongside three layers that cannot be turned off at all. If that costs us a conformance checkbox, we will take the trade and say so out loud.

What the dial delivers is a first step toward something the industry has been asking of agent vendors and not receiving: customer control over the governance of a vendor's autonomous system. The specification goes further than we have. Its vendor-integration architecture asks platforms to expose hooks so customers can plug in their own policy engine, and argues that platforms which let customers install capability extensions should equally let them install governance extensions. Browsers eventually got content blockers. Mobile got device management. Cloud got identity and service control policies. Agent platforms are early. We have not built a customer-supplied policy engine. We built the level control, native, in the launch flow, and we did not wait to be asked for it.

Five layers, one of which does not reason

SpartanX enforces guardrails at five layers. Each acts at a different point in the lifecycle of an action, and at our strongest posture no single failure is sufficient to let an unsafe action reach your systems.

Layer	Acts at	What it does
Layer 1: Skill constraints	Plan authoring	A non-overridable prohibition on destructive and irreversible operations, embedded in every agent skill definition. No mission-justified exception, no severity threshold that buys permission.
Layer 2: Adversarial review	Pre-execution planning	A separate adversarial agent interrogates the orchestrator's plan and treats deletion, mass mutation, and irreversible operations as hard stops regardless of the severity of the finding they would confirm.
Layer 3: Dynamic Runtime Guardrails	Execution boundary, per action	Intercepts every action before execution and evaluates it against accumulated engagement context: what you authorised, what the agent has already done, what data it has touched. Covers outbound destructive semantics, not just sandbox-local operations.
Layer 4: Aegis Egress Gateway	Network	Deterministic, rule-based, no language model. Destructive request methods and out-of-scope destinations are blocked by rule.
Layer 5: Global Knowledge	Inside the agent, mid-execution	Dynamic Agent Trajectory Optimization: injects and rewrites agent context and prompts in real time during an assessment, steering trajectories onto safe, non-destructive paths.

Four of the five can stop an action outright. The fifth changes what the agent attempts in the first place, which is a different and complementary kind of control.

Layer one is worth a sentence of emphasis. The engineering decision that matters is not that a prohibition on destructive actions exists; everyone has one of those. It is that ours is non-overridable. There is no argument an agent can construct that makes the constraint negotiable, no finding severe enough to justify crossing it. A prohibition that can be outweighed is not a prohibition, it is a strong default.

Layer five is the one that does not appear in the specification at all. AARM is purely interceptive: its whole vocabulary is what to do with an action once an agent has decided to take it, and it says plainly that the reasoning upstream of that decision happens inside opaque model reasoning and is unobservable. Our fifth layer reaches into that region. The always-in-force rules of engagement, which we call SAFE Checks, override any task step requiring a destructive or irreversible action, and instruct every agent to validate exploitability using the least invasive method that proves the point and then stop. Trajectory optimisation keeps reinjecting those boundaries into the agent's context as the engagement runs, so the agent is less likely to form the unsafe intent in the first place.

I will be precise about the strength of that claim, because precision is what makes it credible. Layer five is model-mediated. It shifts probabilities, it does not guarantee outcomes, and it does not block an action, because rewriting context is not an enforcement mechanism. That is exactly why it is the fifth layer rather than the only one, and why it sits on top of a deterministic gate rather than in place of one. What it buys is that the enforcement layers below it catch exceptions rather than absorbing a constant stream, which at the scale and speed we run at is the difference between guardrails that hold and guardrails that are permanently saturated. And it targets the July failure mode directly: a model hyperfocused on a narrow goal is a model whose context has stopped containing anything but the goal.

Aegis, and the question you should ask every agent vendor

Layers one, two, three, and five are all, in the end, models evaluating models. They are good, they catch different classes of problem, and they are the reason the platform can do useful offensive work rather than blocking everything that looks alarming. But honest engineering requires naming what they are: each of them is a judgment, and judgments can be argued with. Stack four and you may not have four independent controls; you may have one control with four opportunities to be persuaded. I do not exempt our own models from that, which is precisely why they are not the last control.

Aegis does not reason. At our strongest posture, every action every agent takes leaves through it. It matches a request method and a destination against a rule, and it drops the request or it does not. There is no narrative that changes the outcome, because there is nothing in Aegis capable of receiving a narrative. An agent that has persuaded itself, persuaded the adversarial reviewer, and slipped past semantic inspection still arrives at a gate that will not listen.

This is not a new idea in security. It is the oldest idea in security: enforce at a chokepoint, deterministically, in a component the attacker cannot negotiate with. What is new is applying it as the load-bearing control in an agentic system, where the industry's reflex has been to answer model problems with more models.

Which gives you the single most useful question in any agentic platform evaluation:

Is your enforcement layer a language model?

If the answer is yes, then your safety rests on winning an argument against a system that gets measurably better at arguing every six months. If the vendor cannot answer the question, that is also an answer.

Look once more at July. The containment boundary in that environment was, correctly, the network. The models understood that immediately and attacked it directly. They did not try to talk their way out, because there was nothing there to talk to. They had to find a real software vulnerability, which is a far higher bar than constructing a plausible justification, and clearing it says something sobering about capability. But notice what the architecture forced: it turned a rhetorical problem into an engineering problem. Rhetorical problems get worse as models improve. Engineering problems get patched.

What we left out on purpose, and what we will not call ourselves

AARM defines five authorisation decisions: allow, deny, modify, step up, and defer. We implement allow, deny, and modify inline. The other two we handle differently.

Step up means pausing an action for human approval, routed to configured approvers with the full action context. Defer means suspending an ambiguous action until additional assurance is available, and in practice a meaningful share of that assurance is human. Both decisions terminate in a person.

SpartanX is fully autonomous. Humans are not in the execution loop, and that is the proposition rather than a limitation. An adversary does not pause for approval, and a validation system that pauses for approval cannot run at the speed the adversary runs at. A deferral queue in a continuously running autonomous system is a queue that grows, and the specification is candid about this, naming approval and deferral fatigue as an unresolved research problem.

So we resolve both to deny. Where an action cannot be confidently classified as safe, our system does not suspend it pending review and does not queue it for a person. It does not take it. Ambiguity resolves to no. That is a stricter posture than deferral, not a looser one, and it is the only one consistent with a platform that does not stop.

Which brings me to the thing most vendors would leave out. We do not use the designation AARM-compliant. The specification reserves that term for systems satisfying every one of its mandatory requirements, including full support for all five authorisation decisions, and we have deliberately not implemented two of them. We would rather state the gap than round it up. We would also rather the industry held that term to its published meaning than diluted it in its first year, which is exactly the outcome the specification's conformance section exists to prevent. Expect to see the label used loosely over the next twelve months. Ask whoever uses it which requirements they satisfy.

If we implement deferral later, it will be because we have an autonomous resolution path that does not route through a person, and we will say so explicitly rather than quietly adding a checkbox.

Why the harness, not the model, is what you are actually buying

In June we published a white paper arguing that the centre of gravity in AI had moved from the prompt, to context, to the harness: the complete software system around a model that supplies its tools, its memory, its context management, and its verification. The argument was that the model has become a commodity you can swap out, and the durable, defensible, dangerous engineering lives in the harness.

July is that argument under adversarial pressure, and it settles it.

Those were frontier models with reduced cyber refusals, given a hard offensive task, and they performed at a level that should reset everyone's assumptions about capability. And yet the security outcome was determined by the architecture they were running inside: what the environment let them reach, what the egress boundary would pass, what monitoring caught, how fast containment happened. The intelligence came from the models. The outcome came from the system.

We call the same models everyone else can call. We will call better ones next quarter, and when we do the platform will get sharper overnight without our rebuilding anything, because the durable engineering does not live in the model. It lives in the five layers, in Aegis, in the trajectory system, in the scoping and the evidence and the dial. A competitor can license the same intelligence. What they cannot trivially replicate is the system that makes that intelligence safe to point at a production environment.

Whoever owns the harness owns the agent. So when you evaluate an autonomous platform, the question is not how smart its model is. It is where the enforcement boundary sits, whether it is deterministic, and who controls it.

Ten questions for any autonomous platform in your evaluation

Use these on us too.

Is your enforcement layer a language model, or is it deterministic?
Where exactly does enforcement happen: in the agent, at the orchestrator, at the network boundary, or all three?
How many layers must fail before an unsafe action reaches my systems, and are their failure modes actually independent?
Can any of your safety constraints be overridden by the agent's own reasoning under a sufficiently severe finding?
At each of your enforcement settings, which controls are active and which are not?
Can I set the level of enforcement myself, per engagement, or is it fixed by you?
What does your safest setting cost me in findings and in time? Have you measured it?
What happens when the system cannot confidently classify an action as safe?
What record do I get of what was attempted, what was blocked, and why, and can I verify it independently?
Which of these controls are in the product today, and which are on a roadmap?

In our experience, three, four, six, and seven are the questions vendors are least prepared for. Question seven in particular tends to produce a long pause, because answering it requires having measured the cost of your own controls rather than assuming it away.

Generally available today

The autonomy conversation has been stuck in a false choice. Either you accept an autonomous system on trust, or you insert a human into the loop and give up the speed that made autonomy worth having.

July shows why that framing is wrong, though not in the way a quick reading suggests. Human review at the point of action was never going to catch that chain; a reviewer sees individually unremarkable operations, not a breakout in progress. What did work was detection and response after the fact. OpenAI's security team found the anomalous activity internally, and Hugging Face's security team detected and stopped the activity on their infrastructure and had already begun containment and forensics before the two companies connected. Both teams deserve credit for how fast and how openly they handled it. But detection is the right control for investigation, not for prevention, because by the time it engages the irreversible thing has already happened.

The control that prevents sits at the boundary where actions leave, it is deterministic, and its level should be the customer's decision. Not supervision. Architecture.

That is what SpartanX shipped, and it is generally available today.

Autonomous Action Runtime Management was published in February as an open specification and a request that vendors build it. We are the first to ship it in production, at enterprise scale. We would rather the rest of the industry followed quickly than that we held the position alone, because the models are going to keep getting more capable, and that is the one thing in this paper you can be certain of. The only question that decides how it goes is whether the systems around them get disciplined at the same rate.

If you are deploying agents faster than you can govern them, evaluating an autonomous security platform and trying to work out what is actually enforcing its boundaries, or answering a board that has started asking what your AI agents are permitted to do and who decided, that is the conversation we are built for. Ask us to show you the dial. Then go ask everyone else question one.

About SpartanX

SpartanX is The Ultimate Adversary™. The SpartanX platform runs an autonomous adversary against your organisation continuously, across seven attack surfaces, proving what is genuinely exploitable with evidence rather than asserting what might be. The External Attack Platform tests your internet-facing estate including web applications, APIs, and mobile. NodeX brings the same capability inside the perimeter, where NodeX's agents test identity, internal APIs, segmentation, and your own agentic systems from the position of an adversary who is already in. TAV closes the loop from proven finding to confirmed fix. Autonomous Exposure Management is the category this makes possible: attack, validate, remediate, and retest as one continuous cycle at machine speed.

Request a guided walkthrough or read what Autonomous Exposure Management is.

Diego Spahn is Co-Founder and Chief Executive Officer of SpartanX, which he founded with Erik Nilsen and Ryan Sheldrake. His career spans two decades, ten years in security consulting followed by ten years building security products.

Ready to see SpartanX in action?

Discover how 600+ AI agents continuously test your entire attack surface with exploit-validated proof.

Book a demo Explore the platform