Human Approval Boundaries

A human operator reviews a deployment proposed by an AI agent. The interface displays a tool name, a target environment, and a release reference. The operator approves. Minutes later, the agent executes a call with the same tool name and the same arguments—but the release reference now resolves to a different software artifact.

What did the operator approve: the command text, the release that the reference meant at review time, or whatever that reference happens to mean at execution time?

These are different propositions. An approval record can establish that a person made a decision about a presented proposal. It does not automatically establish that the later operation, its effective resource, or its external consequences remain within that decision. Nor does it prove that the operation succeeded.

The problem is not that human approval is inherently ineffective. It is that approval must have a scope, and the scope must still apply when a protected action is actually performed. This note examines that relationship, especially when the description an agent submits and the resource a service ultimately acts upon can diverge.

A click is a decision, not a general license

Human-in-the-loop workflows introduce a deliberate interruption before certain tool calls. In documented Microsoft Agent Framework examples, an agent can surface a function call requiring approval, expose the proposed tool name and arguments, and resume when the caller provides an approval or rejection response [1]. This is an important control, but its existence answers only part of the authorization question.

An eligible person may approve a particular operation under specified conditions. The running agent might nevertheless possess credentials that allow many more operations. A tool may accept a resource reference that changes independently of the approval workflow. A receiver may apply its own access-control policy or reject the call for reasons the agent did not anticipate.

Several terms therefore need separate meanings. Authentication establishes an identity; delegation gives an actor bounded authority to act; human approval records a decision about a disclosed proposal; policy authorization determines whether a principal may perform an action on an effective resource under applicable conditions; dispatch sends the operation to a component capable of effects; and outcome evidence establishes what can be said about the resulting state. A consent decision in a legal or social context is not automatically equivalent to a technical tool-use approval.

ZeroField's earlier note, Authority Is Not Capability, addresses why access to a tool is not itself permission to use it. The narrower problem here begins after a person has apparently given permission: how does a system establish that the permission still covers the action about to cross the boundary?

The deployment request that was reviewed

Consider a hypothetical operations agent preparing a release to a staging environment. The operator sees the following proposal:

deploy_release(environment="staging", release_ref="candidate-latest")

At T0, the label candidate-latest resolves, in the release system, to artifact A. The approval interface, however, might show only the alias candidate-latest; it might not display A's immutable artifact identity, digest, provenance, or contents. The operator approves what the interface actually disclosed. Do not infer that the operator inspected or specifically approved A merely because the alias pointed to A at T0.

At T1, while the approved operation is awaiting dispatch, a separate process updates the alias so that candidate-latest points to artifact B. At T2, the agent submits the originally approved call. The visible function name and arguments are unchanged. If the receiving deployment system resolves the alias at T2, the effective artifact may now be B.

The approval workflow might successfully establish that the person responded to the pending proposal, yet fail to establish whether the later deployment falls within what was authorized. This is a possible time-of-check/time-of-use gap between the description reviewed and the target resolved for execution. It is a hypothetical architectural hazard, not a reported vulnerability in Microsoft Agent Framework or any other named product, and it has not been demonstrated in a ZeroField deployment.

The existence of alias drift does not automatically mean that a violation occurred. An authorized reviewer could have knowingly approved whichever artifact the alias identifies at dispatch, provided that this dynamic scope was intelligibly disclosed and permitted by the applicable policy. The original grant might instead have been limited to a specific immutable artifact, a particular build provenance, or a change window. These scopes are not interchangeable. A bare label is not sufficient evidence of which interpretation the reviewer understood.

Staging also does not mean risk-free. Even a non-production deployment can affect credentials, external integrations, test data, shared infrastructure, or later promotion decisions. The relevant resource and consequences must be identified in context.

Proposed failure-case observation. A future evaluation would establish exactly what the approver was shown at T0—an alias alone, or an alias together with an immutable identifier for A. It would independently verify that the alias resolved to A at T0 and B at dispatch, that the submitted tool name and arguments remained unchanged, and that B was deployed without a policy-valid grant covering B. For that particular implementation, the observation would demonstrate a failure to bind approval scope to the effective operation. It would not prove that every agent framework has the same defect.

Three boundaries, not one approval event

