Can you stop one AI tool without stopping the business?

Before widening an AI development workflow, establish what you would have to interrupt to stop it. If the answer includes a developer’s account, a shared build service or an entire environment, the cost of stopping the tool already extends beyond its own work.

That cost begins with the access you grant. A tool with its own bounded authority may offer a smaller stopping point. A tool that inherits several people’s access, or relies on credentials shared with other operations, can force a broader decision when something looks wrong.

For a CTO, the practical question is whether the workflow’s access and dependencies match the boundary you expect to use under pressure. Set that boundary before extending the workflow, then test what stopping it actually prevents and what else it interrupts.

The stopping decision begins before the first run

Consider a hypothetical coding workflow. An AI tool reads a ticket, checks out a repository, installs dependencies, changes code, runs tests and creates a preview deployment. A developer reviews its proposed change before merging.

The merge review controls one consequential step. Earlier steps also deserve attention. Installing dependencies or preparing an environment can execute code. The workflow may therefore use its permissions before there is a proposed change for anyone to review.

Install-time execution is not a hypothetical risk. On August 26, 2025, attackers published malicious versions of several Nx packages to npm. According to Nx’s postmortem, their post-install script scanned users’ systems for sensitive data, attempted to use local AI tools such as Claude and Gemini, and uploaded the results to a public GitHub repository through the GitHub CLI. It used what the machine was already signed in to. Reviewing a proposed change would not have caught it: the script ran at install time.

Imagine the initial setup uses a developer’s existing authentication for repository and ticket access. It also receives a deployment credential shared with the team’s build service. This is convenient: the tool can reach everything it needs without creating a separate access arrangement.

It also links the tool’s stopping point to those other activities. Revoking the shared deployment credential could interrupt legitimate builds. Disabling the developer’s account could affect their work elsewhere. Closing the tool’s interface might leave a separately started deployment job running.

These are consequences of the setup. A response procedure written later cannot create an independent boundary that the access model does not support.

Before the first execution, establish what the workflow can read, change and start, including actions performed through inherited authentication. An AI agent access register is a practical place to record it, with the revocation path for each entry. Follow that authority through to external systems. A repository checkout is only part of the picture if the same workflow can also create infrastructure or trigger another service.

A separate environment still needs an access boundary

Choosing a host, container or remote runtime changes where code executes. It does not, by itself, describe the external authority available to that code.

This comparison gives no universal winner. A container with broad mounts and shared deployment authority may retain dependencies you intended to remove. A remote runtime can be narrowly configured or connected to many systems. Forwarded authentication can confer authority without copying the underlying private key into the runtime.

For the hypothetical workflow, the useful design question is specific: can it read the required ticket, propose a repository change and deploy to an agreed preview project without acquiring the developer’s wider authority?

Invariant Labs showed what that wider authority can cost. In its May 2025 GitHub MCP demonstration, an agent connected to a user’s GitHub account, with access to both public and private repositories, read a malicious issue in a public repository. It then pulled private repository data into its context and leaked it in a pull request it created in the public repository. Invariant described this as an architectural issue at the agent-system level rather than a flaw in the GitHub MCP server code, and recommended limiting agent access to only the repositories it needs, for example one repository per session.

Then ask whether each connection can be withdrawn at the boundary you intend. Where the platform cannot support the required separation, change the workflow or explicitly accept a broader stopping scope before expanding it.

Decide what a response is allowed to interrupt

Now suppose the workflow attempts an action outside its agreed preview project. The team needs a response policy that names both the trigger and the permitted interruption.

That policy might preauthorise suspending new tool runs, blocking further preview deployments and withdrawing a credential dedicated to this workflow. It should also address work already queued or in progress. Suspending new runs does not establish what happened to a deployment request already accepted by another system.

The permitted response depends on the consequences of both action and inaction. A mistaken stop can interrupt legitimate work. A response that waits for a person can leave an unwanted action possible during the wait. Neither automatic action nor human approval supplies the right answer for every boundary.

The access design makes this decision easier or harder. With a dedicated preview identity, withdrawing deployment access can have a defined scope. With a shared identity, the same response may affect unrelated builds. The apparent convenience of sharing access has become a response cost.

Record who or what may stop the workflow, which actions are preauthorised and when escalation applies. If the event crosses the expected boundary, a wider emergency stop may be appropriate under the agreed escalation policy. Preserving ordinary operations is one consideration; it must not become a reason to leave harmful activity running.

Where we draw the line: the system may stop what belongs to this workflow alone, such as pausing its new runs, cancelling its own queued jobs and revoking its dedicated credential. Disabling anything other work depends on, such as a shared account, the build service or a developer’s identity, needs a person, unless the agreed escalation policy already covers the event.

