Who Authorized the Work Is Not Where It Ran
Why consequential agent workflows need separate evidence for workload identity, execution environment and human business acceptance.
An agent workflow can produce a clean result and still leave the most important questions unanswered. Who was allowed to start the work? Where did the work actually run? And who, if anyone, accepted the resulting business action?
Those questions sound similar because they all concern control. They are not the same question. Treating them as one is how a useful tool result starts to look like a business commitment.
Recent changes in agent infrastructure make the distinction practical. OpenAI's release notes describe generally available mutual TLS and X.509 workload identity federation for API access. Cloudflare's AI changelog describes an arrangement in which Cursor hosts an agent loop, inference and planning while Cloudflare runs commands, file edits and repository operations in customer-controlled infrastructure. Cloudflare's Workers changelog also documents an Agents SDK update with per-request MCP server creation for stateless handling and explicit trusted middleware controls.
Taken together, these updates are a useful reminder: a system can know who authenticated a workload without collapsing that fact into where its tools ran. And neither fact decides whether a person or organisation approved a consequential outcome.
Three records, three questions
A robust handoff keeps three kinds of evidence visible.
Workload identity answers: who or what was authenticated to invoke this capability? A certificate, identity provider assertion or scoped service credential may establish a principal, an issuer, a method of authentication, a permitted scope and an expiry time. That is valuable evidence. It tells an operator which workload was allowed to ask for work.
Execution evidence answers: where and how did the work run? For an agent task, that could include the executor or backend, an isolated session or instance identifier, the requested tool or command, a result status and a digest of the output artifact. This record matters when planning happens in one environment while command execution happens in another. It also matters when a session disappears and a later reviewer must reconstruct what completed.
Business acceptance answers a different question: did the appropriate person or organisation decide to act on the result? A valid identity does not reserve a seat, send a customer message, accept a contract or approve a production change. A successful tool call does not do those things either. The decision to create an external effect needs its own explicit acceptance record.
These records may be linked in one workflow, but they should not be merged into a single status such as "done". A status that hides the boundary is hard to audit and even harder to recover safely.
Why the separation is becoming more important
Modern agent systems increasingly divide responsibility across services. A planning loop may run in a hosted product. Repository tools, command execution and file operations may run in an isolated environment controlled by the customer. An MCP server may be constructed for a single request, while other stateful features live elsewhere.
That division can be beneficial. It can narrow the environment in which a command executes and make an execution boundary easier to inspect. But it also means that one log line from the planner cannot describe the full action. A reviewer needs evidence from the caller and the executor.
The same principle applies when an organisation changes providers or moves a workload. A trusted workload identity may remain the same while the execution backend changes. The backend may be approved while an expired identity should no longer invoke it. Both facts should be checkable independently.
This is not a call to collect unlimited telemetry. It is a call to preserve the minimum evidence that lets a later reviewer answer a precise question without guessing.
A compact handoff record
For a consequential handoff, a useful record can be small and structured. It should capture:
- the authenticated principal and authentication method;
- the issuer or identity-provider reference, granted scope and expiry;
- the executor or backend and its isolated session or instance identifier;
- the requested tool or command and the result status;
- a digest or durable reference for the resulting artifact; and
- the separate human or organisational acceptance state.
The key is not the exact field names. The key is that the record can answer each of the three questions above without relying on an informal summary. If the executor returns a result but acceptance is pending, the record should say so. If the session has been lost, the result digest should still allow a reviewer to identify what was produced. If a backend has changed, that change should be visible rather than silently inherited.
This approach also improves recovery. An interrupted workflow should resume from the durable handoff record, not from an assumption that the original execution session still exists. The next stage can verify the prior result, identify who invoked it and decide whether the correct person must approve the next action.
A practical review sequence
A team can apply this distinction with a short review sequence.
First, confirm the invocation boundary. Which workload identity requested the action? What scope was available, and was it still valid at the time?
Second, confirm the execution boundary. Which environment ran the command or tool? Was the expected isolated executor used? Can the result be tied to a concrete status and artifact rather than a conversational claim?
Third, confirm the decision boundary. Is the result only a read, a proposal or a prepared change? If it will create an external effect, who has authority to accept it, and has that acceptance actually been recorded?
This sequence is deliberately useful for ordinary work, not only high-risk systems. A report assembled by an agent may be ready for review without being approved for publication. A booking suggestion may be accurate without being permission to book. A repository update may have passed a tool check without being authorised for release.
The useful rule
Identity is evidence of who may invoke a workload. Execution evidence is proof of where a task was attempted and what it returned. Business acceptance is a decision about what happens next.
Keeping these separate does not slow useful automation. It gives automation a clearer stopping point. Agents can research, prepare, validate and propose. Reviewers can understand the boundary between an authenticated request, an executed task and an authorised external action. And when something changes or fails, the organisation has a record from which to restart rather than a persuasive message to reinterpret.
The most useful question for any consequential handoff is therefore not simply, "Did it work?" Ask: who was allowed to ask, where did it run, what evidence came back, and who still needs to decide?