Persistent AI Agents Are Coming. Enterprise Security Is Not Ready for an AI That Never Logs Off.

The first generation of enterprise AI was easy to picture. A person opened an interface, asked a model a question, read the answer, and the interaction ended. Agentic AI changed that picture. Agents now plan, call tools, reach systems, manipulate files and carry work forward without a human decision at every step. The next shift is more consequential. The agent does not disappear when the task ends. It remains. It remembers. It wakes on schedules and triggers, it may start new work and delegate to other agents, and it gradually learns the organisation it operates inside. This is the persistent AI agent, and it changes the enterprise security problem in ways that identity, endpoint and logging tools were never designed to answer.

From AI session to machine actor

OpenAI's June 2026 report on how agents are transforming work describes knowledge work moving away from individual interactions and toward delegated, long-horizon tasks that agents carry out while orchestrating tools and environments [1]. The numbers behind that description are striking. In December 2025, 35.4% of sampled Codex users had assigned at least one task that would take an experienced person an hour or more. By May 2026 that share was 70.2%, and roughly one in four sampled users had assigned work estimated at more than eight hours [1].

A persistent agent is not a chatbot with better memory. It is a long-lived software actor with identity, state, authority and history. Consider a finance agent that remains active for twelve months. Every morning it reconciles transactions. It investigates anomalies, reads email, queries internal databases, corresponds with vendors and creates tasks for specialist sub-agents. On day one the organisation knows exactly why it exists. By day 180 the questions are harder.

Traditional IAM can authenticate a service identity. Endpoint tooling can observe a process. Logging can record an event. None of those mechanisms, on its own, answers whether a persistent autonomous actor should still be trusted to perform this particular action now. That is a control-plane question, and it is a new one.

Identity is only the beginning

NIST has started examining the problem directly. Its National Cybersecurity Center of Excellence published a concept paper in February 2026 on accelerating the adoption of software and AI agent identity and authorisation, inviting comment on the identification, authorisation, auditing and non-repudiation of AI agents, and on controls to prevent and mitigate prompt injection [2]. A NIST Cybersecurity Insights post on 27 August 2026 went further. It warned that early agentic deployments are “repeating a familiar pattern: prioritizing feature development and immediate value over security”, and argued that agents need to be treated as first-class entities with their own unique identifiers, credentials and entitlements, bound to the identity of the user or system operating them [3].

That work matters, and it is also only the beginning. An agent having an identity does not mean the action it is attempting is authorised.

Before that transfer moves, the enterprise needs to establish who delegated this authority and for what purpose, whether this transaction sits inside the delegated scope, what information influenced the decision, whether current policy permits the action, and whether a person needs to approve it. The distinction between identity and authority is the fundamental one in persistent agent systems.

Authority should expire even when the agent does not

Human access has been moving for years toward just-in-time privilege, conditional access and privileged access management. Persistent agents need an equivalent. Helixar calls it an Authority Lease. The agent can stay alive indefinitely while the authority delegated to it remains deliberately temporary.

After thirty days the agent does not necessarily stop. Its authority does. A person has to attest that the agent still has a legitimate purpose and that the scope remains appropriate. Access control shifts from “Agent X has permission Y” to “Agent X currently has permission Y because authority Z remains valid under these conditions.” For a machine actor that never logs off, that difference is the whole point.

Memory becomes part of the security boundary

Persistence brings a second problem: memory. Microsoft's security team put it plainly in June 2026 [4].

AI memory transforms an AI system from a stateless tool into a learning collaborator. That unlocks powerful experiences, but it also increases the attack surface of the AI system.

Without memory, an attacker has to achieve their objective in a single prompt. With memory, in Microsoft's words, they can “shape behavior gradually over time or plant memories that influence agent reasoning after the original context is gone and user awareness is lower” [4]. AWS reaches the same conclusion from the architecture side. The Well-Architected Agentic AI Lens states that agent memory should be partitioned along the isolation axes that matter for the workload, that tamper detection should run on every memory read with a versioned history to support forensic replay, and that every write path into memory, including tool outputs and inter-agent messages, should pass through validation before data reaches the store [5].

The principle that follows is simple to state and hard to live with: an agent's memory cannot automatically be treated as truth.

