Agent Authority Has No General System of Record

One of the fastest-growing authorization surfaces in software is a prompt in an agent harness. May I run this command. May I read this file. May I send this email. Across today’s agent products, humans are bounding individual actions, and few of those clicks produce a structured authorization record that another system can rely on after the session. The click is consumed, the action proceeds, and the durable residue is often only an event log. When an auditor asks six months later who approved an export, which undertaking it served, and what boundary the approver believed they were setting, the log can show a click without answering the task-level question.

Approval interactions already happen at scale. What is missing is the durable record that distinguishes approval of the task from approval of one action inside it.

The missing record matters because an agent is not merely a faster deterministic workflow. It is goal-seeking software that can assemble context, discover tools, and choose a path its designer did not enumerate. That open-world value also defeats authorization models that assume the caller’s identity or original session predicts the next action. The control objective is therefore survival correctness: when reasoning is wrong, context is hostile, a credential is stolen, or a supplier fails, the remaining authority should still be bounded by approved work and able to terminate with it. The record is a containment boundary, not a claim that the reasoning inside it is trustworthy.

This is the third of three essays on who controls the agent stack. The first named the provider seam that hides credential mechanisms and custody from agent logic. The second named the binding layer where runtime evidence becomes an enterprise-governed Agent and Agent Deployment. That layer can say whose agent is running and which deployment was approved. It cannot say whether the current undertaking is approved, because that is not an identity fact. This essay is about that third control point, the approved-task record. A fourth decision remains deliberately outside the contest: each resource retains authority over whether one concrete action may proceed now.

Where Task Authority Lives Today

Ask where the authority for an agent’s current task is actually recorded in a working enterprise, and you get four different answers depending on who you ask.

Each of these is real, and each is doing part of the job. None has the full set of properties a system of record for the approved-work ceiling needs. A durable owner. A statement of approved purpose with its bounds. A lifecycle of its own, with states and an expiry that do not depend on any credential’s lifetime. Revocation that propagates, so ending the record ends derivation of new authority. A join to evidence, so any action can be traced to the approval it served. And independence from any single vendor, so the record survives changing the harness, runtime, or model. Value-based model routing makes that last requirement concrete mid-task rather than at migration time. One undertaking can span several inference suppliers before it completes, so no vendor’s session state sees the whole task even in principle, and the record is the only stable join.

The result is that task authority in many agent deployments is not simply governed badly. It is governed four ways at once, in systems that rarely share one task identifier or lifecycle. The prompt lives in the harness, the grant at the identity provider, the role in cloud IAM, and the ticket in the ITSM. Grant the second essay’s 2 a.m. incident a won binding layer: runtime evidence identifies the instance, and the binding layer resolves it to the enterprise research agent. The next question is still open: which approved undertaking justified the document export? The on-call engineer has four partial records and no authoritative task boundary that joins them.

Why Identity Cannot Carry the Job

The tempting fix is to lean harder on the identity layer, since that market is at least being contested. Give the agent a first-class identity, bind it to an owner and an approved deployment, scope its roles tightly, and call the result governance.

The second essay made the argument against this at length, so here it is compressed. A person is durable and changes jobs slowly, so anchoring recurring authority to who someone is often works tolerably well. A logical Agent can also be durable, but its runtime instances multiply quickly and it can pursue many undertakings whose approval ends long before the Agent record does. Identity-anchored grants therefore risk becoming standing privilege shared across tasks. That risk stopped being theoretical in August 2025, when OAuth tokens stolen from one vendor’s AI chat agent were replayed to exfiltrate data across numerous corporate Salesforce instances. Standing, capability-shaped, task-agnostic grants gave the theft its blast radius, and no record existed that could say which undertaking any of that access served. A task record would not have stopped the theft. It would have bounded what the stolen grants could serve, containment rather than prevention. And the least-privilege work supplies the deeper reason. The model is untrusted reasoning that proposes actions, so the governance question at every step is not whether this Agent may ever do this thing. It is whether this task, as approved, justifies this action now. Identity cannot answer a question about a task. Only a record of the task can.

The Object Is the Approved Task

Call the missing artifact the approved task record. One distinction keeps it precise. Agent protocols already have a task object, in the sense of held work, an execution handle for something in progress. That is not this. The record here is the governed statement of approved purpose, the thing the work in progress should be checked against, with an accountable owner, explicit bounds, and a lifecycle that ends.

The object is not exotic. Whatever form wins will spell at least this much:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "task_id": "task_01J9Z4",
  "version": 3,
  "owner": "alice@example.com",
  "approved_by": "acquisition-review-policy:v4",
  "agent": "research-agent",
  "deployment": "research-agent:v17",
  "purpose": "Prepare the Q3 acquisition review",
  "bounds": {
    "resources": ["deal-room/acme/**"],
    "effects": ["read", "summarize"]
  },
  "state": "active",
  "expires_at": "2026-07-18T00:00:00Z"
}

