Why AI Agent Authority Decays

Tomohiro Iida · Published October 1, 2026 · Updated October 1, 2026

Granting an AI agent permission to do a job is relatively easy to reason about. Keeping that authority valid for 24 hours, several days, or several weeks is much harder. The difficult part is not only whether the agent is intelligent enough. It is whether the authority that was valid yesterday is still valid against the subject, runtime, source, policy, evidence, and external state that exist now.

Scope: the Netsujo Controller discussed here controls software-development and operations workflows. It is not a production onchain-finance system. The onchain-finance discussion is a design comparison based on public specifications and research.

Authority is not one fact

Statements such as “the Owner approved it,” “the signature is valid,” or “the agent has the role” are important, but none of them is sufficient on its own. In long-running Controller operations we also have to ask whether the agent is still the same operational subject, whether the code and binary match what was reviewed, whether the source HEAD matches the QC target, whether receipts and attestations are still fresh, whether policy has changed, whether a restart preserved the intended generation, and whether the previous external mutation actually happened.

Design model used at Netsujo: Authority(t) = Grant × Subject Integrity(t) × Runtime Integrity(t) × State Binding(t) × Evidence Freshness(t) × Policy Validity(t) × Outcome Certainty(t). This is an operational model, not a standardized mathematical formula.

If one factor no longer holds, we do not treat the old grant as automatically executable. That is what this article means by authority “decaying.” The authority itself is not physically degrading; the context that made the grant valid has changed.

Five ways authority decays

1. Subject Drift — the subject behind the authority changes

An agent can keep the same name while its model, runtime, binary, execution host, or boot generation changes. On September 30, 2026, one Controller failure happened because a helper that was executable in Git was checked out with different file-mode metadata during a root-side bootstrap. The runtime failed closed before materialization. After the fix, the source HEAD itself had changed, so we rebuilt from the new source instead of silently reusing the old generation and authority.

The Owner’s intent had not changed. The authorized object had. That distinction is central to Authority Continuity.

2. State Drift — the state being authorized changes

A review of one source HEAD does not authorize a different HEAD. This is why our Controller binds evidence to exact commits rather than to a pull-request label or a conversational claim that “CI is green.”

A similar state-dependence appears in Account Abstraction. ERC-7562 was in Review as of September 30, 2026. It says a UserOperation should receive full validation before mempool admission and again before inclusion in a bundle or block, because validity can depend on mutable state and an operation that was valid earlier can become invalid later.

3. Evidence Drift — the reason an action was allowed becomes stale

Receipts, attestations, QC results, signatures, and measurements all have freshness and target-binding requirements. In our 24-hour operations, when HEAD moved we invalidated the old CI/QC evidence and required fresh exact-head evidence. We also hit a separate failure where an installation payload that was already canonical was normalized again as though it were raw input, causing receipt issuance and readback to fail closed.

Evidence therefore has a lifecycle: issuance, representation, transfer, reference, renewal, and expiry. “Evidence exists” is not enough; we need to know what it binds to, in what representation, and for how long.

4. Policy Drift — the meaning of the grant changes

A grant such as “this agent may execute” is underspecified if scope, destination, value ceiling, production access, or redelegation are not explicit. ERC-8226, still a Draft as of September 30, 2026, proposes a compliance delegation layer for AI agents handling tokenized regulated assets, with mandates that are scoped, time-bounded, and financially capped.

The operational question is what happens when policy changes. If the effect ceiling is unchanged, some evidence may be renewable. If privilege or the amount ceiling increases, or the destination or policy meaning changes, that is a new authorization decision.

5. Outcome Ambiguity — the previous side effect is unknown

An API call times out. The caller sees an error, but the remote system may already have committed the change. Blind retry can then create a duplicate payment, duplicate message, duplicate merge, or duplicate migration. Observing no effect in one external-state check is not sufficient either; a delayed original request may still succeed later. The Controller represents this as OUTCOME_UNCERTAIN instead of collapsing it into failure.

Error ≠ Not Executed. A failed response is not proof that no side effect exists.

We made the system safer, and then it stopped too often

Fail closed on uncertainty. Refresh evidence when HEAD changes. Stop when authority is unknown. These were necessary controls. But over long periods a second failure mode appeared: evidence expires, runtimes disappear temporarily, restarts need revalidation, and the Controller stops until a human types “resume.”

That taught us to separate Safety from Liveness. A safety failure executes something that should not happen. A liveness failure prevents an allowed action from continuing. Guardrails can improve safety while simultaneously introducing state, expiry, synchronization, and dependency failures that damage liveness.

Authority Continuity is not permanent authority

By Authority Continuity we mean the ability to preserve only the authority that is still justified across time, state changes, restarts, and evidence renewal without silently raising the Owner’s ceiling. The goal is not to make a grant live forever. It is to keep necessary authority bound to the current context.