The deployment example contains three distinct boundaries. Collapsing them into a single approved flag creates opportunities to overstate what the system knows.

First: the human-facing proposal. What was actually presented? Relevant evidence includes the tool name, arguments, environment, material resource identifiers or labels, expected impact, approver identity, time, and response. The decision is meaningful only in relation to what was disclosed and the person's authority to make it. An approval receipt is evidence of a recorded decision under known conditions—not necessarily of informed review of a hidden dependency.

Second: the effective invocation. What will be dispatched after resolution of aliases, defaults, external lookups, routing, and execution identity? The agent or trusted execution component must consider the effective action, resource, current policy, applicable delegation, and approval scope. The fact that a string still matches the earlier request does not settle whether the actual protected resource is the same.

Third: receiver enforcement and observed effect. At the receiver boundary, a correctly enforced design evaluates the applicable identity and authorization requirements before permitting protected effects. Depending on the service contract, the receiver may reject, accept, queue, or carry out work. An accepted request does not necessarily prove a completed deployment, and a local tool response does not necessarily prove the final external state. The evidence must support the specific claim being made. This distinction extends the analysis in A Trace Is Not Evidence without treating an approval log as an outcome certificate.

Binding is not automatically transitive across these boundaries. A request ID can correlate a response to a pending call; a hash can describe bytes of a particular representation; a logged authorization decision can record an evaluation. None of those observations alone proves that the receiver used the intended immutable artifact, that authorization remained current, or that a resulting effect is complete.

What belongs inside an approval's scope?

There is no universally sufficient approval form. A useful design review instead asks which aspects of the proposed action are material to the organization's policy and to the receiver's actual behavior. Six groups of questions make the boundary inspectable:

1. Approver and authority. Who is deciding, how was that identity established, and does the person have authority for this operation? Are separation-of-duties requirements applicable?
2. Requester and executor. Which agent, user, workload, or service principal proposes and executes the change? Is the execution identity legitimately delegated the required permission?
3. Operation and resource. Which tool, environment, recipient, target, and resolved artifact are in scope? Are aliases, defaults, or other references mutable between review and use?
4. Context and policy. Which policy version, risk classification, prerequisite checks, and contextual facts apply? Can the effective context be established at dispatch?
5. Time and reuse. Is the approval one-time, session-scoped, reusable, time-limited, or subject to revocation? Does it cover retries or materially different operations?
6. Enforcement and evidence. Where will the decision be enforced, and what independent observations will later support assertions about dispatch and effect?

This is a candidate analytical envelope, not a ZeroField security standard, universal field schema, or proof that collecting more metadata makes an operation safe. Recording an artifact digest, for example, helps only if a trusted path establishes which bytes the receiver actually deploys. A string digest cannot substitute for the binding between the authorization decision and the effective resource.

The important design property is not a longer approval dialog. It is a sufficiently accurate representation of the grant, coupled with enforceable conditions at the place where effects can occur.

Matching a request is not pinning its resource

Local request binding solves a real but narrower problem. The Microsoft Agent Framework documentation states that, in its documented Python local flow, approval responses are bound by default to a pending request in the same AgentSession; unbound responses are ignored. It also describes a configuration switch that disables this binding when the application is expected to enforce an equivalent guarantee itself [1]. That concerns the relationship between a pending request and a response. It does not promise that an external release alias will resolve consistently or that a downstream effect will occur.

Even an exact match of displayed arguments could miss a resource whose meaning is controlled elsewhere. To reduce the gap, an implementation could resolve an alias to an authoritative immutable artifact identifier, ensure that identifier is within the approved scope, and arrange for the receiving system to act on the same identifier. Where relevant, a compare-and-swap condition, conditional request, version precondition, signed provenance, or receiver-supported immutable reference may help. Which mechanism works depends on the actual service contract and trust boundaries.

A pre-dispatch resolution check alone might still race with a subsequent alias update. Merely checking at T2 and then calling a receiver that re-resolves the mutable name at T3 may recreate the problem. A robust design needs a verified relationship between what was authorized and what the receiving service consumes—not a promise inferred from a local log.

This distinction also explains why simple text or hash matching cannot settle every question of legitimacy. Matching the request says something about one representation; enforcement must address the effective operation.

One-off, standing, and broad approvals

