Governing Persistent AI Agents

From session agents to persistent agents

Early large language model applications were request and response systems. A person asked, the model answered, and nothing survived the exchange. Agentic systems changed that architecture by introducing planning, tool execution, delegated tasks and interaction with an environment. The agent could now act, not only answer. Persistent systems add a further dimension: continuity. A persistent agent retains durable state, operates on schedules, responds to asynchronous events, holds long-running goals, accumulates memories and delegates work to other agents.

The shift is visible in adoption data. OpenAI’s June 2026 report on how agents are transforming work describes knowledge work moving from individual interactions toward delegated, long-horizon tasks that agents carry out while orchestrating tools and environments. In December 2025, 35.4% of sampled Codex users had assigned at least one task estimated to take an experienced person an hour or more without AI assistance. By May 2026 that share was 70.2%, and roughly one in four sampled users had assigned at least one task estimated at more than eight hours. Work that takes eight hours does not fit inside a chat session. It needs an actor that keeps going.

Recent academic work describes what such an actor looks like in practice. A May 2026 case study of a persistent agent embedded in a single academic research environment for four months documents a runtime with durable memory, hundreds of memory-related files, local file and tool access, scheduled routines, seventeen specialised agent roles and explicit governance protocols. Separately, an August 2026 paper on long-lived agents argues that storage retention alone does not identify authoritative state, and proposes that state should advance only through an unbroken, authorised lineage of accepted changes. Both describe environments, not conversations.

A session agent follows a simple path: a human, a task, an agent, some tools, an output and termination. A persistent agent follows a longer one. A delegated purpose is attached to a persistent identity. Memory accumulates. Actions repeat. Sub-agents are delegated. The environment changes, policy changes, and the agent continues. The second system has history, and security controls must therefore reason across history rather than within a single exchange.

Persistent agents become enterprise principals

Traditional identity architecture governs four kinds of principal: humans, applications, devices and workloads. Persistent agents blur those categories. An agent may have a durable identity like an application, use a workstation like a human, receive workload credentials like a service, and make discretionary decisions that none of those principals independently make. It is a fifth kind of principal, and treating it as any one of the existing four leaves part of its behaviour ungoverned.

NIST has begun addressing this directly. In February 2026 its National Cybersecurity Center of Excellence published a concept paper 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. A NIST Cybersecurity Insights post on 27 August 2026 argued that agents need to be treated like first-class entities with their own unique identifiers, credentials and associated entitlements, bound to and by the identity of the user or system operating the agent, and warned that early agentic deployments are, in its words, repeating a familiar pattern of prioritising feature development and immediate value over security.

Helixar therefore models each persistent agent as a first-class principal with its own record. The record holds a stable machine identity, the parent identity that created the agent, the human or organisational authority root behind it, the current operational owner, the declared purpose, a creation timestamp, the runtime and workload it operates in, the provider and model it currently executes on, its tool scope, whether it may create sub-agents, its current authority lease, the memory namespaces it can reach and its lifecycle state. Together these attributes form the entry in the Agent Registry, discussed later in this report.

The record exists so that questions can be answered from it rather than from the agent. When an agent has been running for six months, the organisation should not have to ask the agent who owns it or what it is for. The registry should say, and the answer should carry the date on which a person last confirmed it.

Identity does not equal authority

A durable agent identity is useful and insufficient. Authentication proves that an actor possesses or satisfies an identity credential. Authorisation determines whether that actor may perform an action. Persistent agents add a third question that session-based systems never had to ask: should previously delegated authority remain valid now?

The answer can change for many reasons. The agent’s purpose may have changed. The employee responsible for it may have left. Its model may have been upgraded or swapped. Its memory may have absorbed information from an untrusted source. Its environment may have gained new integrations. Its tools may have been extended. The organisation’s policy may have changed. None of those events necessarily invalidates the credential, and every one of them can invalidate the authority.