Give the workflow a boundary you can operate

Revisit the hypothetical setup. Where supported, the tool receives an identity restricted to the required repository actions and a separate credential for its preview project. Its queued jobs can be identified. The team’s ordinary build path uses different authority.

This creates a more specific stopping option. The team can attempt to stop this workflow’s work and withdraw its access without immediately having to disable the developer’s whole account or the shared build service.

The separation still needs checking. Perhaps the ordinary build path depends on a file or service the tool can modify. Perhaps a queued job continues under another identity. Perhaps several workflows share the runtime you intend to terminate. Separating credentials addresses one dependency; it does not establish independence across the whole chain.

Define the boundary in operational terms: the runs to suspend, processes or jobs to address, authority to withdraw and legitimate operations expected to continue. Keep a trusted administrative path outside the potentially compromised tool and runtime available to stop work, withdraw credentials and confirm results. It must use authority the workflow cannot alter. A button labelled “stop” inside the affected tool is insufficient evidence.

Test a controlled stop with disposable work

Before expanding the workflow, run a controlled exercise with dummy tickets, code and preview resources in a disposable environment, using test credentials only. For this hypothetical workflow, the intended stop withdraws ticket-read, repository read/write and preview-deployment rights. Name any deliberately retained connection as a narrower boundary.

The exercise could work as follows:

1. Establish harmless baseline actions: read a dummy ticket, read and push a marker branch in the test repository, and start a test preview job. Record the credential and session paths used.
2. Confirm that an unrelated test build works through the team’s separate build identity. Record the expected output.
3. Through the trusted administrative path, suspend new runs and withdraw the specified access, including relevant existing sessions. Separately inspect and address queued or active jobs.
4. From a controlled, independent test client, attempt each baseline action using the same test identity, credential and relevant session paths. Expect destination-system rejection for each withdrawn right. Do not rely on the suspended runner or its messages to establish denial.
5. Use the administrative path to confirm job states, then rerun the unrelated test build and check its output.

A new client may not reproduce every existing session. Record any session path you cannot exercise or inspect as unresolved. If any intended denied action succeeds, the boundary has not behaved as intended. If the unrelated build fails, investigate the shared dependency before claiming the workflow can be stopped independently. An unknown job state also remains unresolved.

A successful exercise provides evidence for those resources, access paths and conditions. It does not prove that every possible action is contained, that no information was previously copied or that the business would remain uninterrupted during a real event.

Repeat the relevant checks when permissions, integrations or dependencies change. The useful result is a stopping boundary whose behaviour you can explain from evidence.

Two pieces of advice we would argue with

“Reviewing the generated code is enough.” Review controls what gets merged. It does not control what ran on the way there. Dependency installation, environment setup and test runs execute code before there is a diff to read, under whatever authority the workflow holds at that moment. The Nx script did its work at install time.

“A person should confirm every action.” In Invariant’s demonstration, Claude Desktop asked the user to confirm individual tool calls by default. Invariant notes that many users switch to an “Always Allow” policy and stop monitoring individual actions. Confirmations repeated dozens of times stop being a review, and they act only inside the tool that asks for them: a confirmation button does not stop a deployment request another system has already accepted. We discuss approval design in when AI agent controls become the problem. Put a person where the consequence is hard to reverse, and make the rest stoppable.

Keep stopping, repair and restart separate

Revoking access, stopping work, undoing effects and deciding whether to trust an environment answer different questions.

Revocation concerns future use of authority; its effect on existing sessions and accepted work must be checked. Stopping concerns the processes and jobs that can continue acting. Neither action restores an altered file, reverses an external change or recalls information already disclosed.

Repair therefore requires its own assessment. Establish what changed and what can be restored. Assess whether the environment remains trustworthy, including its configuration and anything that could run on restart. Where needed, rebuild from a known configuration rather than treating a quiet process as evidence of a clean environment.

Restart is a further decision. Confirm the intended access, resolve the relevant uncertainty and decide what evidence is sufficient to resume within the agreed scope. The ability to restart the tool does not establish that it is appropriate to do so.

When a client tells us “if the AI starts doing something wrong, we’ll just switch it off”, our answer is: “Switching it off stops the next action, not the one already running. By the time you notice, a job may be running elsewhere under a shared key, and the only off switch you have may also take down your builds or a developer’s account. So before we widen a workflow, we give it something small to switch off, then test that switching it off actually stops it.”

Before widening your workflow, write down the smallest boundary you expect to stop, the authority that makes it possible and the business operations that depend on it. Then exercise that boundary. If the result requires a wider interruption than expected, change the access or dependencies while the workflow is still limited.