Who can stop an agent after it starts acting?

AI agent runtime stop controls matter once an autonomous workflow has moved beyond planning and begun changing external systems. At that point, stopping execution may require action at the session, tool, identity, queue and downstream-workflow layers, while anything already committed may have to enter recovery instead.

The incident commander sees the second remediation step appear in the trace.

An operations agent has diagnosed a service degradation as a failed application tier. Its runbook allows it to drain traffic from unhealthy instances, restart services and, under certain conditions, fail over to a standby.

The diagnosis is wrong.

The first instance has already been removed from rotation. The agent is now preparing the next action.

Someone says, “Stop it.”

The orchestration console has a stop control.

Security can disable the agent’s workload identity.

The gateway can deny additional tool calls.

The infrastructure platform has its own cancellation APIs.

Those controls sit at different points in an execution path that has already begun moving.

The useful question during the incident is more precise:

Which action can still be prevented, and which one is already outside the agent’s control?

Once autonomous systems can produce real side effects, runtime containment becomes a path through every layer capable of carrying work after the original reasoning loop has been interrupted.

A stop button has to name what it actually stops

The incident commander uses the control in the agent runtime first.

Amazon Bedrock AgentCore exposes a StopRuntimeSession operation that terminates an active runtime session and stops ongoing streaming responses. AWS positions it for cases including unresponsive sessions, timeout handling and explicit application shutdown.

The operation has a clear scope: the runtime session.

An agent may already have sent an API request, placed work on a queue or started a downstream workflow under its own execution context. A long-running service operation may have accepted the command and returned before completing the underlying work.

Terminating the reasoning loop prevents another decision from originating there. The incident team still has to account for work that has crossed into other systems.

The next tool call is often the cleanest place to interrupt execution

The remediation agent has not yet invoked the failover tool.

If authorization is checked immediately before each consequential action, security can still prevent that call even though the agent has already planned it.

Human-in-the-loop implementations use the same boundary deliberately. Temporal’s current Strands Agents integration, for example, allows a hook to interrupt execution before a tool call, wait for an external decision and cancel the tool when approval is denied. Its broader execution model treats external I/O as Activities with their own timeouts, retries and cancellation behavior.

A production containment design can use the invocation boundary without requiring a person to approve every action.

During ordinary operation, policy may answer in milliseconds. During an incident, an emergency deny rule or task-level containment state can change that answer before the next side effect begins.

A permission decision made only when the task started can become stale while the task is still running.

In-flight work may already belong to another system

The session is terminated.

One infrastructure operation continues running.

AWS Step Functions illustrates why this can happen in ordinary distributed systems. Standard Workflow executions can be stopped with StopExecution, but AWS documents cases in which already invoked work continues. Running Lambda functions cannot simply be terminated by the state machine, and activity workers may rely on heartbeats or their own cancellation handling to recognize that the parent execution has ended.

For synchronous service integrations, Step Functions makes a best-effort attempt to cancel an underlying job when the workflow is aborted. AWS notes that cancellation can still fail because of permissions or service conditions.

The same mechanics appear in an agentic workflow once tools reach durable or independently executing systems. A database operation, infrastructure job, browser action or external SaaS transaction can continue toward completion even after the orchestrator stops issuing instructions.

Containment planning therefore needs an inventory of tool behavior: which operations accept cancellation, which only acknowledge receipt and which become effectively committed once accepted.

Identity revocation reaches authority beyond the session

Security also disables the agent’s production identity.

This closes an access route that may remain relevant after the original runtime disappears—for example, if another component attempts to continue the task or reuse the same authority.

Microsoft Entra’s Continuous Access Evaluation for supported workload identities can enforce certain revocation events, such as disabling a service principal, without relying solely on token expiry. Microsoft notes that participating resource providers can reject a token and force reevaluation when supported revocation conditions occur. The current workload-identity implementation has scope limitations, including support focused on qualifying service principals and Microsoft Graph as the resource provider.

A production agent may also cross several credential models during one task: its workload identity, delegated user tokens, API keys held by a gateway, service credentials attached to a tool, or authority acquired by a downstream workflow.

The incident runbook therefore needs to know where access is reevaluated and where an already issued credential may remain usable until expiry or explicit revocation.

Queued work can outlive the decision to stop

Before the session ended, the agent scheduled two remediation jobs.

Neither has started.

