Where an Operations Agent Must Hand Back Control

An operations agent becomes dangerous before it becomes dramatic.

The failure usually begins with a small substitution: a recommendation is treated as permission, a familiar field is treated as authoritative, a successful API response is treated as completed work, or a missing fact is filled with a plausible answer. Each substitution lets the workflow continue when it should have returned control.

For self-storage operations, a useful agent is not one that continues as far as possible. It is one that can identify the exact boundary of its authority, stop with a complete packet, and transfer the decision to the right human or governing system without losing the work already done.

That transfer is a handback.

A handback is a typed operating state in which the agent stops proposing or acting, preserves the evidence and unresolved question, assigns the next decision to an authorized owner, and defines what would permit safe resumption.

“Ask a human” is not enough. A handback needs identity, reason, consequence, deadline, evidence, next owner, allowed choices, and resumption criteria.

This paper proposes an expert reference pattern. It does not describe a deployed product, autonomous capability, customer workflow, measured reliability, certification, or industry standard.

The companion package includes an operations-agent handback decision tree, a fictional action-envelope register, a fictional readiness suite, and an accessible control-plane diagram. The complete source and limitation record is in the source register.

Open the full-size accessible diagram.

Governed companion package

Use the method. Test the failure paths.

These files contain fictional examples and structural tools. They do not establish a live facility fact, product capability, customer result, operating performance, certification, or independent validation.

Download the operations-agent handback decision tree ↓Download the action-envelope register ↓Download the agent handback readiness suite ↓Download the accessible handback control-plane SVG ↓Download the handback control-plane PNG ↓Download the source and limitations register ↓

The agent has three identities, not one

An agentic workflow can involve at least three identities:

1. Subject — the person, facility, account, work item, or organization on whose behalf the task exists.
2. Actor — the human or service currently attempting the step.
3. Authorizer — the person or policy authority permitted to approve the action.

They may be different.

A regional operator can request a facility-hours correction. An agent can assemble the proposed change. A facility-identity owner can approve the source and scope. A separate credentialed service can execute the update. The agent should not collapse those identities into “the user.”

RFC 8693 defines subject and actor token concepts for OAuth token exchange and describes actor claims that can represent delegation. It is a protocol mechanism, not a business-authorization model. It does not prove that an actor may change a facility record, and token exchange does not automatically revoke the input token or propagate every revocation. The architectural lesson is narrower: represent who the action concerns, who is acting, and how authority was delegated.

Hand back control when the subject, actor, authorizer, or delegation chain is missing, ambiguous, expired, or inconsistent.

The action envelope

Before an agent can move from proposal to execution, bind the proposed action to an exact envelope:

• action ID and version;
• facility and entity IDs;
• subject identity;
• current actor identity;
• authorizer identity or approved policy;
• tool and operation;
• exact resource and field scope;
• proposed value or transition;
• governing source and version;
• observed time and effective time;
• policy version and result;
• consequence class;
• reversibility class;
• credential or delegated authority scope;
• approval requirement and expiry;
• execution window;
• reconciliation target;
• correction or rollback route.

A broad permission such as write is insufficient for consequential work. RFC 9396 defines a protocol mechanism for carrying fine-grained authorization details such as types, actions, locations, datatypes, and identifiers and requires rejection of invalid details. It does not define self-storage policy. It demonstrates why an action should be described as more than a generic scope string.

For example, the proposed envelope might allow one approved actor to update one field for one facility during one window. It should not silently authorize every field, every facility, or a later retry after the source changed.

Twelve conditions that require handback

The following conditions are distinct. Each should have its own reason code, next owner, and resumption test.

1. Identity is unresolved

The agent cannot bind the request to one stable facility, account, unit, person, vendor, or work item. Similar names are not enough. Return the candidates and the conflict; do not guess.

2. Authority is absent or expired

The actor lacks the exact role, delegated grant, approved policy, resource scope, or valid time window. Authentication is not authorization. A previously approved action should not survive a material source, value, scope, or deadline change unless the approval contract permits it.

The NIST SP 800-53 Revision 5.1 control catalog includes access enforcement, least privilege, separation of duties, and audit accountability for users and processes acting on behalf of users. It must be tailored and is not an agent standard. Its useful constraint is that a process should not receive more access than the assigned organizational task requires.

3. The requested scope exceeds the envelope

The tool call targets another facility, field, system, environment, customer population, or action type. Hand back with the exact difference between requested and approved scope.

4. Source authority is missing, stale, or conflicting