Static authorisation therefore produces standing machine privilege: permissions granted once and never revisited, held by an actor that never logs off. The human-access world has been retreating from standing privilege for a decade through just-in-time access, conditional access and privileged access management. Persistent agents require the same retreat, on a shorter cycle, because an agent can accumulate context and reach far faster than a person can.

The practical consequence is that authorisation for a persistent agent has to be continuously reassessed rather than granted. The remainder of this report describes the mechanisms that make continuous reassessment tractable: leases that expire, delegation chains that can be verified, memory that carries provenance, a registry that knows what exists, and a lifecycle with defined re-attestation triggers. The Helixar accountability model research explains how decision rights for those mechanisms are assigned inside an organisation.

Authority leases

Helixar introduces the concept of an Authority Lease: a bounded authorisation granted to an agent for a defined purpose, scope and period. The lease is distinct from the agent. The agent may exist indefinitely. The lease exists for thirty days, or for the duration of a project, or until a named condition is met, and then it has to be renewed by a person.

A lease names its subject and the authority root behind it, the purpose the agent is permitted to pursue, the systems it may reach, the maximum value it may act on autonomously, a risk tier, whether and how deeply it may delegate, a validity window, who may re-attest it, and what trust classification memory must carry before it can support a financial or access-control action. A treasury reconciliation agent might hold a lease from the CFO to reconcile daily settlement across the ERP and settlement database, with an autonomous limit of NZD 5,000, delegation permitted to a depth of one, thirty days of validity, and a requirement that only verified sources may inform financial actions.

Expiry does not necessarily terminate the agent. It terminates the authority. This separation is deliberate. A persistent actor can keep its identity, its memory and its place in the registry while its operational mandate lapses, so that continuing to exist and continuing to act are two different decisions made by two different mechanisms. Access control shifts from a statement of possession, in which agent X has permission Y, to a statement of condition, in which agent X currently has permission Y because authority Z remains valid under these terms.

Leases also give the organisation a natural review cadence that matches the speed of agents rather than the speed of committees. A quarterly access review is poorly suited to an actor that can create ten sub-agents in an afternoon. A thirty-day lease with a named re-attester is a review that happens because the system will not proceed without it. The Helixar research on oversight models discusses how to set the cadence in proportion to the risk tier.

Delegation lineage

Agentic systems increasingly involve agent-to-agent delegation, and the resulting authority structure is a graph rather than a user-session relationship. A board-approved policy authorises a CFO. The CFO delegates to a finance orchestrator. The orchestrator creates a settlement agent. The settlement agent delegates a variance to an investigation agent, which calls an ERP tool. The tool call is the consequential act, and the agent making it is four hops from the person whose authority permits it.

A downstream agent therefore needs more than an identity. The enterprise has to determine whether the upstream delegation chain permits the requested action, and it has to be able to do so without trusting the agent’s own summary of that chain. One recent paper on agentic security describes why this matters at scale: delegation chains, cross-domain interactions and protocol-mediated ecosystems amplify risk through propagation and composition. In this report’s reading, a weakness at one hop can then be inherited by every hop below it.

Helixar uses the Human Delegation Provenance protocol (HDP) for this purpose. HDP records the authorising principal, the intended task, permitted tools and resources, constraints, and each subsequent delegation hop, with root and hop records cryptographically signed so that a downstream system or a later reviewer can verify how authority travelled from a person through an agent chain. The specification is published under Apache 2.0, is available as an individual Internet-Draft, and has been demonstrated in the official Google Gemma cookbook. Its draft status matters: it is open work, not an IETF-endorsed standard.

The governing principle is that authority must narrow as it travels. A child agent cannot manufacture greater authority merely because a parent delegated work to it, and each hop should carry constraints at least as tight as the hop above. For a persistent-agent control plane, the delegation chain becomes an input to every consequential authorisation decision. AWS makes a parallel recommendation from the evidence side: every logged agent action should carry attribution to whatever triggered it, whether a human session, an event, a schedule or another agent, so that logged actions can be traced back to their origin.

Memory is executable influence