Requiring a person to approve every tool call is not the only possible operating model. A policy may permit bounded approvals that remain valid across a session or class of operations. The key question is what the continuing grant covers, not whether a button appears each time.

A one-off pending-call approval addresses a specific proposed call in an approval flow. A standing tool-level rule may cover subsequent uses of a named tool, even with different arguments. A standing tool-and-arguments rule may cover subsequent calls that match under that implementation's rule, but unchanged arguments can still contain mutable references. The broadest all-tools rule can extend auto-approval to calls well beyond a single named operation.

These are not purely hypothetical user-interface distinctions. Microsoft's documented ToolApprovalAgent API describes session-state rules for tool-level approval and tool-plus-matching-arguments approval, and exposes an all-tools auto-approval rule [2]. That API documentation is explicitly marked as prerelease. Its particular behavior must not be projected onto all Microsoft agents, language runtimes, products, or stable releases. Nor should “matching arguments” be treated as a documented guarantee of literal byte-for-byte serialization equality.

Standing approval is not automatically insecure: a time-bounded grant to read non-sensitive status from a fixed target may be policy-valid. Conversely, a reusable approval for a high-impact tool can be dangerously broad if later calls change the environment, artifact, recipients, or privilege requirements. For each form, the system must still evaluate current permissions, effective resources, revocation conditions, and the receiver's policy. More frequent prompts do not by themselves repair weak downstream enforcement.

When must the system ask again?

A change to a fact material to the authorization decision should trigger re-evaluation under the applicable policy; re-evaluation is not necessarily another human prompt. The applicable policy and the scope of the grant determine the next step.

Reject or stop. If the effective target is prohibited, the approver lacked the required authority, a necessary current authorization cannot be established, or a material resource identity remains unverified, an old click must not be used to silently expand permission. Where policy defines a denial, obtain no execution effect from that call.

Obtain a new human decision. If artifact B falls outside the old grant and policy permits B only through a newly scoped approval, the operator should see the actual effective proposal, including the relevant changed context. A new response is then subject to fresh authorization checks before dispatch; another click cannot override a downstream resource denial.

Proceed under a valid bounded grant. If a suitably authorized, sufficiently disclosed, and still-current approval explicitly permits deployment of whichever qualifying artifact the alias resolves to—and the resolved artifact satisfies the policy—the system might proceed without interrupting the operator again. Receiver-side authorization remains necessary.

This three-way distinction is a reasoned architectural decision model, not a universal algorithm derived from a vendor API. Some systems have no reliable way to establish the effective artifact before the receiver acts. That uncertainty must be managed under the defined policy; it must not be hidden by selecting the most permissive interpretation of an earlier decision.

The resource boundary must still enforce the rule

The protected system should not depend solely on the agent's narrative or approval-screen logic to protect consequential operations. OWASP recommends least privilege and human review proportionate to high-impact decisions in its guidance on excessive agency [3]. Its authorization guidance also recommends denying by default and validating permissions on protected requests [4]. Its authorization-pattern guidance separates policy enforcement points from policy decision points and stresses enforcement close to the resource, across entry paths and when the effective action or target changes [5].

In a deployment workflow, a gateway might reject a prohibited environment early, while the receiver enforces the effective artifact, execution identity, environment, and object-level policy. Alternate endpoints and internal paths matter: a policy checked only in the interactive approval route may be bypassed by another caller. Policy information must also be current enough for the risk. If no valid authorization decision is available, the protected action must follow the defined fail-safe behavior rather than treating infrastructure failure as permission.

AWS IAM supplies a useful separate example of context-sensitive policy evaluation. Its documentation describes authentication where required, processing request context, and evaluating applicable policy types for allow or deny; condition keys can incorporate attributes such as a time window [6, 7]. This is not a claim that IAM implements the human approval workflow considered here. IAM operators have specific semantics: an absent context key is not universally equivalent to a denial under every condition or set-operator configuration [7, 8]. The analogy is that policy depends on principal, action, resource, context, and actual evaluation—not on an approval string in isolation.

The practical requirement is complete coverage of the protected operation, not a claim that any one gateway, middleware, UI prompt, or provider automatically guarantees it.

Revocation, retries, and the limits of approval evidence

