Most of the AI security market right now is doing platform work. This is a symptom of the journey we have been on regarding our usage (more accurately unintended usage) of AI agents. The problem is that AI is being incorporated into every aspect of our technology, from vendors that you are using, to staff relying on ChatGPT, to curious developers spinning up OpenClaw at work.

The first piece of securing AI is understanding where AI is in your environment, and that is why we’ve seen so many AI security companies build a centralised platform that gives organisations visibility. Let’s be clear, this is needed. However, these platforms live at the web gateway or network layer - seeing what agents do based upon the traffic they produce, and alerting security teams when an agent has done something it shouldn’t. Given the pace at which agents can cause harm when they go wrong, this shouldn’t be considered anything other than a short-term solution to this problem.

For enterprises to truly adopt agentic AI with confidence they need something which is much more deeply integrated. This has spawned a new wave of security tools, known as ‘runtime’ security for AI agents. Runtime security tools have been around for many years across many different technologies, so this was always going to be the direction of travel. EDRs are the perfect example - runtime security tooling for your staff laptops.

As many of you will know, we are building a runtime security monitoring system at Secure Agentics, and something recently came across my feeds which was one of the more satisfying reads that I have had in some time: AARM

AARM: Autonomous Action Runtime Management

TL;DR AARM is an open specification, authored by Herman Errico (Senior PM at Vanta) with a Technical Working Group that includes people from Elastic, Darktrace, Truist, Gusto, Ballistic Ventures and IEEE. It defines what a runtime security system for AI agents has to do to provide meaningful security, in very clear terms. It does not tell you how to build them, but agrees as a community what these tools must be capable of. The core idea is that the action boundary, the moment an agent tries to take an action, is the security boundary.

AARM lays this out better than I’ve seen it laid out anywhere else and it was one of those rare times where you’ve been working on a problem for some time, arrived at many sensible conclusions about how something should be done, and then you read something which confirms that all of the ideas you had were indeed the right ones. They identify several characteristics of AI agents that break traditional security thinking and resonated with how we are thinking about AI security:

• Irreversibility. You can filter a bad sentence out of a model’s output. You can’t un-send an email, un-drop a table, or un-wire a payment. Tool executions produce permanent effects at the moment they fire.

• Speed. Humans manage two to five meaningful actions a minute. Agents run hundreds. Your reviewer queue cannot keep up, and any process that assumes it can is short-sighted.

• Contextual risk. Each action in a sequence can be individually permitted whilst combining them is a breach. Read customer records - fine in some cases. Send an email - fine in some cases. Both together: data exfiltration.

None of this is solved by a dashboard. SIEM tells you what happened after an event. API gateways verify who is calling, not what the call means in context. Firewalls protect your external perimeters whilst agents can cause harm in your internal environment. Guardrails filter text, not risky actions in the context of that agents role. IAM evaluates permissions in isolation and has no idea that reading customer followed by sending email to external is the problem. Human-in-the-loop sounds comforting until you realise it is a terrible security recommendation.

So, where does that leave you if you’re genuinely trying to secure an agentic system? This is the gap AARM is explicitly trying to fill.

What the spec actually requires

AARM defines components, behaviours, and conformance requirements, and leaves the implementation to whoever wants to build these systems, which is the right move.

An AARM-conformant system has to do five things in sequence:

1. Intercept every AI-driven action before it reaches the target system.

2. Accumulate context in an append-only, hash-chained log. The user’s original request, prior actions, data classifications, tool outputs, etc.

3. Evaluate the action against both static policy and contextual intent alignment. Does this action match what the user actually asked for?

4. Enforce one of five decisions: allow, deny, modify, step-up (require human approval), or defer (suspend until context is sufficient).

5. Record a cryptographically signed receipt binding the action, the context, the decision and the outcome.

The spec then lays out nine conformance requirements, six of which are MUST, and three are a SHOULD.

Architectures

The spec defines four implementation architectures:

• Protocol gateway: sit between the agent and its tools, typically as an MCP proxy or similar. Context is limited because you only see what is on the wire - this is where most AI security tools currently sit.

• SDK / instrumentation: embed in the agent framework at the source code level. Deep integration and highest context richness because you see everything.

• Kernel / eBPF: even lower-level integration, hooking into the system internals of the machine the agent is running on. Useful for catching stuff everything above this would miss, but a part of the solution not the entire thing.

• Vendor integration: hooks into SaaS vendors agents. Good when you can get them, but change vendor to vendor.

Why this matters

The market today is mostly selling platforms that try to cover every AI security concern at once. Posture management, model risk, evals, observability, guardrails, compliance, governance, etc. The value is breadth, ticking every box at once.

This makes sense in the early days, but to secure a truly agentic future we need to be going much deeper and for that breadth is not the answer. The answer is giving security teams the tools that empower them to truly control their agents - stopping harmful actions before harm takes place, analysing it’s risk in session and organisational context, tying together integrations from the top of the stack to the bottom, not just sitting in web logs.

For this genuine security approach AARM is the best thing yet for defining exactly how and what we need to be doing and giving everyone a shared vocabulary. Now, when somebody tells you they’ve got “AI agent security,” you can ask: do you do R1 through R6? Is your enforcement pre-execution or post-hoc? Where do you sit in the architecture stack? Can you track contextual risk across a session?

The value of this spreads from vendor vetting, to product roadmaps, to compliance requirements. With how comprehensive and on-the-money even the first version of this spec is we’re now sure that this will continue to become a benchmark for the entire community moving forward. We, here at Secure Agentics, are fully on board and are keen to continue to evolve this in line with agentic AI and as the security community finds its feet in this new terrain.

Until next time!