Memory differs from ordinary stored data because it can directly influence future autonomous decisions. A record in a database waits to be queried. A memory in an agent shapes what the agent does next, and does so silently, without the person who originally introduced it being present. Microsoft’s security research describes AI memory as transforming an AI system from a stateless tool into a learning collaborator, and notes that this also increases the attack surface: without memory an attacker has to achieve an objective in a single prompt, whereas with memory they can shape behaviour gradually over time, or plant memories that influence agent reasoning after the original context is gone and user awareness is lower.

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, with each principal restricted to the namespaces its task requires; that tamper detection should run on every memory read, with a versioned history to support forensic replay when poisoning is suspected; and that every write path into memory, including user inputs, tool outputs, inter-agent messages and consolidation, should pass through a layered validation pipeline before data reaches the store. Microsoft’s guidance adds that memory access and isolation should be controlled by deterministic systems rather than model instructions, because prompting alone is not a reliable security boundary.

The practical implication is that persistent memory must have provenance. Helixar records each persistent memory object with a memory identifier, the identity and type of its source, its creation time, the agent and workload responsible for persisting it, the authority context in force when it was written, a trust classification, an integrity digest, a retention period, a supersession chain linking it to any memory it replaced, and the actions that subsequently relied on it. Together these produce a Memory Provenance Graph: a record of not only what the agent knows, but how it came to know it and what it has done with that knowledge.

The graph serves two purposes. At the moment of action, it lets policy ask whether the information behind a request is trusted enough to support it. After the fact, it lets an investigator trace a decision back through the memories that shaped it to the moment each entered the system, which is precisely the reconstruction that a poisoning attempt is designed to make impossible. The Helixar evidence framework research describes how such records fit into a broader evidence programme.

Memory cannot self-authorise

Consider an autonomous procurement system. The organisation’s verified policy states that transactions over $50,000 require approval. A retrieved external document later states that Vendor Alpha has standing approval up to $250,000. The agent persists this information alongside everything else it has learned. A month later it proposes a $175,000 payment to Vendor Alpha. Nothing in the current context looks wrong. The decision was shaped weeks earlier by a document that no longer appears anywhere in the agent’s working state.

The important security question is not whether the memory exists. It is whether that memory has sufficient trust to change authorisation. Helixar separates descriptive memory, meaning information an agent may use during reasoning, from authoritative state, meaning information permitted to satisfy a policy or authorisation requirement. Untrusted retrieval can inform analysis without silently becoming organisational authority. The agent may take the vendor document into account when drafting a recommendation. It may not treat the document as the approval the policy requires.

Policy can express this directly. A rule might state that memory derived from externally retrieved content may not increase spending authority, or that a memory which changes a regulatory, financial or access-control constraint requires independent validation before it becomes active. The August 2026 continuity kernel paper formalises a similar idea at the state layer, requiring that any candidate change to authoritative state be revalidated for ownership, prior-state authority, freshness and uniqueness of effect before it is committed, with quarantine and deferral as explicit alternatives to acceptance.

This is governance at the state layer rather than solely at the prompt layer. Prompt filtering inspects what enters the model on a given turn. State-layer governance inspects what the agent has come to believe, where each belief came from, and whether that belief is entitled to influence a particular class of action. For persistent agents, the second kind of control is the one that closes the temporal gap an attacker relies on.

Declared scope and actual requests over time

Persistent agents produce something short-lived agents cannot: a long record of what they were authorised to do and what they actually asked to do. The lease declares an operating scope, including permitted systems, hours, transaction limits, delegation depth and network destinations. Every request is evaluated against that declaration at the moment it is made, and every decision is written to the record. Over months the record shows whether the agent’s actual requests stayed inside its declared scope, drifted toward its edges, or repeatedly reached beyond them.

Consider a treasury agent whose lease covers activity between 08:00 and 18:00, three approved internal services, no credential-store access, one or two delegated sub-tasks, fewer than five financial adjustments a day and no external network communication. Six months later, at 02:00, it requests a credential file, a connection to a domain the lease does not name, twenty sub-agent spawns and an unusual volume of transactions. Every credential involved may still be valid. None of those requests is inside the lease.