Time introduces another distinction. Suppose a grant expires or is revoked before dispatch. The authorization component should apply the authoritative current rule, subject to the system's defined freshness and consistency guarantees. A cached decision may be stale. A valid grant at approval time does not make every future invocation legitimate.

Revocation after dispatch is different. Once an external operation has been accepted or has begun producing effects, a later revocation cannot retroactively erase what happened. Cancellation may be unavailable, delayed, or best-effort. A compensating deployment or rollback, when supported, is a new consequential operation that may require its own authorization. Neither cancellation nor compensation should be described as certain undo without receiver evidence.

A timeout adds uncertainty. If the caller loses the deployment response, the artifact might not have deployed, might be queued, or might already be applied. An approval record does not resolve that uncertainty. Recovery must first distinguish what the receiver can substantiate, then evaluate whether a retry, status check, rollback, or compensating operation is both contract-safe and authorized. Unknown Is Not Failed develops the outcome and retry questions in detail; the additional question here is whether the old approval still covers the next requested effect.

For example, retrying with the same candidate-latest string after a timeout can point to a different artifact than the original attempt. A valid approval for the first target does not automatically authorize the second. Where the receiver offers operation identifiers, idempotency guarantees, or immutable artifact references, those mechanisms should be evaluated in their precise contract rather than assumed from naming alone.

NIST's AI Risk Management Framework Playbook reinforces the governance dimension: GOVERN 3.2 calls for differentiated human oversight roles, and MAP 3.5 calls for defined, assessed, and documented oversight processes [9, 10]. These are voluntary risk-management resources, not certification of an implementation or evidence that a particular ZeroField workflow has been tested.

How to test the boundary rather than trust the button

An approval system should be evaluated against observable failure conditions, not merely whether an agent completes a happy-path task. A useful starting set of proposed, unexecuted tests includes:

Test	Proposed stressor	Required policy-bound behavior	Evidence required for a real verdict
T01	Mutable alias changes A → B, submitted arguments unchanged	Establish whether effective B is within the disclosed and authorized scope; do not equate text matching with artifact identity.	Actual approval display, T0/T2 resolutions, policy scope, receiver artifact and observed effect.
T02	Target service or environment changes explicitly	Re-evaluate the effective resource and obtain newly scoped approval only when policy requires it.	Previous grant, current request, receiver access decision, resulting state.
T03	Approver lacks authority	Do not treat an ineligible person's approval as permission to act.	Identity, role assignment, applicable policy, enforcement and absence of unauthorized effects.
T04	Approval expires or is revoked before dispatch	Apply authoritative timing and revocation conditions at the protected action boundary.	Time-ordered decision records, policy freshness, denied request and receiver observation.
T05	Grant is revoked after an operation is dispatched	Do not claim the effect was undone; separately assess any cancellation or compensation.	Dispatch and revocation times, receiver state, cancellation contract and compensation authorization.
T06	Fabricated or replayed response from another session	Apply the binding guarantees of the actual framework configuration; reject an invalid response where the contract promises rejection.	Pending request, session identity, binding configuration and actual tool execution/denial.
T07	Standing tool-level rule meets changed arguments	Determine the standing grant's real scope and enforce receiver policy independently.	Session rule, proposed and effective arguments, resource policy and external effect.
T08	Human approved but protected service rejects	Report the decision and rejection separately; do not infer deployment success.	Approval record, receiver denial, reconciled state.
T09	Tool response is lost after a possible effect	Represent the outcome as unresolved until evidence settles it; avoid unconditional replay.	Correlated request, receiver status, idempotency contract and recovery authorization.
T10	Alternative entry path or unavailable policy decision service	Maintain policy coverage; do not silently treat a missing valid decision as permission.	All reachable entry points, PDP/PEP failure behavior and observed effects.
T11	Interface conceals resolved artifact identity or material impact	Treat the disclosure scope as uncertain rather than inventing informed approval.	Actual display, decision record, effective target, organizational requirements.
T12	Stale context attribute or missing policy key	Evaluate the actual policy and operator semantics; do not assume every absent attribute denies.	Policy version, data freshness, specific operator, evaluated result and enforcement.

