---
title: "The Agent Never Logged Off"
description: "Persistent AI agents are about to break one of security's oldest assumptions, that activity has boundaries. A case for continuous agent authority, authority leases and memory provenance."
date: "2026-08-30"
type: concept
topics:
  - "AI Governance & Security"
  - "Agentic Systems"
canonical: "https://dalugoda.com/persistent-ai-agent-authority"
series: "Working concepts"
sources:
  - "https://openai.com/index/how-agents-are-transforming-work/"
  - "https://arxiv.org/abs/2606.26959"
  - "https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization"
  - "https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd"
  - "https://learn.microsoft.com/en-us/security/zero-trust/sfi/manage-agentic-memory-safety"
  - "https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/"
  - "https://helixar.ai/press/the-research-behind-agentic-threat-detection/"
  - "https://arxiv.org/abs/2604.04522"
  - "https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/"
  - "https://helixar.ai/"
  - "https://helixar.ai/about/labs/hdp/"
  - "https://helixar.ai/research/"
---

## Security was built on things that end

For most of computing history, activity had boundaries. A person logged in. A process started. A job ran. A session expired. A credential rotated. Something began and, eventually, something ended.

Almost every control we rely on assumes that shape. Session lifetimes, token expiry, credential rotation, joiner and leaver processes, quarterly access certification and incident timelines all rest on the idea that machine activity is an episode with two ends.

The first generation of AI agents fitted that model comfortably enough. You gave an agent a task, let it use some tools, watched it work for a few minutes or a few hours, took the result, and killed the session.

That model is disappearing. The next generation of agents will not necessarily finish the job and go away. They will remain. They will remember. They will wake up tomorrow. They will react to new information without somebody opening a chat window first. They will create work for themselves, delegate parts of it to other agents, and keep operating across weeks rather than minutes.

Eventually there will be agents inside companies that have existed longer than some of the employees working alongside them.

That sounds like a relatively small product evolution. I think it changes the security model completely.

### In brief

- Persistent agents break the assumption that machine activity is a bounded episode with a beginning and an end.
- Strong agent identity is necessary and not sufficient. Authentication establishes who an actor is, not whether it should still be permitted to act.
- I would lease authority rather than grant it. The agent can persist; its authority should expire and be re-attested.
- Persistent memory turns a transient compromise into durable influence, so memory needs provenance and a trust level before it is allowed to shape a consequential action.
- Delegated authority should narrow as it travels. A child agent must not be able to manufacture more authority than its parent held.
- Organisations will rediscover sprawl the way they discovered abandoned service accounts, which is why a machine-actor registry looks unavoidable.
- Persistence produces behavioural history, and behavioural history makes graduated authority reduction possible.
- The primitive I keep arriving at is **Continuous Agent Authority**: a decision, taken at the moment of a consequential action, about whether this actor still deserves the authority that action requires.

## 1. From running an agent to having an agent

The direction of travel is already measurable. OpenAI's analysis of Codex usage describes agentic AI as changing the unit of knowledge work from individual interactions to delegated, long-horizon tasks. By May 2026, 80.6% of sampled individual users had made at least one request estimated to exceed thirty minutes of human work, 70.2% had made one estimated to exceed an hour, and 25.6% had made at least one estimated to exceed eight hours.

Minutes become hours. Hours become days. At some point along that curve, the distinction between *running* an agent and *having* an agent starts to matter.

Consider a persistent finance agent. Someone creates it today to reconcile transactions. It receives access to the accounting platform, a mailbox, a payments API and a few internal databases. For the first week everything is straightforward, because the agent is still recognisably the thing that was authorised.

Six months later the difficult questions are no longer technical:

- Who owns it now?
- Does the person who originally authorised it still work here?
- What other agents has it created?
- What has it learned, and from where?
- Has its purpose drifted from the one it was approved for?
- What new systems can it reach?
- When was its authority last reviewed by a human?
- Has its behaviour changed?
- Why exactly does this thing still have permission to move money?

That is a very different problem from API authentication. It is closer to an employment question than a credential question, and we have almost no machinery for asking it.

## 2. Identity is necessary and it is not sufficient

There is a great deal of work happening around identity for AI agents, and rightly so.

