Unattended scheduled agent

Chen runs a financial shared services center. Every morning before eight he needs yesterday's reconciliation: payment channel transactions, the order system, and the general ledger, checked three ways. His team built a reconciliation agent that runs itself at 3 a.m. — nobody present, nobody handing off a task — and drops the exception report in Chen's inbox. It worked beautifully, until internal audit asked one question: that account running at 3 a.m. — who authorized it to see payment transactions?

Chen had no answer. The old way to run unattended work is a cron job plus a service account: the password sits in a config file, the engineer who wrote it left last year, and the password is still the same password. The permissions were opened back when the goal was "just get it running," and they are far wider than the job needs. When something breaks, nobody claims it right away, and when audit asks why the account has those permissions, the answer is folklore passed along by word of mouth. Nobody present at 3 a.m. is acceptable. Nobody accountable is not.

The flow

The reconciliation agent runs in autonomous mode: it acts in its own name and does not represent any particular person. Notice the diagram below — there is no User lane, and that absence is the defining feature of this scenario: there is no per-task delegator. In its place stand two forms of "someone was here": the permission boundary drawn by organization-level consent at approval time, and the accountable people written into the ledger. Step numbers belong to the same system as The full journey of one delegation; this page shows ①⑤⑥, with the ⑤⑥ messages adapted for autonomous mode.

No delegator, but someone accountable

Delegated mode answers "on whose behalf." Autonomous mode has to answer a different question — whose account does this go on. Every agent must register two accountable people: the Owner handles the technology — configuration, credential rotation, upgrades, and the 3 a.m. page; the Sponsor handles ownership — which business this agent exists for, and whose books its cost and risk land on. When an accountable person leaves, ownership transfers automatically, so "service accounts with no owner" stop happening. See The Agent Identity model.

Three moments that matter

1. Consent — it happens at approval time: no per-task delegator does not mean no human decides. When the reconciliation agent enters the ledger, the permission boundary it applies for — read-only on payment transactions and order data, write-only on the reconciliation report — goes to approval together with a purpose statement and two accountable people, and an administrator confirms it in the organization's name. Every 3 a.m. run from then on is framed by that boundary. Widening the boundary means going through approval again. Authorization stops being "whoever opened that hole back then" and becomes "the boundary approved in that review."
2. Audit record: every nightly batch lands in the audit chain with an audit_id: who granted it — the organization (the approval record traces back to a specific approver); on whose behalf — the agent itself (autonomous mode borrows nobody's identity); what it did — which data sources it read and which report it wrote. When internal audit comes back, Chen just pulls the records: every step taken at 3 a.m. is queryable at eight.
3. Revocation: reconciliation logic goes wrong and starts writing dirty data? The Owner or an administrator can revoke the grant and disable the agent at any time, after which new token requests are no longer accepted. For how quickly already-issued tokens stop working, see Revocation and emergency response. Autonomous-mode tokens are short-lived and fetched on demand by design — cut the source and the tail is short.

Capabilities used here

Capability	What it does in this scenario	Read more
Autonomous mode	The agent acts in its own name; the token's subject is the agent itself	Three access patterns
First-class identity and accountable people	Owner + Sponsor are mandatory on the record, with automatic succession when someone leaves	The Agent Identity model
Organization-level consent	Approval draws the boundary in place of per-task delegation	Consent and approval
Audit chain	Every unattended step traces back to an approval and an accountable person	Audit and accountability chain
Registration and lifecycle management	From entering the ledger to being retired, the agent has a file the whole way	Register and manage your agents

Next steps

• Scenario: Governing an enterprise agent fleet — from one unattended agent to dozens across the company.
• Hands-on: Register and manage your agents — put accountable people and permission boundaries into the ledger.
• Concept: Three access patterns — delegated, autonomous, multi-hop, and who the subject is in each.