That is why enterprises need memory provenance. Helixar records the lineage of persistent memory: where it originated, which workload wrote it, what trust classification applies, when it was introduced, what authority existed at that point and which later actions relied upon it. Policy can then draw a line that prompt filtering never could. Untrusted memory may inform analysis, but it cannot on its own satisfy the authorisation requirements for a high-impact action. The question stops being “what does the agent remember?” and becomes “why does it believe this, and is that belief trusted enough to influence this action?”

Delegation becomes a graph

Persistent agents also create other agents. A finance orchestrator starts a reconciliation agent, which delegates research to an investigation agent, which invokes a data-analysis tool, which modifies an enterprise system. The final agent may never have interacted with the person whose authority ultimately permitted the task.

Recent academic work on agentic security describes the same amplification: delegation chains, cross-domain interactions and protocol-mediated ecosystems compound risk through propagation and composition [7]. AWS's guidance on agent logging makes the point from the evidence side, recommending that every logged action carry attribution to whatever triggered it, whether a human session, a schedule or another agent [6].

This is why Helixar's Human Delegation Provenance protocol (HDP) treats authorisation as a chain rather than a single token. Each delegation hop retains a cryptographically verifiable relationship with its parent, so the chain of authority can be checked without relying on the agent's own explanation of why it acted [8][9]. HDP is published as an open Internet-Draft under Apache 2.0; it is open work, not an IETF-endorsed standard. Persistent agents make that property essential. If an autonomous actor can operate for months, the organisation must be able to reconstruct who authorised what, who delegated to whom, which restrictions travelled with each delegation, and which authority ultimately produced an action.

The enterprise will need an Agent Registry

Cloud created resource sprawl. SaaS created application sprawl. IAM created service-account sprawl. Persistent AI will create agent sprawl. An enterprise with 5,000 employees could eventually operate tens of thousands of specialised agents and sub-agents. Some active, some dormant, some abandoned. Some with valid owners, some belonging to employees who left six months earlier, some still holding access to systems nobody remembers granting.

The enterprise therefore needs an inventory of autonomous actors. Helixar maintains a persistent Agent Registry that records identity, owner, purpose, lineage, current authority lease, memory namespaces, deployment location, model and provider relationship, and lifecycle state. A CISO should be able to ask how many agents currently operate inside the enterprise and get a number. Then:

These are asset-management questions, identity questions and security questions at the same time.

Authority has to be re-evaluated at the moment of action

A persistent agent changes over time. Its environment changes. Its memory changes. Its tools change. Its model may change. Its owner may change. Authorisation that was correct on the day of delegation cannot be assumed correct on day 180.

Helixar therefore treats authority as something evaluated at the moment of action rather than granted once. Each consequential request is checked against several independent inputs: the agent's identity, the HDP delegation chain behind it, the current lease, the runtime policy in force, and the provenance of any memory the action relies upon. The result is not only allow or deny.

Consider a treasury agent whose lease covers three internal systems, business-hours activity, fewer than five financial adjustments a day, no credential-store access and no external network destinations. At 02:13 it requests a credential-store read and a connection to an endpoint the lease does not name. Its identity is valid. The requests are outside its authority. A control plane that evaluates each request against the lease declines them at the moment they are made, writes the attempts to the tamper-evident record, and can hold the lease for human re-attestation. No signature of a known attack is required, and the decision does not depend on the agent's own account of what it was doing.

Zero Trust is moving from users to autonomous actors

The security industry spent the last decade retiring the assumption that a user should be trusted because they are inside the network. Persistent agents force the next transition: do not trust the agent because it authenticated successfully. Every consequential AI action should be evaluated against current authority and current context. In short:

The agent may be legitimate. The credential may be legitimate. The model may be legitimate. The requested action may still be wrong.

This is also why persistent agents cannot be governed purely at the model layer. Their risk lives across identity, memory, delegation, tools, networks, enterprise systems and time. The control point has to sit above any individual model provider.

The AI control plane is becoming the trust layer for machine actors

Visibility is no longer enough. Prompt filtering is not enough. API logging is not enough. Agent identity alone is not enough. Enterprises need to answer four questions, continuously.

Helixar is designed to answer those questions across providers and workloads through one control plane: cryptographic delegation provenance, persistent-agent identity, authority leases, memory provenance and runtime policy enforcement, with every decision written to a tamper-evident record that can be verified offline. Scope and coverage depend on deployment and policy configuration, and are validated in paid pilots.

The agent can persist. Its authority does not have to. That distinction may become one of the defining security principles of the autonomous enterprise.