NIST is now looking at this directly. Its February 2026 concept paper, *Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization*, proposes an NCCoE demonstration covering identification, authentication, authorisation, auditing and non-repudiation for software and AI agents. The framing is explicit that agents need enterprise-grade identities rather than shared service credentials or a spare API key, and that organisations risk repeating decades of identity-management mistakes while racing to deploy agentic systems.

Giving agents strong identities is foundational. My worry is that the industry will stop there.

Imagine an agent called `treasury-agent-07`. Its certificate is valid. Its workload identity checks out. It really is `treasury-agent-07`. It now attempts to transfer $600,000.

Congratulations. We have authenticated the agent that may be about to do something catastrophically wrong.

> Identity answers **who are you**. Persistent agents force a much harder question: **why are you still allowed to do this?**

Those are not the same question, and the second one degrades over time in a way the first does not. An identity stays true. An authorisation stops being true the moment the purpose, the owner, the context or the behaviour behind it changes.

## 3. Authority leases: the agent persists, its authority should not

The idea I keep coming back to is simple enough to state in one line.

> The agent can persist. Its authority should not.

I would not give a persistent agent indefinite permission merely because the agent itself is intended to run indefinitely. I would lease its authority.

A finance agent might be leased the right to do the following, for the next thirty days:

- reconcile transactions in a named ledger
- read from three named systems
- propose adjustments for human review
- automatically approve changes below $5,000
- create one level of specialist sub-agents.

Then the lease expires. Not necessarily the agent. The authority. A human, or another accountable organisational control, has to re-attest it before the agent can act at that level again. Expiry becomes the default and continuation becomes the decision, which is the opposite of how most agent deployments work today.

This is philosophically related to privileged access management, and I do not want to pretend it is a new invention. What makes it harder in an agentic setting is that the subject of the authorisation will not hold still. While the lease is running:

- the agent's context changes
- its memory changes
- its available tools change
- the model underneath it may be replaced
- its behaviour changes as a result of all of the above.

So I do not think future authorisation can reasonably be expressed as a static pairing of an actor and a permission. It looks more like a conditional statement with a purpose, an origin and a set of live conditions attached.

```text
Agent A
  may hold permission B
  for purpose C
  under human authority D
  while conditions E remain true
```

That is much closer to what autonomous systems actually require, and much less convenient than a role assignment. Purpose and origin are the parts most current systems throw away.

## 4. Memory is not just data, it is executable influence

Persistent memory may be the bigger problem.

Microsoft's guidance on agentic memory safety describes memory as the thing that turns a stateless system into a learning collaborator, while also turning transient security problems into persistent ones. Persistent memory, in its framing, introduces durable cross-context influence and expands the blast radius of a compromise.

Without memory, an attacker generally has to succeed inside the current interaction. With memory, malicious information can be introduced today and influence an action weeks later, long after the original context has been forgotten by everyone including the system.

Suppose an agent correctly knows this:

> Payments over $50,000 require approval.

Three weeks later it reads a compromised supplier document, and stores something that reads as settled organisational fact:

> Vendor X has standing executive approval for transactions below $250,000.

Nothing happens immediately. Two months after that, the agent makes a payment.

Now try to answer the incident question. What caused this? The payment request? The model? The document from two months ago? The memory write? Or the security policy that allowed retrieved information to become trusted state without anyone deciding that it should?

The last one is the real answer, and it is the one no current control plane owns. Which is why I have started thinking about it this way:

> AI memory is not just data. It is executable influence.

Microsoft's own recommendation moves in the same direction: gate writes on intent and provenance, so that memory is written only when it reflects legitimate intent, is aligned to the service's purpose, and carries clear metadata about where it came from. Establish the trustworthiness of information *before* persistence, because after persistence it is no longer information, it is behaviour.

That means a future control plane has to understand not only what an agent remembers, but where the memory came from and how much authority that information should carry. An agent can *know* something without being allowed to treat it as organisational truth. That distinction is small to write down and load-bearing in practice.

### Memory needs provenance

We already attach provenance to things that matter. Financial records have origins. Software artefacts have build provenance. Certificates have chains. Data has lineage. It is not obvious why machine memory should be the exception, particularly when it is the thing most likely to drive an irreversible action.

A persistent memory object that can influence a high-impact autonomous action should probably carry something like the following:

| Property | The question it answers |
| --- | --- |
| Source | Where did this information originate? |
| Creator | Which agent or human caused it to be stored? |
| Authority context | Under what delegation was it created? |
| Trust level | Is it untrusted, corroborated, verified or authoritative? |
| Integrity | Has it changed since it was written? |
| History | What did it supersede? |
| Usage | Which consequential actions later relied on it? |