That sketch is a floor, not a proposal. Authority derivation is gated by state, either through a current check or a bounded-freshness projection. Credentials carry the reference, so any action can be joined back to the approval it served, and ending the task ends new derivation without pretending already completed effects can be recalled. The bounds are what an enforcement point checks a proposed action against, version identifies the state that was evaluated, and owner is who the auditor calls. Nothing in it commands the resource, which still applies its own policy to whatever arrives.

The agent or harness may propose this record. It must not be able to activate or widen its own authority merely by changing the proposal. An accountable person, policy, or approval service decides when the record becomes live and whether a later expansion is legitimate; the system of record preserves that decision and its evidence. Separating proposer, approver, recorder, and enforcer prevents “the agent asked for it” from becoming “the enterprise authorized it.” One product may operate several of those roles, but the roles remain distinct.

System of record means a logical authority here, not one centralized database. The record can be event-sourced, replicated, or federated, as directories and Git histories are, provided one authoritative answer exists to whether this task is still approved and revocation propagates from that answer.

This is not a new idea struggling for a first expression. Domain-specific versions are old. Purchase orders, change approvals, and trading mandates are approved-purpose records that bound authority in their own systems. Every other durable layer of the stack eventually grew a system of record as well. Source has Git. Secrets have Vault. Workloads have the cluster’s desired state. Identities had a directory before anything else could depend on them. Agent authority has no cross-domain equivalent. What lacks a general form is the undertaking that can span runtimes, issuers, and resources while preserving its owner, bounds, lifecycle, and evidence relationships. The agent version has been argued from several directions, including how natural-language intent becomes checkable, approvable bounds and why shaped intent is not sufficient without a governed record behind it. One proposed shape is the Mission draft, my own proposal, a record of approved purpose with its own owner, state, and expiry that credentials derive from and enforcement points consult. The market does not have to adopt that particular shape. It does have to adopt some shape, because every property in the list above depends on the record existing as a first-class object rather than as a prompt’s discarded output.

Three approval grains surround that object and must not be collapsed:

A harness permission prompt usually occupies the third row. Preserving the click is valuable, but it does not manufacture the first row. The approved-task record has to be shaped, validated, and approved before its authority is projected into execution.

The Transport Primitives Exist. The Shared Semantics Do Not.

The instinct, on hearing “new control plane,” is to expect every transport interaction to be invented from zero. That is not true, and it matters for how fast this layer can arrive. Much of the request, interaction, decision, and credential machinery already exists.

Read the inventory economically rather than as a standards report. The missing asset is not another protocol. It is the durable enterprise record that every issuer, enforcement point, and audit eventually has to reference.

Read down the middle column and the pattern is hard to miss. The requests, user interactions, decisions, and projections have standards or active proposals. Read down the right column and the missing layer is also clear, but it is larger than one schema.

The transport is mostly available. The shared task semantics, lifecycle, trust, and enforcement contract are not.

That asymmetry is why this layer is closer than it looks without being easy. Nobody has to displace OAuth or invent a new generic decision protocol. The work is to define the record, state transitions, authority subset rules, resource semantics, issuer trust, freshness behavior, privacy boundaries, evidence relationships, and the bindings into existing flows. This is a semantic and adoption problem more than a transport war, but it is substantial protocol work.

Who Mints the Record, and Who May Approve It

Four plays are competing for the record, mostly without saying so.

Every play has a product analog, although none yet proves the complete general record. Harness session state and permission prompts are the bundled play’s raw material. Identity-platform consent and grant machinery is the grant growing up. Enterprise approval workflows are the ticket reaching down. And the mission-shaped control plane is the independent approved-work play, proposed but not yet a mature product category.

The fourth play’s hardest requirement is in its own row, and it is the first essay’s lesson applied one layer up. A record developers must stop and author will lose to the prompt, exactly as GSS-API lost on the estates where operating the realm stayed a separate project. The record has to be minted as a byproduct of asking for the work, shaped from the request itself, approved by policy for routine bounds, and escalated to a human only at thresholds. The security team’s lifecycle and the developer’s autonomy are not opposed demands. They are the same demand, that the friction live in the plumbing rather than the workflow.

The forces that decide this contest are the same three from the identity essay, transferred whole. Distribution favors the harness because it owns the moments where work is requested and actions are confirmed, much as the runtime owns the moment of instance creation. Durable state decides whether any alternative is real, because a layer that does not become the system of record for task approvals is an adapter on someone else’s record. And resource acceptance is the decisive integration, because a record that enforcement points never consult is documentation, not authority.

The likeliest near-term state is, again, all of the plays at once. Prompts in the harness, grants at the identity provider, roles in cloud IAM, tickets in the ITSM, and no join between them. That is not a forecast. It is a description of the present. The hybrid mess arrived at this layer before the market did, which is exactly why the record is the near-term demand rather than the long-term vision.