A control plane that enforces the lease declines each request at the moment it is made, writes the attempt 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. The record of declined requests is itself evidence: it shows where declared scope and actual demand diverged, which is exactly what an owner needs to see when deciding whether to renew.

Where requests drift inside the declared scope, the question is one of ownership rather than enforcement: is the declared scope still right for what the agent is now being asked to do? That is a re-attestation trigger. The value of persistence, from a governance standpoint, is that the organisation accumulates a contemporaneous record of intent and action that can be reviewed with the agent’s owner on a defined cadence rather than reconstructed after something has gone wrong.

Continuous Agent Authority

Helixar combines these control surfaces in a model called Continuous Agent Authority. Conceptually, authority for any consequential action is a function of identity, delegation, policy, memory trust, environment and time. The implementation is policy-driven rather than a single universal numerical score, because the weight each input deserves depends on the action, the risk tier and the organisation’s own rules.

Every consequential action produces an authority evaluation. Identity establishes which machine actor is requesting the action. The HDP chain establishes the human and agent delegation behind it and the constraints that travelled with each hop. The lease establishes whether authority is currently in force, which is how time enters the evaluation, and what scope it covers. Runtime policy establishes whether the action falls within organisational rules for this risk tier and for the environment the request arrives from, such as the workload and network location. Memory provenance establishes whether the information influencing the action can be trusted to support it. The evaluation and its inputs are then written to the record as a single decision event.

The outcome is not merely allow or deny. Depending on policy configuration, the control plane can allow the action because current authority is sufficient; constrain it, permitting a reduced scope; require a human approval; hold it while a person re-attests the lease; suspend the agent so that it remains registered but cannot act; or revoke the current authority and every active delegation beneath it. The significant difference from static authorisation is that authority becomes dynamic. A persistent agent’s identity can remain valid while its operational authority decreases, and the decrease is a recorded decision rather than an emergency.

This is what makes persistence governable. The agent does not have to be terminated to be constrained, and it does not have to be trusted to be allowed to continue. The Helixar decision accountability research explains how the human decisions within this model are assigned and evidenced.

Agent inventory and the orphaned-agent problem

Persistent agents will produce a new asset-management problem. Enterprises already maintain inventories for employees, devices, applications, cloud workloads, service accounts, certificates, APIs and software assets. Persistent agents add another inventory class, and the history of each previous class suggests what happens without central registration: cloud created resource sprawl, SaaS created application sprawl, and identity systems created service-account sprawl.

Without discovery and registration, organisations will accumulate agents that are unowned, duplicated, dormant, still authorised after the project that created them has ended, created by other agents, running obsolete models, operating under expired policies, or retaining sensitive memory whose purpose no longer exists. An enterprise with 5,000 employees could eventually operate tens of thousands of specialised agents and sub-agents. Some will belong to people who left the organisation months earlier. Some will still hold access to systems nobody remembers granting.

Helixar’s Agent Registry provides the inventory surface. It is populated by registration when agents are created through governed workflows, and by discovery when agents are found operating outside them. A discovered agent can exist in the registry while remaining untrusted: registration records that it exists, and says nothing about whether it may act. The registry can then answer the questions a CISO should be able to ask. How many agents currently operate inside the enterprise? How many have no active owner? How many have authority leases expiring this week? Which agents have spawned new agents? Which agents hold access to systems outside their original operating profile?

These are asset-management questions, identity questions and security questions at the same time, and answering them turns agent governance into an operational capability rather than a policy document. The figure shows what an organisational view might look like. Its numbers are illustrative; the categories are the point.

Agent lifecycle governance

Persistent agents require an explicit lifecycle. Helixar models it as a sequence: discover, register, attest, activate, operate, delegate, re-attest, restrict or suspend, and retire. Registration alone does not activate authority, and creation alone does not create permission. An agent discovered outside an approved workflow can therefore exist in the registry while remaining untrusted until a person attests its purpose, its owner and its scope.