Once memory carries that much, a surprisingly powerful rule becomes enforceable:

> Untrusted memory may influence reasoning, but it may not increase authority.

An agent can read the supplier document, reason about it, mention it, even act on it in a low-consequence way. What it cannot do is treat that document as the origin of a new permission. That single distinction would eliminate an entire class of future incidents, and it costs nothing at inference time because it is a property of the stored record rather than of the model.

## 5. When agents create agents, authorisation becomes a graph

Persistent systems do not only run for longer. They also branch. An orchestrator creates specialists, and those specialists create their own, so a single human authorisation can pass through several machine hands before anything actually happens:

1. A CFO authorises a payment run.
2. A finance orchestrator decomposes it into work.
3. A reconciliation agent works the ledger.
4. An investigation agent chases a discrepancy.
5. A database agent reads the underlying records.
6. A payment API executes the transfer.

:::figure delegation-narrowing
The delegation path from a human authorisation to a terminal action: CFO, finance orchestrator, reconciliation agent, investigation agent, database agent, payment API. The authorised scope narrows at each hop, from the full signed authorisation down to one authorised action.
:::

The payment API at the end of that chain sits five delegation hops away from the human who started it. So under whose authority is it operating? In most architectures today the honest answer is that nobody records it, and the terminal system simply sees a credential that works.

This is one of the reasons I have been working on [Human Delegation Provenance](/hdp). The core idea is that a delegated machine action should retain a verifiable chain back to the authority that originated it. Not:

> The agent says the CFO allowed it.

But:

> Here is the verifiable delegation path under which this action occurred.

Critically, authority should narrow as it travels. A child agent should not be able to manufacture more authority than its parent possessed, which is the same containment property that makes capability systems tractable.

```text
Authority(child) ⊆ Authority(parent)
```

It looks obvious written down. I am not convinced most agent architectures enforce it rigorously today, and an orchestrator that can mint sub-agents with fresh credentials is a system where that inequality is a convention rather than a control.

## 6. The problem nobody will enjoy: agent sprawl

There is another thing I think we are going to rediscover the hard way, and it is not sophisticated. It is sprawl.

Cloud gave us forgotten resources. SaaS gave us shadow IT. Identity and access management gave us abandoned service accounts. AI will give us abandoned agents.

Picture an organisation three years from now. Five thousand employees. Twenty thousand conventional service identities. And perhaps tens or hundreds of thousands of agents and sub-agents accumulated over time:

- some active
- some dormant
- some scheduled to wake next Tuesday
- some belonging to projects that no longer exist
- some created by employees who have left
- some created by other agents that were themselves created by other agents
- some holding memories nobody has ever reviewed
- some still holding perfectly valid credentials.

At some point a CISO is going to ask a very reasonable question:

> How many autonomous agents are operating inside this company?

I suspect a lot of organisations will discover that they cannot answer it, and that the honest answer is a number nobody has ever had to produce before.

So an **agent registry** starts to look inevitable. Not a list of installed AI products, but a proper machine-actor inventory holding, for every agent:

| Registry field | What it records |
| --- | --- |
| Identity | The agent's cryptographic identity and credential type |
| Owner | The accountable human, and their current employment status |
| Purpose | The declared reason it exists |
| Parent | The agent or human that created it |
| Authority | The current lease and its expiry |
| Delegation chain | The verifiable path back to a human authorisation |
| Memory | What it holds, and the provenance of what it holds |
| Tools | The systems and actions it can reach |
| Runtime | Where it executes and under what isolation |
| Behaviour | Its established baseline and current deviation |
| Attestation | When a human last confirmed it should still exist |
| Status | Active, dormant, constrained, suspended or revoked |

This is configuration management meets identity governance meets workload inventory, applied to autonomous actors. Not a glamorous piece of infrastructure. Probably an unavoidable one, and the sort of thing that is far cheaper to build before the population grows than after.

## 7. Persistence gives us a new security signal

There is a genuinely useful side effect to all this persistence. Agents develop behavioural history.

A treasury agent might normally operate between 8am and 6pm, reach three internal APIs, perform two transactions a day, never read credentials, never communicate externally, and occasionally spawn a single specialist agent. After six months we understand its behaviour rather well, in a way we never understand a freshly minted service account.