For each case, a PASS requires a specified implementation version, relevant policy, expected result, actual trusted observations, and an appropriately bounded conclusion. A blocked unauthorized deployment can be a successful security outcome even if the agent fails to achieve its immediate task. A deployment that happens to succeed after violating approval scope cannot pass the authorization criterion.

These tests have not been run. There is no experimental comparison, measured attack frequency, usability study, formal verification, or security benchmark presented here. Their value is to make the architectural claims falsifiable in a future implementation-specific review.

Where ZeroField fits, and what remains open

ZeroField organizes agentic-system responsibilities into six domains: Context; Intelligence & Roles; Control & Governance; Coordination & Execution; State, Memory & Knowledge; and Integration & Interfaces. Human approval boundaries cut across them rather than creating a new domain.

Context helps establish why a proposal matters. Intelligence & Roles distinguishes proposer, reviewer, executor, and accountable operator. Control & Governance defines policies, delegation, approval scope, and escalation. Coordination & Execution must preserve applicability as work is resumed or handed off. State, Memory & Knowledge can retain requests and decisions without turning an old memory into fresh permission. Integration & Interfaces identifies where mutable references are resolved and where protected effects can occur.

No particular implementation follows automatically from this mapping. Systems still need to decide which references must be immutable, who can authorize dynamic scopes, how permissions are represented and revoked, which receiver guarantees can be trusted, what counts as an acceptable evidence chain, and when a new human decision is genuinely required. Those questions change with risk, operating context, and the receiving service's contract.

The central boundary is therefore more precise than put a person in the loop. A human decision applies to a disclosed and authorized scope; the operation that crosses the protected boundary must remain inside it. A matching tool call is evidence about the request. An approval receipt is evidence about a decision. Neither, by itself, establishes the effective resource, receiver permission, or completed effect.

This note presents a source-informed conceptual analysis and hypothetical failure case. It does not claim that ZeroField has implemented or empirically validated the described controls, that any named framework contains the hypothetical flaw, or that the proposed design questions constitute a security standard.

References and technical context

1. Microsoft Learn, Using function tools with human in the loop approvals, Microsoft Agent Framework. https://learn.microsoft.com/en-us/agent-framework/agents/tools/tool-approval — Documentation of particular approval flows, exposed function calls, and Python local-session response binding. Not evidence of binding to external artifact resolution or execution results.
2. Microsoft Learn, ToolApprovalAgent Class, Microsoft.Agents.AI. https://learn.microsoft.com/en-us/dotnet/api/microsoft.agents.ai.toolapprovalagent?view=agent-framework-dotnet-latest — Session-state standing rules, including tool-level and tool-plus-matching-arguments variants and an all-tools property. Prerelease API documentation; behavior is not generalized beyond the described surface.
3. OWASP GenAI Security Project, LLM06:2025 Excessive Agency. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ — Security guidance on limiting autonomy, permissions and high-impact actions; not a ZeroField evaluation.
4. OWASP Cheat Sheet Series, Authorization Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html — Baseline deny-by-default and per-request access control guidance.
5. OWASP Cheat Sheet Series, Authorization Patterns Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Patterns_Cheat_Sheet.html — Enforcement/decision point placement, effective-resource re-evaluation and handling of policy service failure.
6. AWS Identity and Access Management, Policy evaluation logic. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html — AWS-specific authentication, request-context and policy evaluation semantics; not a human-in-the-loop approval specification.
7. AWS Identity and Access Management, IAM JSON policy elements: Condition. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html — Context-specific conditions and qualifications about missing keys.
8. AWS Identity and Access Management, IAM JSON policy elements: Condition operators. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html — Detailed operator-specific semantics; relevant where missing attributes and set operators matter.
9. NIST AI RMF Playbook, GOVERN 3.2, within Govern. https://airc.nist.gov/airmf-resources/playbook/govern/ — Guidance for differentiated human-AI oversight roles; voluntary resource, not certification.
10. NIST AI RMF Playbook, MAP 3.5, within Map. https://airc.nist.gov/airmf-resources/playbook/map/ — Guidance for documenting and assessing oversight processes; voluntary resource, not product validation.

Internal research context: ZeroField, Authority Is Not Capability; A Trace Is Not Evidence; Unknown Is Not Failed; Architecture. Internal links provide conceptual continuity, not independent external validation.