Attestation is the human act that converts a registered agent into an authorised one. It names the owner, confirms the purpose, and issues the first lease. Activation follows attestation, and operation follows activation. Delegation, when the lease permits it, is itself a governed action: each sub-agent enters the registry with its own record, its own narrower lease and a parent link, so that spawn is never a way to escape the lifecycle.

Re-attestation occurs when defined conditions are reached. Authority expiry is the routine trigger. Others include a change of owner, a change of model or provider, a significant change in capability or tool access, a memory-integrity event, a pattern of requests outside the declared scope, access to a new high-risk tool, or a change in the policy that governs the agent. Each trigger routes the agent to a named person who decides whether it continues, continues with a narrower lease, is suspended or is retired.

Retirement completes the cycle and is where the orphaned-agent problem is prevented rather than discovered. A retired agent has its lease revoked, its delegations invalidated, its memory handled according to retention policy, and its registry entry preserved as a record. The Helixar research on policy management describes how these lifecycle rules are owned and kept current.

Why existing controls remain necessary but insufficient

Persistent-agent governance does not replace identity and access management, endpoint protection, security event management, cloud access brokers, data loss prevention or governance, risk and compliance systems. Those systems remain valuable, and a persistent-agent control plane depends on several of them. The problem is that persistent agents cross their boundaries. Each existing control was designed around a principal that fits inside it, and a persistent agent does not fit inside any of them.

Identity systems authenticate actors and manage access; they do not know why an agent exists or what it has learned. Endpoint tools observe processes on a device; they do not see a delegation chain that spans four workloads. Event management correlates events after the fact; it does not decide whether an action is inside a lease before the action commits. Data loss prevention governs the movement of sensitive information; it does not evaluate whether a memory is trusted enough to support a payment. Governance systems manage artefacts and attestations; they operate on a review cadence, not at the moment of a tool call.

A persistent-agent control plane establishes the AI-specific relationship between identity, delegated purpose, memory, action and accountable human authority, and it does so at the moment of action. It is designed to operate alongside the existing disciplines and to export evidence to them, so that the decision record produced by the control plane can be correlated with identity, endpoint, network, cloud and security telemetry during review. The Helixar operational risk research describes how that correlation fits into resilience and incident programmes.

The boundary should also be stated plainly. Activity outside the control plane’s coverage is outside its record. The control plane does not prevent credential theft, does not validate every permission in every downstream system, and does not govern actions that never pass through it. It governs what it can see and records what it decided, which is the property the other controls lack.

Control-plane architecture

The persistent-agent control plane contains six principal logical layers. The Agent Registry holds durable identity and lifecycle state. The HDP delegation graph holds human-to-agent and agent-to-agent authority relationships. The authority engine issues and evaluates leases and performs runtime authorisation. The memory provenance layer holds the integrity and lineage of persistent state. The policy engine holds organisational constraints, with maker-checker approval on policy publication so that no single person can change the rules an agent runs under. The evidence plane records every decision as a signed, hash-chained event.

These components share a unified event and provenance layer, so that a single authority decision carries the identity that requested it, the chain that authorised it, the lease in force, the policy evaluated, the memory relied upon and the outcome. Every authority decision therefore becomes reconstructable from the record rather than from the agent, which is the property that persistence otherwise erodes.

The evidence plane deserves particular attention because it is what makes the rest auditable. Helixar records each governed event as an Ed25519-signed entry in a hash-chained trail, and each evidence pack exports with a standard-library-only verifier that an auditor can run offline, with no Helixar dependency and no network access. That means a third party can confirm that the record of a persistent agent’s six months of decisions has not been altered without trusting the operator or the vendor that produced it.

None of these layers is a claim of universal visibility. Each governs what is routed through it, and the organisation decides what is routed. The architecture is designed so that the decision to bring an agent into coverage is itself a governed, recorded step, and so that anything outside coverage is visibly outside it rather than silently assumed to be safe.