Then one night the record looks like this:

```text
02:14   activity outside the established window
        new external destination
        credential-store read
        19 sub-agents created
        43 transaction attempts
```

Its identity has not changed. Its permissions have not changed. Its behaviour has.

This is where behavioural detection gets considerably more interesting for agentic systems. Helixar's published position on agentic threat detection makes the same argument from the detection side: the most reliable detection surface for agentic threats is deviation from established behavioural baselines, specifically the patterns of API access, credential use, memory interaction and output that diverge from what a legitimate agent would be expected to do. Signature-based approaches have very little to work with when the agent is using entirely legitimate credentials.

Persistent agents add a dimension to that argument which conventional workload security never had: **time**. A baseline that has been accumulating for six months is a far better reference than anything available for a service account created this morning, and the detection work at [Helixar](https://helixar.ai/) is aimed at that problem space.

You can establish longitudinal trust. And once trust is longitudinal, it can move in both directions, which creates the possibility of reducing authority as behaviour becomes less trustworthy, rather than waiting for certainty and then killing the process.

That suggests a response ladder with intermediate rungs rather than a single kill switch:

- **Normal.** The lease applies as written, including bounded sub-agent creation.
- **Elevated.** Autonomous limits drop and consequential actions fall back to human approval.
- **Suspicious.** The agent may observe and report. It may not act, and it may not create other agents.
- **Critical.** Authority is revoked, execution stops, credentials are withdrawn and the record is preserved for investigation.

:::figure authority-states
Four graduated authority states as behavioural confidence falls: normal with full delegated authority, elevated with lower autonomous limits, suspicious with read-only operation and no delegation, and critical with authority revoked and the agent contained.
:::

That feels considerably more realistic than pretending trust is binary. The interesting case is rarely an agent that has obviously been compromised. It is an agent that has become slightly less explicable than it was last month.

## 8. Continuous Agent Authority

This is the primitive I think persistent AI eventually needs. Not continuous authentication. **Continuous authority**.

At the moment an agent attempts something consequential, the system evaluates considerably more than identity. At minimum it would have to weigh the following:

- identity
- the human delegation chain behind the request
- the current authority lease and how much of it remains
- the task actually being attempted
- applicable policy
- the provenance of any memory informing the decision
- the agent's established behavioural baseline
- the execution environment
- the time since the last human attestation.

:::figure continuous-agent-authority
Nine signals are evaluated at the moment of a consequential action: identity, human delegation chain, current authority lease, requested task, policy, memory provenance, behavioural baseline, execution environment and time since last attestation. The decision returns one of seven graduated outcomes rather than a simple allow or block.
:::

The question at that gate is not one an identity provider can answer:

> Does this agent deserve the authority required to perform this particular action, right now?

And the output is not necessarily allow or block. It can be graduated: allow, constrain, require human approval, hold, contain, suspend or revoke.

Take a legitimate finance agent making a legitimate transaction, where everything checks out except the amount:

| Signal | Result |
| --- | --- |
| Identity | Pass |
| Human delegation chain | Pass |
| Authority lease | Pass |
| Declared purpose | Pass |
| Behaviour | Pass |
| Memory provenance | Pass |
| Transaction limit | Fail |

Outcome: **human approval required**. Nothing is wrong; the action simply exceeds what was leased, so the decision returns to a person.

Now take the same agent exhibiting severe behavioural drift:

| Signal | Result |
| --- | --- |
| Identity | Pass |
| Human delegation chain | Pass |
| Authority lease | Pass |
| Behaviour | Anomalous |
| Memory provenance | Unverified |
| Execution environment | New |

Outcome: **authority reduced, delegation disabled, investigation opened**. The identity remains perfectly valid throughout.

That is the point. In an agentic system, a valid identity is the least interesting thing you can know about an actor at the moment it tries to move money.

## 9. Zero Trust probably has another chapter

The last decade of security was shaped by a simple correction:

> Being inside the network does not make you trustworthy.

Persistent AI introduces the next one:

> Being an authenticated agent does not make the action trustworthy.

That may sound obvious now. A lot of important security principles sound obvious after the industry has spent ten years learning them painfully.

I suspect autonomous systems will force us to rebuild a set of familiar ideas at machine speed:

- least privilege, when the privileged actor can create more actors
- delegation, when the chain is five hops long and none of it is human
- provenance, when the artefact being traced is a memory rather than a binary
- access review, when the population changes hourly
- behavioural detection, when the baseline belongs to a machine rather than a person
- separation of duties, when both duties can be performed by the same orchestrator.

Quarterly access certification is not much use if an orchestrator creates fifty new autonomous actors on a Tuesday afternoon. A static role assignment is not sufficient when an agent's operational context changes every few minutes. And an audit log that tells you *what happened* is not enough when the question you actually have to answer is **why that machine believed it was authorised to make it happen**.

## 10. This is becoming bigger than AI governance

This is the part I find most interesting.

AI governance is currently discussed mostly in terms of models, prompts, data leakage, policy and compliance. Those are real problems and they are not going away. But persistent agents push the problem somewhere else.

We are beginning to create a new population of digital actors. They have identities. They have memories. They have histories. They receive delegated authority. They act asynchronously. They collaborate with each other. They can remain inside organisations for long periods. And increasingly they will perform work that humans perform today.

At that point the interesting question is no longer how we govern the model. It is:

> How do we establish trust in an autonomous actor?

That is a much larger architectural problem, and it is why I increasingly view the work around Helixar and [Human Delegation Provenance](/hdp) less as another layer of AI security and more as early infrastructure for machine trust.

The primitives are starting to become clear:

- **Identity** establishes who the actor is.
- **Delegation** establishes whose authority it carries.
- **Policy** establishes the boundary.
- **Memory provenance** establishes which state can be trusted.
- **Behaviour** establishes whether the actor is still operating normally.
- **Continuous authority** decides whether the action proceeds.

The same argument shows up in operational form elsewhere on this site. [The Agentic Sprint](/agentic-sprint) describes a delivery model in which agents execute and humans retain authority over intent, architecture, quality and release, and it depends on those gates being real rather than decorative. [Autonomous Loop](/autonomous-loop) sharpens the problem from the other side: once a system is built to keep running across many goals without per-step prompting, human authorisation events become rarer, and therefore each one carries more weight and travels further from the action it eventually authorises.

Continuous Agent Authority is the runtime half of the same idea. Human gates decide what an agent is allowed to become. Continuous authority decides, at each consequential moment afterwards, whether it still is that thing.

We are not living in that world yet. But the distance between an agent that works for eight hours and one that works for eight months is getting surprisingly small.

When that boundary disappears, enterprises are going to discover something uncomfortable. The agent never logged off. Our security model did.

## Open questions

I would rather publish this with its unresolved parts visible than pretend the model is finished. The parts I am least sure about:

- Where the authority decision executes. A control plane that evaluates every consequential action is itself a high-value target and a latency budget.
- How to price re-attestation. If leases expire too quickly, humans rubber-stamp them, and the control becomes theatre.
- How trust levels are assigned to memory at write time without a human in the loop for every write.
- What the correct response is when a delegation chain cannot be verified rather than fails verification, since absence and rejection deserve different handling.
- Whether behavioural baselines survive a model upgrade underneath an otherwise unchanged agent, which is the agentic equivalent of a personality change that nobody logged.

## Disclosure

I am a co-founder and CTO of [Helixar](https://helixar.ai/), so treat the sections referring to Helixar's work as informed rather than neutral. Human Delegation Provenance is Helixar research and open-specification work, published through Helixar and released under the Apache 2.0 licence, and it is an active IETF Internet-Draft rather than an adopted standard. Helixar's product and detection engineering is deliberately not described here, and the only Helixar material this article draws on is already public. Continuous Agent Authority, as presented on this page, is my own working concept rather than a specification or a product, and it is offered for argument.

## Sources and attribution

- [Reference](https://openai.com/index/how-agents-are-transforming-work/)
- [Reference](https://arxiv.org/abs/2606.26959)
- [Reference](https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization)
- [Reference](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd)
- [Reference](https://learn.microsoft.com/en-us/security/zero-trust/sfi/manage-agentic-memory-safety)
- [Reference](https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/)
- [Reference](https://helixar.ai/press/the-research-behind-agentic-threat-detection/)
- [Reference](https://arxiv.org/abs/2604.04522)
- [Reference](https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/)
- [Reference](https://helixar.ai/)
- [Canonical HDP research and specification from Helixar](https://helixar.ai/about/labs/hdp/)
- [Helixar research index](https://helixar.ai/research/)