The Open World Is Producing Domain Records First

The second essay argued that the identity market may split, contestable in heterogeneous enterprises and more likely to default to major harness providers in the open world. The approved-work layer can split the same way, with one instructive difference. Domain-specific records are already taking concrete form.

When a consumer’s agent spends money, the parties on both sides of the transaction need something stronger than a session prompt. The Agentic Payment Protocol (AP2) v0.2 provides a concrete domain-specific example. Open Mandates can capture user-approved constraints for autonomous purchases. Closed Checkout and Payment Mandates bind a concrete checkout and payment into signed objects that merchants, credential providers, networks, and payment processors can verify. That is evidence the object is technically expressible and that a resource-facing protocol can be designed around it. AP2 remains an early domain signal, not evidence that a general approved-task control plane or broad deployment already exists.

The lesson cuts both ways. It shows what a domain-specific record can look like and why resources may have an incentive to evaluate one. It also exposes the consolidation risk from the identity essay operating one layer up. If the only accepted records are minted inside payment networks and model-provider ecosystems, the open world can get task authority the way it got login, from a short list of platforms whose records others cannot issue. The cross-domain seams, issuer trust that spans domains and task context that keeps meaning after a hop, decide whether the record remains issuable by any authority a resource chooses to trust.

Not Every Action Requires a Control-Plane Hop

One objection needs disarming here as much as it did in the identity essay. A record with per-action relevance sounds like a synchronous check against a central service on every tool call. That is one enforcement mode, not the architecture.

The record is desired state, not necessarily an inline proxy. At a baseline level, its state gates issuance, so a revoked or expired record stops new credential derivation while already issued credentials remain usable to their published freshness bound. A runtime-enforced deployment also checks current task state and concrete parameters at declared consequential boundaries. The highest-consequence actions can require mediated credential custody and action-bound approval immediately before execution. These modes trade latency and integration cost for tighter containment. None of them promises one global instant, and none imposes a hop on every call.

Across those modes, the decision remains conjunctive:

Permit = valid runtime evidence AND eligible Agent and Agent Deployment AND live approved task AND valid credential AND resource policy permits.

The approved-task record is the system of record for the undertaking and its authority ceiling. It is not the system of record for every resource permission, and it never commands a resource to act.

The record is also not frozen at approval. Agents discover mid-task that the work needs a destination or operation nobody enumerated upfront, and a static ceiling would turn the record into a cage rather than a bound. The lifecycle therefore includes governed widening, and the recovery loop already has a worked pattern at the network boundary, where a blocked agent’s denial becomes a requestable one and the escalation that widens the task is exactly what the denial carries.

Test Whether the Record Is Real

The same kind of test that applied to the binding layer applies here. An enterprise evaluating any agent platform’s governance story should ask six questions.

1. Does task approval produce a durable record? If approval of the undertaking does not mint an object with an owner, bounds, and expiry, the platform has session state, consent UX, or action step-up rather than task governance.
2. Does revoking the record actually stop anything? Ending the record should end new credential derivation immediately and reach enforcement points in bounded time.
3. Can an auditor join an action to the approval it served? Across the harness, the identity provider, and the resources, one record should thread the evidence together.
4. Does the record survive changing vendors? If the approvals live only in the harness, changing the harness resets the enterprise’s authority history to zero.
5. Is the record machine-checkable at the point of use? A rationale a human can read is a ticket. A bound a policy decision point can evaluate is a record.
6. Does the resource retain the final decision? The record can bound and justify authority. Current resource policy must still be able to narrow or deny it.

Ask them in order. Many current products provide approval UX or logs without creating the durable task object in question one, so the remaining properties never become testable.

The Last Word

Honesty about the counter-case, as before. In a single-vendor estate running short-lived, supervised agents, harness session state plus action prompts may provide enough practical governance, while the ITSM absorbs what auditors require at human speed. If agents stay small, the absence of a separate approved-task record may never be felt. Longer tasks, more autonomy, more vendors, and more instances create the conditions under which its absence starts to cost something.

So the arc ends where the series began, with the couplet. Distribution determines the default, and the harness has distribution at the moments where work is requested and actions are confirmed. Seams determine whether that default can be challenged. The transport primitives are further along than the market realizes, while the shared record semantics and resource contract remain open. Whether that gap closes in time is a delivery question, and the MCP companion supplies the test, while the Cross App Access companion shows the nearest machinery, the grant layer this essay names, actually shipping. The provider seam decides how credentials are presented. Runtime evidence says what instance controls the key. The binding layer says whose Agent it is and which deployment was approved. The approved-task record says why authority exists and when it ends. The resource still decides whether one concrete action may proceed.

The first two control points are already being contested. The third remains unavailable as a general, interoperable control plane because its record and enforcement contract have no shared form yet. That is not merely a gap in the market. It is the market.