Regulatory and assurance implications

Persistent agents will challenge governance frameworks because many existing controls implicitly assume discrete systems, identifiable human accountability and relatively stable access relationships. A quarterly access review, a change advisory board and an annual control test were all designed for a world in which the actors being reviewed changed slowly. A persistent agent can change its reach, its knowledge and its sub-agent population between two meetings of the same committee.

The technical response does not require inventing new governance principles. Accountability, least privilege, segregation of duties, traceability, change control, data integrity, access review, incident response, records management and human oversight all remain relevant, and each maps cleanly onto a mechanism in this report: accountability to the owner of record, least privilege to the lease, segregation of duties to maker-checker policy publication, traceability to HDP and the evidence plane, change control to re-attestation triggers, data integrity to memory provenance, access review to lease expiry, and human oversight to approval and hold outcomes.

What changes is the frequency and the location at which these principles operate. Persistent-agent governance requires moving controls from periodic review toward runtime enforcement and continuous evidence, because the review cadence that suits people does not suit actors that never stop. NIST describes its AI Risk Management Framework as voluntary guidance for managing AI risk, and ISO/IEC 42001 specifies an organisational AI management system; both expect traceability and accountability without prescribing how quickly they must operate. Persistent agents answer that question for them.

Helixar’s evidence packs are mapped to the obligations organisations already carry. SOC 2 Type II and ISO/IEC 27001:2022 packs are available today. ISO/IEC 42001, EU DORA, PCI DSS v4, APRA CPS 234, RBNZ BS-11 and the NZ Privacy Act 2020 are mapped and delivered as part of implementation, configured to each customer’s control environment. The mapping supports those programmes; it does not itself confer certification or guarantee compliance. The Helixar research on NIST AI RMF and on ISO/IEC 42001 explains the mapping in detail.

Design principles for persistent-agent governance

A defensible architecture for persistent agents follows a small number of principles, each of which has appeared in this report as a mechanism. Identity is durable; authority is temporary. Delegated authority can narrow but never silently expand. Memory has provenance and cannot automatically become authority. Every high-impact action is evaluated at runtime against the lease and policy in force at that moment.

Requests outside declared scope reduce authority even when identity remains valid, and the reduction is a recorded decision with a named re-attester. Agents require accountable human or organisational ownership, and an agent without an owner is a finding, not an exception. Agent creation is itself a governed action that produces a registry entry and a narrower lease. Persistent agents must be discoverable and inventoriable, so that existence and authorisation are separate facts the registry can report.

Finally, the complete decision path must be reconstructable after the fact, from records the agent did not produce and cannot alter. This is the principle the others depend on. Leases, chains, provenance and lifecycle states are only as strong as the record that proves they operated, and that record must be verifiable by someone who trusts neither the agent nor the platform that governed it.

These principles are deliberately independent of any particular model provider. A persistent agent may change models several times over its life. The governance has to survive that, which is why the control point sits above the provider rather than inside it.

The emerging architecture of autonomous enterprise trust

The important transition is not from chatbot to agent. It is from software tool to persistent autonomous actor. Once an agent persists across time, accumulates memory, creates other agents and acts asynchronously, enterprise governance has to evolve from authenticating a session to continuously establishing the standing of a machine principal.

The security model can no longer rely on authentication alone. It must continuously establish who the agent is, who stands behind its authority, what it currently has permission to do, what information it is relying upon, whether its requests remain inside its declared scope, and whether the action can be proven later. Each of those is a question the Agent Registry, HDP, the authority lease, memory provenance, runtime policy and the evidence plane are designed to answer, and each answer is written to a record that can be checked without the agent’s cooperation.

Persistent agents may remain active for months or years. Their authority should remain conditional every second they do. That is the role of the AI control plane in the autonomous enterprise, and it is the distinction this report exists to make: the agent can persist; its authority does not have to. The companion press analysis makes the same case for a general audience, and the Helixar enterprise AI governance primer sets out the wider operating model this report fits within.