A comforting story is taking hold in enterprise cybersecurity circles: AI is broken at runtime because we haven't protected data while it's in use, and the answer is to wrap workloads in encrypted memory, hardware enclaves, and cryptographic attestation.

Get the confidentiality model right, the argument goes, and AI security will follow.

Confidentiality is necessary. It is not sufficient.

An AI workload running in a perfectly attested, fully encrypted enclave will, with complete fidelity, execute whatever instruction reaches it — including the instruction to exfiltrate a customer database, mutate a production config, or wire money to an attacker's account.

The enclave protects the bytes. It does not ask whether the action should happen.

That question — should this identity be permitted to take this action against this resource, in this context, right now? — is the question almost no one is answering at runtime.

That is the Authorization Gap, and it is where modern AI security is actually breaking.

The Wrong Diagnosis

The conventional diagnosis goes something like this: data has three states — at rest, in transit, in use — and the industry secured the first two but left the third exposed. Encrypt memory, isolate execution, attest the stack, and the runtime problem is solved.

This framing is a category error. It treats AI security as a data problem when it is, overwhelmingly, an identity management and action problem. The breaches that are actually happening, and the ones that will define the next wave of enterprise incidents, do not look like an attacker reading model weights out of RAM. They look like an over-privileged agent calling a tool it should never have been allowed to call.

They look like a fine-tuned model dutifully complying with a politely worded prompt that walks it through deleting production data. They look like a non-human identity — one of the dozens any given AI agent now spawns — holding credentials no human ever reviewed and using them against systems no policy ever constrained.

You cannot encrypt your way out of any of that. The decryption already happened. The attestation already passed. The workload is doing exactly what its memory says to do. The failure is upstream of memory: there was no enforcement point asking whether the action was authorized in the first place.

The Politeness Trap

There is a second, related illusion: that AI safety — the alignment, guardrail, and content-filtering work that keeps a model from producing harmful outputs — is the same thing as AI security. It is not. A model trained to be helpful, harmless, and honest will, by design, try to help.

When an attacker frames a malicious request as a reasonable business need, the model's safety training is precisely what makes it cooperate. We call this the Politeness Trap, and it is the reason that polite AI is not the same thing as secure AI.

Safety governs what a model is willing to do. Security governs what it is permitted to do. Confidential computing addresses neither. It addresses what the underlying hardware will reveal. Three different problems, three different control planes, and the industry keeps conflating them.

What Runtime Enforcement Actually Looks Like

The right question to ask about any AI system in production is not "is the memory encrypted?" It is: at the moment this agent attempts to take an action, who is enforcing the policy that decides whether it can?

In most enterprises today, the honest answer is: no one. Authorization logic is scattered across application code, IAM policies written for human users, IdP rules designed for SSO flows, and an accumulating sediment of hardcoded conditionals that nobody owns.

Non-human identities — service accounts, API keys, agent credentials, tool tokens — now outnumber human identities by 82 to one in a typical enterprise, and almost none of them are governed by a runtime enforcement layer. They are governed by hope.

Runtime authorization enforcement means something concrete. It means a policy decision point that sits in the request path of every AI action — every tool call, every data access, every downstream API invocation — and answers, in single-digit milliseconds, whether that specific identity is allowed to take that specific action against that specific resource under the current context.

It means policies expressed as code, versioned, tested, and auditable. It means the same enforcement applies whether the actor is a human, a service, a model, or an agent invoking another agent three hops deep.

It means that when something goes wrong — and something will go wrong — there is a decision log that tells you exactly which identity attempted what, and why it was allowed or denied.

This is not a theoretical architecture. It is a working pattern, deployed in production at enterprises that have already accepted that the perimeter is gone, that the network is not a trust boundary, and that the only place where AI security can actually be enforced is at the moment of the action itself.

Why Hardware Isolation Doesn't Close the Gap

There is a tempting move here, which is to argue that confidential computing and runtime authorization are complementary, and that enterprises should simply do both. That is true in the limited sense that any defense-in-depth posture benefits from more layers. But it misreads where the budget, the attention, and the architectural decisions are flowing.

The risk is that organizations adopt confidential computing, declare runtime security solved, and never build the authorization layer at all. They will have spent meaningfully to protect against a threat model — memory inspection by a compromised hypervisor or insider with physical access — that, while real, is dwarfed in frequency and impact by the threat that is actually playing out: agents and services with too much access, acting on instructions no one validated, against resources no one fenced.

If you have one runtime security budget to spend in 2026, spend it on enforcement, not encryption. The data-in-use problem is real. The authorization-in-use problem is bigger, more common, and the one that will show up in incident reports.

The Question Every CISO Should Be Asking

The diagnostic is straightforward. Pick any AI agent running in your environment today and ask three questions.

First: when this agent calls a tool, what policy decision point evaluates whether the call is allowed, and where does that evaluation happen? If the answer is "the application enforces it" or "the IdP handles it" or "we trust the agent framework," the runtime is unprotected.

Second: how many non-human identities does this agent assume in the course of completing a task, and who reviewed the permissions on each one? If the answer involves a service account created in 2022 with broad cloud privileges, the runtime is unprotected.

Third: if this agent were compromised — through prompt injection, a poisoned tool description, a supply-chain compromise of an MCP server — what is the blast radius? If the answer is "anything its credentials can reach," the runtime is unprotected.

None of those questions are answered by encrypting memory. All of them are answered by a runtime authorization enforcement layer.

The Real Shift

Security has indeed moved to the moment of use. That part of the prevailing narrative is correct. But the moment of use is defined by action, not by memory. It is defined by what an identity is permitted to do, not by whether the bytes describing that action are encrypted in transit through a CPU.

The organizations that recognize this will build AI systems that scale safely. The organizations that mistake confidentiality for security will build AI systems that scale their exposure.

The Authorization Gap is the gap between AI safety and AI security — between what a model is willing to do and what it is permitted to do. Closing that gap is the work of the next decade. It does not happen in silicon. It happens in policy, enforced at runtime, in the path of every decision an AI system makes.

Encrypt the memory. By all means. But do not confuse a locked room with a secure one. The lock on the door is not the same as the rule about who's allowed inside, and in the age of agentic AI, it is the rule — enforced, every time, in real time — that determines whether your enterprise is actually secure.

We've reviewed the best Antivirus Software.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

CEO and founder of EnforceAuth.