Cloudflare’s Resumable Agents: Check Access Before They Act

An agent prepares a deployment for a client’s staging service. A teammate approves it. Before execution, that teammate loses project access and the target release changes.

This is a hypothetical agency workflow. When the run resumes, a saved approval explains an earlier decision. Your application still needs to establish whether the intended action is authorized now.

That is the useful engineering question behind Cloudflare’s October 26 announcement about resumable agent code and approval waits. A team can preserve progress across interruptions while keeping permission checks close to the action they protect.

This guide uses documentation reviewed on October 27, 2026. The controls below are application design recommendations, illustrated with synthetic client and deployment records.

What Cloudflare announced, and when it shipped

Cloudflare describes @cloudflare/computer v0.7.0 supporting recovery after interruptions and pauses for application-supplied answers, such as approval. Its release record is dated October 23; the explanatory changelog is dated October 26.

The announcement demonstrates onInterrupt: "replay", an application function pausing at ctx.interrupt(), and the application answering a pending call. Waiting survives deployments and does not consume the run’s timeout. See the announcement and example.

Cloudflare labels recovery and approval waits experimental. Its documentation warns that runtime-changing upgrades can fail interrupted runs. Pin and test the runtime you intend to operate. These details matter when an agency promises a client that queued work will finish after an infrastructure change.

The new capability is a useful trigger for reviewing an existing workflow. The review should cover the authority behind each operation as well as the operation’s recovery behavior.

Make an approval describe the exact change

An approval button labeled “continue” gives a reviewer very little to verify. For a client deployment, show the client, environment, service, intended release, and relevant effect in the same review surface.

Keep a server-side record of that intent. For example:

{
  "actionId": "action-demo-42",
  "clientId": "client-demo-a",
  "environment": "staging",
  "operation": "deploy-release",
  "resourceId": "orders-service-demo",
  "releaseId": "immutable-release-demo-17",
  "approvedBy": "reviewer-demo-8",
  "approvalExpiresAt": "2026-10-27T12:00:00Z"
}

This is an illustrative application record, not a Cloudflare API payload. All identifiers are synthetic. Store credential references separately from secret values.

The record gives the executor something concrete to compare with the request it is about to perform. The application should resolve client ownership from trusted records, rather than accepting a model’s assertion that a resource belongs to that client.

If the deployment changes to another environment, resource, or release, require review of the changed intent. A teammate who approved a staging release has not approved a later production deployment just because both tasks share a conversation.

Choose an approval lifetime appropriate to the operation. A stale approval should lead to a new decision. It should not silently extend itself whenever a worker restarts.

OWASP’s transaction-authorization guidance recommends protecting approved operation data from modification and checking authorization at execution. Applying those ideas to an agent deployment is an application design choice; the stored approval needs enforcement behind the button.

Recheck current access at the tool boundary

For an agency, the relevant authority can change while a run waits. A client engagement may end, a developer may move projects, or a production-access grant may expire.

Define which principals your application requires to remain authorized: the requester, the approver, the executing service identity, or a documented combination. A departure does not have to cancel every business workflow automatically, but the rule should be explicit and enforced.

Before a new external effect, the trusted application function should establish:

1. The action still belongs to the expected client and resource.
2. Its approved payload is unchanged and its approval remains valid.
3. Current policy permits the required identities to perform it.
4. The credential selected for execution has the required scope.

Put this check immediately before the external operation in the trusted tool implementation. A separate permission-check tool whose earlier result was recorded is a weak place to depend on freshness during replay.

This follows OWASP’s recommendation to validate permission on every request. The downstream service should also enforce the permissions it controls. An earlier application check cannot make a later provider request atomic with a permission change in another system.

If current authority cannot be established, hold the new effect for review. Returning a recorded result for an action that already completed is a different case: the response describes past work, rather than permission to perform another action.

Design what happens when the external action repeats

Cloudflare’s replay model restarts JavaScript and supplies recorded results for completed calls. A call whose result was not recorded can run again, even if its external effect succeeded before interruption. Its recovery documentation describes stable host-call IDs and unsafeToRepeat() for handling this boundary.

Consider a second hypothetical case. A deployment provider accepts a release request, then the process stops before recording the response. The application now has an uncertain outcome. Sending another request might create another deployment.

For a provider that supports idempotency, pass a stable operation identifier using its documented mechanism. Cloudflare’s host callId is useful for a repeat of that same host call. Also decide how your application identifies the same business action if a user starts an entirely new run; that new run should not accidentally turn a retry into a new operation.

Check the provider’s key scope, retention period, and behavior when the same key arrives with different parameters. An arbitrary header named Idempotency-Key does nothing unless the receiving service implements the contract you need.

Where repetition is unsafe and no suitable deduplication mechanism exists, Cloudflare documents unsafeToRepeat() as failing a run interrupted during that call. A failed run can still leave an external effect that needs investigation. Assign an owner to inspect provider state before authorizing another attempt.

Keep the operation identifier, intended release, provider receipt, and reconciliation status together. A clear “outcome unknown” state is more useful than a green retry button that gives an operator no evidence about the first attempt.

Keep credential values out of paused work

Cloudflare documents that replayable runs journal call responses in Durable Object storage until completion. That makes the return value of a credential-reading tool a concrete design concern. Review the journal behavior and current limitations before deciding what a tool returns.

Prefer a narrow tool such as “deploy this approved release to this service” over returning a provider credential and letting generated code choose arbitrary requests. The trusted implementation can obtain an appropriately scoped credential after its current checks, perform the permitted operation, and return a minimal receipt.

Keep raw values out of approval descriptions, model-visible results, application logs, and routine diagnostic output. Review error handling too: an upstream response or command failure can include more context than the tool intended to expose.

Credential freshness and operation identity are separate. If an authentication token expires during a wait, the application may obtain a replacement with equivalent permitted scope. That does not authorize switching the operation to another client, environment, or resource.

Record which identity performed the effect without recording its credential. The useful evidence is the approved action, current policy decision, operation identifier, and provider result. Secret material adds exposure without proving the action was authorized.

Test the waiting period as part of the workflow

A successful uninterrupted demo misses the conditions this design is meant to handle. Use a staging integration with synthetic records and a controllable test provider to exercise the gap between review and execution.

For each case, verify the external effect as well as the agent’s reported status. A tool returning “done” is insufficient evidence if the provider received a different release or accepted two operations.

Test rejection paths with the same care as acceptance. A blocked action should leave enough non-sensitive context for a developer or client owner to understand the next step. It should not cause the agent to request broader credentials automatically.

Give configuration a clear home, and keep action policy explicit

An agency also needs a dependable way to locate the correct configuration for each client project and environment. Keyrua supports that organization and a CLI workflow for retrieving values. Its CLI documentation and security model describe the access and export boundaries.

Those boundaries matter here. Project members with access can manage values across that project’s environments; environment labels do not provide separate production permissions. Organization administrators retain access across projects. Choose project, organization, and provider-account boundaries that fit your client responsibilities.

keyrua run retrieves the selected project/environment values and injects them into a child process alongside inherited environment variables. That process can access the supplied values. This workflow does not implement the approval, idempotency, or current-action checks described above, and it does not automatically refresh a running process.

Use our AI-agent secrets guide for the broader credential discussion and the offboarding checklist when people leave a client project. Provider-side credential revocation remains a separate responsibility.

For your next agent integration, choose one staging action and deliberately pause it. Change one relevant permission or the intended resource, then inspect what happens when execution resumes. The test should show which application component makes the current decision, which credential it uses, and how the team resolves an uncertain external outcome.