A July 2026 preprint, “Are You Still the Agent I Authorized?”, formulates authorization continuity for long-lived agents and proposes fixing an immutable effect ceiling when the grant is issued. Our use of “Authority Continuity” is a broader operational label that also includes runtime identity, evidence lifecycle, recovery, and reconciliation. We are not claiming it is a standardized term.

Separate renewal from reauthorization

The invariant is simple: automatic recovery must never silently expand authority beyond the existing ceiling.

ERC-8273 is interesting because it avoids long-lived active authorization

ERC-8273 was still a Draft as of September 30, 2026. It proposes an Agent Attestation Registry and transaction-scoped authorization. Its motivation explicitly notes that identity alone does not guarantee that the same agent remains behind an account over time. In the standard atomic path, active authorization is confined to one transaction and cleared when the transaction ends rather than becoming a long-lived session attestation.

One way to read this design is that it shortens the time during which authority can go stale. It is not a complete solution to Authority Continuity. Real agents observe markets, call APIs, cross wallets and bridges, restart, wait, and act again hours later. The continuity problem returns outside the transaction boundary.

Agentic finance needs reconciliation before retry

Consider a chain of execution: agent → wallet → RPC → chain → bridge → exchange. A network interruption somewhere in that path should not automatically produce a retry. A safer pattern is reconciliation-aware execution.

• Assign a stable action ID before the mutation.
• Persist the intended mutation before execution.
• Execute the mutation.
• If the outcome cannot be proven, transition to OUTCOME_UNCERTAIN.
• Reconcile external state using the chain, nonce, transaction receipt, counterparty API, or equivalent source.
• If execution is confirmed, bind the receipt and resulting state.
• Retry only when it can be confirmed that the original action can no longer succeed, or when the same action ID / idempotency key / nonce causes duplicate effects to be rejected.
• If neither can be established, remain in OUTCOME_UNCERTAIN. Immediately before any retry, re-bind Authority to the current state.

A finalized transaction receipt is strong evidence. A transaction hash by itself is only an identifier, not proof that execution finalized successfully. And once the workflow crosses offchain boundaries, not every system shares blockchain transaction semantics.

Persistent authorization has the opposite failure mode

Expiring authority too aggressively hurts liveness. Keeping it alive too long creates residual authority. A September 27, 2026 arXiv preprint, “When Consent Outlives Context,” studies how approvals can outlive the context that originally justified them and later be replayed. It is one research result and should not be generalized to every agent system, but it highlights the symmetry: expire too early and valid work stops; retain too long and stale approval can be reused.

Putting authorization onchain does not remove offchain decay

Blockchains are good at making grants, nonces, caps, revocations, settlements, and evidence commitments independently verifiable. They do not automatically prove that the current model/runtime is the one that was evaluated, that an offchain binary is intact, that source and QC target still match, that an external API mutation completed, or that a policy engine loaded the intended configuration.

Onchain authorization can make part of the Authority state independently verifiable. Authority Continuity still has to be designed across the onchain/offchain boundary.

Seven design principles from Controller operations

1. Authority is state-bound

Bind authority to current source, runtime, policy, evidence, and external state, not only to an agent name.

2. Freshness must be explicit

State what expires the authority and what changes invalidate its evidence.

3. Renewal is not reauthorization

Refreshing evidence under the same ceiling is not the same operation as granting broader authority.

4. Authority must never silently expand

Automatic recovery and agent-produced evidence must not raise the Owner-defined effect ceiling.

5. Fail closed needs a recovery path

Define not only when execution stops but what must be rechecked and who or what may resume it.

6. Safety and liveness are separate SLOs

Measure prevention of invalid actions separately from the ability to continue valid work.

7. Unknown outcomes reconcile before retry

Do not convert uncertainty into failure. Inspect external state before the next mutation.

The hard part begins after authority is granted

The industry is getting better at granting constrained authority: narrow scope, explicit expiry, value ceilings, operation-scoped attestations, and state revalidation. The next problem is how to keep a long-lived agent’s authority safely usable for 24 hours, a week, or a year while the world around that grant keeps changing.

For us, that is the core of Authority Continuity: preserve the ability to act without expanding the ceiling, keep authority re-bound to current state, and reconcile uncertainty before another irreversible action.

Primary references

ERC-7562 — Account Abstraction Validation Scope Rules (Review as of September 30, 2026)

ERC-8273 — Attestation-Gated Agentic Actions (Draft as of September 30, 2026)

ERC-8226 — Regulated Agent Mandate (Draft as of September 30, 2026)

Are You Still the Agent I Authorized? — long-lived agent authorization continuity preprint

When Consent Outlives Context — residual authority replay preprint