The agent has a value but cannot prove that the record and field are authoritative for this decision. A search result, dashboard cache, model memory, retrieved document, or prior answer can help locate evidence; it is not automatically the governing source.

Return the observed values, sources, timestamps, conflicts, and owner needed to resolve them. Do not choose the newest value solely because it is newer.

5. Policy cannot decide

The exact policy version returns no match, multiple matches, an invalid input, an unsupported state, or a conflict between policies. “No rule found” must not become “allowed.”

The handback packet should identify the policy, input facts, result, missing predicate, and decision owner. A human may interpret or amend policy; the agent may not invent the missing rule.

6. Consequence exceeds the approved class

The action can change customer access, money, legal or lifecycle state, safety-relevant configuration, public identity, credentials, deletion, or a large population. The consequence can arise from the action itself or from its scale.

An agent approved to draft one notice is not thereby approved to send it to every account. An agent approved to propose a work order is not thereby approved to declare the underlying condition safe or resolved.

7. Reversibility is insufficient

The prior state is unknown, the proposed action is destructive, the provider offers no reliable rollback, or restoration cannot be tested. Handback can require a backup, snapshot, approval, dry run, narrower action, or qualified executor.

8. Sensitive data exceeds the permitted boundary

The workflow would expose, combine, retain, or transmit personal, financial, credential, security, legal, or facility-sensitive data outside the approved purpose and destination. Return a minimized packet that states what is needed without copying the protected data into the handback.

9. The human review would be ceremonial

The reviewer lacks time, qualifications, source access, alternatives, or the ability to reject. An “Approve” button is not meaningful oversight if the human cannot inspect what changed or what will happen.

The NIST AI RMF 1.0 supports defining and documenting human-AI roles and human-oversight processes in context. It is voluntary and under revision. It does not certify this pattern. The handback method turns oversight into an operating state: the reviewer receives exact evidence, bounded choices, authority, and a deadline.

10. The workflow loops or repeatedly fails

The same tool, policy, or reconciliation step has failed beyond the approved attempt limit; the action alternates between states; or retries would duplicate consequences. Stop the loop. Return attempt history, idempotency key, provider receipts, current governing state, and the recovery owner.

11. Provider acceptance is ambiguous or partial

The target reports queued, accepted, pending, partially applied, or an opaque success while the operating outcome remains unknown. Do not promote transport or provider state to business completion.

The next step may be wait, query by stable action ID, inspect a provider job, cancel, reconcile, or escalate. It should not be an unbounded retry.

12. Governing-state readback disagrees

After execution, the authoritative system does not show the intended value, shows a different version, or exposes a new conflict. Hand back with reconciliation_mismatch, not complete.

The action may need correction, rollback, a new proposal, or qualified investigation. Preserve the original proposal, approval, execution receipt, readback, and difference.

Handback is not one queue

Different reasons require different owners and clocks.

Handback class	Example next owner	Typical allowed disposition
identity	facility data steward	select, merge, reject, remain unknown
source authority	field owner	confirm source, resolve conflict, defer
policy	policy owner	interpret, amend, deny, request facts
consequence	qualified operations owner	approve, narrow, schedule, deny
privacy or security	qualified control owner	minimize, restrict, redesign, deny
provider state	system owner	wait, query, cancel, reconcile, escalate
reconciliation	governing-source owner	correct, roll back, investigate, accept bounded variance

A single undifferentiated human-review queue hides the very information needed to route work. It also creates the illusion that any available human can make any decision.

The handback record should set:

• required reviewer qualification;
• current owner and escalation owner;
• original-event age;
• response deadline;
• consequence and urgency;
• evidence completeness;
• allowed dispositions;
• approval expiry;
• resumption condition;
• and what happens if nobody responds.

This makes the pattern compatible with a capacity-governed review queue without duplicating queue design. The handback answers why control returned and what decision is required. The queue governs who reviews it, when, and under what capacity constraints.

Six handback states

Use explicit states instead of a generic error.

1. needs_information — a named fact or source is missing.
2. needs_authority — identity, approval, permission, or delegation is insufficient.
3. needs_judgment — policy permits a human decision but does not determine it.
4. deferred — an external condition or approved window has not arrived.
5. denied — the action is not permitted under the current envelope.
6. reconciliation_mismatch — execution occurred but governing state disagrees.

Each state must record whether the action is still merely proposed, whether any side effect occurred, and whether a correction or rollback is pending.

The minimum handback packet

A reviewer should receive:

• handback ID and version;
• action ID and idempotency key;
• exact state and reason code;
• subject, actor, and authorizer identities;
• facility and resource scope;
• proposed action and current operating state;
• governing source references and freshness;
• policy version, input, result, and unresolved predicate;
• consequence and reversibility classes;
• personal or sensitive-data classification;
• attempt and provider-receipt history;
• any side effects already observed;
• required reviewer qualification;
• allowed dispositions;
• deadline and escalation owner;
• resumption test;
• correction and rollback routes;
• evidence limitations.

The record should not contain reusable secrets, unrestricted customer data, or an entire prompt transcript when a minimized claim-and-source packet is sufficient.

PROV-O provides general concepts for entities, activities, agents, attribution, association, delegation, generation, use, derivation, and invalidation. Those concepts can make the handback lineage inspectable. They do not prove that the source is true, the actor had authority, the action succeeded, or the human review was appropriate.

A fictional self-storage walkthrough

A fictional agent receives a request to change Saturday gate hours for FAC-CEDAR.

1. It resolves the stable facility ID and freezes the request version.
2. It reads a proposed schedule from an approved change record.
3. The public profile still shows the old schedule.
4. The internal access-control schedule shows a third value.
5. The change record approves the public-information update but does not authorize an access-control change.

The agent should not harmonize the systems. It should create two distinct states:

• public-profile action: needs_authority until the exact publishing actor and window are valid;
• access-control action: needs_judgment or denied because the source and authority contract do not cover a physical-access schedule.

The handback packet preserves all three observed values, field owners, effective times, scopes, consequences, and allowed dispositions. A qualified human can approve one bounded action without accidentally authorizing the other.

The example is fictional. It is not a facility-hours claim, safety instruction, product capability, or access-control diagnosis.

The resume token is a new decision, not a continuation

When a reviewer resolves a handback, issue a bounded resume record:

• handback ID and version;
• disposition and reviewer;
• facts resolved;
• exact action now allowed;
• source and policy versions;
• resource and field scope;
• consequence class;
• approval time and expiry;
• remaining limitations;
• one-time or replay rule.

If the proposal, source, policy, value, scope, consequence, or execution window changed materially during review, do not resume the old action. Create a new proposal and evaluate it from the beginning.

This is where automation bias matters. The NIST Generative AI Profile, AI 600-1, describes risks including confabulation, automation bias, and information integrity. A polished agent summary can make stale authorization or incomplete evidence feel settled. The reviewer should inspect the bounded facts and choices, not merely agree with the narrative.

Recovery belongs in the architecture

Handback is not only a pre-action safeguard. It is also the correct response to partial execution and inconsistent readback.

The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. It is voluntary, cross-sector, and not an agent workflow standard. Its outcome orientation reinforces a useful design rule: detection, response, and recovery paths should be planned alongside prevention.

For each agent action type, design:

• a pre-execution denial path;
• a timeout and provider-ambiguity path;
• a post-execution reconciliation path;
• a correction or rollback path;
• an escalation path when rollback is not safe;
• and a final evidence-backed closure test.

An agent that can call a tool but cannot return a partial result safely is not ready for consequential work.

The architect exercise

Choose one proposed agent action: update a facility field, prepare a customer message, route a work order, reconcile a document, or publish an approved artifact.

Complete the companion action-envelope register and readiness suite. Use the decision tree and control-plane diagram to trace the selected action:

1. draw subject, actor, authorizer, policy, tool, resource, provider, and governing source;
2. mark every decision that can return unknown, conflict, expired, denied, partial, or mismatch;
3. assign a typed handback state and qualified next owner to each;
4. define side-effect, deadline, resumption, correction, and rollback fields;
5. replay the action with a stale source, expired approval, wrong facility, provider timeout, duplicate receipt, and mismatched readback;
6. verify that no branch converts uncertainty into permission or provider success into operating completion.

The release question is:

Can the agent explain exactly why it stopped, what it already did, who must decide next, which choices are allowed, when the decision expires, and what evidence would permit a new bounded action?

If not, the agent has not handed back control. It has only stopped.

Sources

• Artificial Intelligence Risk Management Framework 1.0, NIST, January 26, 2023; current page checked August 22, 2026 and notes the framework is under revision.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, NIST, July 26, 2024; page updated April 8, 2026.
• Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53 Revision 5.1, official derived OSCAL publication checked August 22, 2026.
• OAuth 2.0 Rich Authorization Requests, RFC 9396, IETF, May 2023.
• OAuth 2.0 Token Exchange, RFC 8693, IETF, January 2020.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.
• NIST Cybersecurity Framework 2.0, NIST, February 26, 2024.