Authorize the Agent at Commit Time, Not at Plan Time

An AI agent can form a plan in one moment and create a durable business effect much later. It may read a customer record, obtain an approval, ask another agent to prepare work, wait for a dependency, and only then issue a payment, change a production setting, sign an agreement or send a regulatory filing. Treating the first approval as permanent authority for the final act is a category error.

The right question is not only whether the agent was allowed to plan. It is whether the organization still authorizes this exact effect when the effect becomes durable. For consequential actions, authorization belongs at commit time.

A plan is a proposal, not an authority grant

Planning and committing solve different problems. Planning turns goals, memory and current observations into a proposed effect. Authorization decides whether a principal may perform an action on a resource under a particular set of conditions. Commitment is the point at which an external system accepts the effect and the organization must live with its consequences.

Those moments may be separated by seconds, hours or a long-running workflow. In between, an employee can revoke a delegation, an approval can expire, a budget can be exhausted, a target record can change version, or a security condition can deteriorate. The agent’s earlier reasoning may remain intelligible while its authority has disappeared.

A July 2026 preprint calls the required property “commit-time authorization”: the authority behind derived agent state must remain fresh, causally prior, bound to the same effect and eligible when that effect commits. Its controlled tests found that visible task completion often persisted even after the authorizing path had been invalidated. That is useful research evidence, not an established industry standard. But the architectural implication is already plain: a runtime cannot infer present authority from a historical plan alone.

The commit boundary is where governance becomes operational

This is not a claim that every action needs a database-style two-phase commit. Many SaaS APIs and business tools do not offer prepare/commit semantics, atomic rollback or even a meaningful undo. The practical rule is narrower: identify the last controllable point before an external side effect becomes durable, and make that point a governed runtime boundary.

At that boundary, the runtime should reconstruct the request from live facts rather than replay a stale decision. NIST’s Zero Trust Architecture describes decisions made through policy decision and enforcement points using identity, resource and contextual factors. AWS IAM similarly evaluates a request context comprising the principal, requested action, resource, environment and resource data; it denies by default, and an explicit deny overrides an allow. These are not agent-specific models. They are precisely the discipline agent runtimes need at the moment of effect.

The check should ask: who is acting; which organization and delegation chain are involved; what exact action is proposed; which immutable target or target version will receive it; what policy applies now; and what live business and security context changes the answer. If authority relies on an access token, current activity matters as well. OAuth 2.0 Token Introspection exists to determine whether a token is currently active, including validity, expiration and revocation-related checks.

“An approval should authorize a named effect under stated conditions—not grant an agent a reusable blank cheque.

Bind the authority witness to the proposed effect

A human approval, delegated mandate, policy exception or service credential is an authority witness. The runtime should verify that it still exists, is eligible, and is bound to the effect about to happen. “Approved the vendor payment” is weak evidence if the payee, amount, currency, invoice, destination account or policy version can later drift without invalidating the approval.

A useful proposed-effect record therefore contains a canonical description of the action and its target: for example, supplier identifier, invoice identifier, amount, currency, payment destination, applicable budget and the version of the record the agent inspected. It also contains the authority witness, its validity conditions, the delegation chain where relevant, and a deadline. The runtime can compare that record with live state at commit. A mismatch should produce a new proposal, not a silent continuation.

This avoids a common mistake: replacing governance with a short-lived credential. Short expiry reduces the window of exposure, but it does not prove that an approval remains tied to the same effect, that the resource is unchanged, or that a newly applicable policy permits the operation. Conversely, a fresh authorization decision does not establish that the agent chose the correct action. It establishes current permission, not semantic correctness.

Make the effect safe to retry and legible to investigate

Commit-time authorization needs transaction engineering around it. A network timeout after a payment request creates an ambiguous state: the agent may not know whether the payment happened. Retrying without controls can create a duplicate. Stripe’s idempotency-key design illustrates the essential pattern: a mutating request can be retried under a key, while reuse with different parameters is detected. The key must identify the proposed effect, not merely the agent or workflow run.

For each consequential action, the runtime should carry an idempotency key, an effect fingerprint, a point-of-no-return classification and, where feasible, a compensation path. Distributed-transaction guidance for sagas identifies stale data, idempotency, observability and compensation as explicit concerns, and recommends semantic locking when concurrent orchestrations could act on stale state. Compensation is valuable, but it is not an eraser. Microsoft’s guidance notes that it can fail, require human intervention and may not recreate the exact prior state—especially after irreversible steps or concurrent change.

The practical ordering follows from that limitation. Put critical validations before irreversible operations. Label irreversible steps explicitly. Where an action cannot be reversed, make the authorization and approval evidence correspondingly stronger, and preserve the record needed for review.

A trace is not an authorization record

Distributed tracing remains necessary. W3C Trace Context standardizes identifiers that connect work across services, which is essential when one agent delegates to others and a commit happens far from the original request. But correlation answers “which path led here?” It does not answer “was this effect authorized at this moment?”

A governed runtime should record both. Alongside trace identifiers, retain the proposed-effect fingerprint; policy and policy version; the evaluated context; the authority witness and its validation result; the decision; the actor and delegation chain; the idempotency key; timestamps; and the external system’s result. Sensitive values need not be copied indiscriminately. The record must nevertheless be sufficient to reconstruct why a commit was permitted, denied or sent for review.

What this changes for an autonomous organization

The operating model shifts from granting agents broad standing permission to mediating discrete business effects. Agents remain free to reason, explore, assemble evidence and prepare proposals. The runtime becomes responsible for the narrow transition from organizational memory and agent intent into durable external change.

That separation is productive, not restrictive. It lets an organization permit long-running autonomous work without pretending that yesterday’s context is still valid today. It creates a clear place to apply current policy, preserve accountable evidence, handle retries safely and stop work when authority or state has changed.

Start with the actions that move money, alter production, change entitlements, create legal commitments or transmit regulated data. Map their true point of no return. Define the canonical proposed effect. Bind each approval or delegation to it. Re-evaluate policy immediately before commit. Then design idempotency, compensation and decision records around the actual integration. Commit-time authorization will not make an agent correct. It does make one boundary unambiguous: an autonomous system may reason at length, but it must earn the right to act when action becomes real.