A queue has separated the decision to perform the work from the execution of that work. Under normal conditions, that separation improves durability and absorbs load. During an incident, the worker still needs to know whether an old command remains valid.

A containment-aware design needs a way to distinguish work that remains authorized from work that was authorized when enqueued but should no longer execute.

A worker can validate current task status immediately before execution.

Queued commands can carry a revocable execution token or task generation number.

An incident control can mark the parent task cancelled and require workers to consult that state before producing side effects.

High-impact queues can support explicit cancellation or purging of pending jobs associated with a task or agent run.

What matters is how close that decision occurs to the side effect. The longer the gap between authorization and execution, the more opportunity there is for the safety state to change in between.

An action that already committed needs compensation, not cancellation

The first application instance has already been drained from the load balancer.

No later stop operation can erase the completed API call. Recovery now requires another action that restores the intended state.

Temporal’s AI guidance includes the Saga pattern for distributed operations, where completed steps can have compensating actions that attempt to undo their effects when later execution fails or is abandoned.

The practical taxonomy is broader than “cancel or continue.”

Some actions are cancellable before completion.

Some are reversible after completion.

Some require a separate compensating business process.

Some are effectively irreversible.

A transferred payment may need a reversal process rather than deletion. An email cannot be reliably recalled after delivery. Information disclosed to an external party cannot be made undisclosed. A deleted resource may be recoverable only if the surrounding platform provides backup or soft-delete behavior.

An agent capable of effectively irreversible actions should encounter tighter pre-action controls because runtime intervention has very little value once the tool call succeeds.

Child execution needs its own containment state

The remediation agent also launched a diagnostic subworkflow.

Durable orchestration systems make the lifecycle of delegated work explicit. Temporal, for example, supports child workflows with configurable parent-close behavior, including cases where a child can continue after the parent closes.

Agent systems can create equivalent relationships in several ways.

A coordinating agent delegates to a specialist agent.

A tool starts a long-running job.

A task calls another workflow engine.

A browser session continues independently.

A downstream system accepts a request and assigns its own worker.

By the time an operator invokes containment, the execution graph may contain several independently running branches.

A strong runtime control therefore maintains enough of that execution tree to show which descendants terminated, which received cancellation requests and which now require separate handling.

Without that view, the root agent can disappear while useful—and potentially dangerous—work remains active underneath it.

Containment authority has to be usable during the incident

The incident commander can recognize the bad behavior without administering the identity platform, orchestration service, gateway and every target system involved.

A control path that depends on four teams coordinating manually may be technically complete and operationally slow.

For consequential agents, the organization can expose a narrow incident action that performs an approved containment sequence:

stop runtime → cancel task → block high-risk calls → revoke relevant credentials → invalidate queued work → alert owners of in-flight operations

The operator does not need standing administrator privileges over every component. The incident action can itself be authorized, scoped and logged, while giving the responder enough reach to stop propagation before organizational handoffs become the bottleneck.

A containment drill reveals what the button cannot reach

After the incident, the team tests the stop path deliberately.

The agent is placed in a non-production environment and allowed to begin a multi-step remediation sequence.

Containment is invoked at several points:

• before the first tool call;
• while a tool is running;
• after a queued job has been created;
• after a child workflow has started;
• after one external action has committed.

The resulting timeline is more useful than a screenshot of a red STOP button.

It shows how long new calls continue after containment begins. It identifies credentials that remain usable. It reveals which workers honour cancellation, which queued jobs still execute and which committed actions enter compensation.

For this agent, containment is defined operationally:

no new consequential actions can begin under the task’s authority, outstanding work has been cancelled or classified, externally running operations are known, and completed side effects have entered the appropriate recovery path.

That definition can be tested.

A button label cannot.

The incident closes only after the execution tree is accounted for

Back in production, the runtime session disappears within seconds.

One infrastructure action had already completed and is reversed.

Two queued jobs are invalidated before workers execute them.

The diagnostic child workflow is terminated separately.

The agent identity remains disabled until the investigation is complete.

The team records the last tool call that succeeded, the first one that was denied, which work continued after session termination and which compensating action restored the drained instance.

Only then is the containment boundary known well enough to close the incident.

An autonomous system can cross several execution boundaries in less time than a human can follow the trace. Those boundaries need controls before the first incident asks them to work together.

The difficult part is not giving an agent a stop button.

It is knowing what can still be moving after someone presses it.