The kill-switch for a 5-person team: how to turn off an AI agent when it goes wrong, with no IT department

When your self-built or vendor agent does something wrong on a Friday, can you actually stop it before Monday? For most 1-15 person teams in 2026, no. There is a pause button somewhere in the tool dashboard and a revoke step somewhere in the credentials list, and almost no small team has written down where they are before they need them. This piece is the no-IT-department version of the enterprise containment problem.

The enterprise framing is at AM-171, which covers the four-primitive containment architecture (purpose binding, kill switch, network isolation, credential revocation) and the Kiteworks 2026 Data Security and Compliance Risk Forecast figure that 60% of organisations cannot terminate a misbehaving agent quickly. Small teams are not measured separately in that survey; the structural exposure is the same and the operational consequence of an unrecoverable Friday incident is worse, because there is no security operations centre and no overnight on-call.

Pause is not the same as revoke

The single most important distinction at small-team scale.

Pause stops the agent running. The Zap toggle is off. The Make scenario is paused. The n8n workflow is disabled. The agent does not execute on its next scheduled run. The credential the agent uses to act is still valid, sitting in the vendor’s account, still trusted by every downstream system.

Revoke invalidates the credential. The API key is deleted in the vendor console. The personal access token is removed. The OAuth connection is severed. Anything else acting under that credential, anywhere in the team’s environment, will fail on the next call.

For routine misbehaviour (the agent is producing odd output but not harmful), pause is enough. For suspected compromise, a leaked credential, an agent acting against the team’s interest, or a vendor-side incident, revoke is required and pause alone is incomplete. The reason matters at small-team scale specifically: most 1-15 person teams share a single founder API key across three or four AI tools, so pausing one Zap does not stop the same key from being used by Cursor, Make, and the custom MCP server running on the founder’s laptop. Pause is local; revoke is global.

The credential side of this problem is the prerequisite work covered in the non-human identity starter kit for small teams. The kill-switch routine assumes per-agent credentials are already in place; if a single founder key is still being shared across multiple tools, run the starter kit first and come back.

The per-tool runbook

Six tools cover most 1-15 person teams. Each line below is checked on 26 May 2026; re-check on the next renewal because the tool UIs shift.

Anthropic API key. Console at console.anthropic.com → Settings → API Keys. Click Revoke on the affected key. Revocation is instant from the console; existing requests using the key fail on the next call; there is no grace period. There is no separate pause action for an API key; the revoke is the action. For per-tool isolation, the prerequisite is having one Anthropic key per tool rather than one shared founder key.

OpenAI API key. Platform at platform.openai.com → API Keys. Click the trashcan icon next to the key. Deletion is permanent and cannot be restored; you generate a new one and update the tools that depended on it. Again, no separate pause for an API key; the revoke is the action.

GitHub Personal Access Token. github.com → Settings → Developer settings → Personal access tokens, Fine-grained or Classic. Click Delete next to the token. The token stops working immediately; any deploy key created with the token is also removed. For organisation-owned repos, an org owner can revoke organisation-scoped tokens through the organisation token review page. For known-leaked tokens, the GitHub credential-revocation API accepts bulk-revoke requests.

Zapier. Each Zap has an on/off toggle in the Zaps list; that is the pause action. The credential revoke happens in My Apps / App Connections by clicking the menu icon on the connection and choosing Delete. Stopping a Zap does not delete its history; deleting an app connection means Zapier no longer has access to that account. Both are needed for a full containment action.

Make.com. Each scenario has an on/off toggle that pauses it. Connections are managed in the Connections section where they can be renamed, updated, or deleted. The connection-delete is the revoke action.

n8n. Workflow toggle is the pause. Credential delete in the n8n Credentials library is the revoke. The n8n documentation surfaces the critical nuance explicitly: deleting an OAuth credential in n8n does not revoke n8n’s access at the third-party app. The OAuth grant must also be revoked in the third-party’s account settings (Google, GitHub, Notion, Slack). For a complete revoke on an OAuth-based credential, two actions are required, in this order: delete in n8n, then revoke at the third-party.

The pattern in those six is consistent enough to generalise. Pause is in the workflow or scenario or Zap toggle (or for raw API keys, the revoke is the only action because there is no separate pause). Revoke is in the credentials or connections or keys section, and for OAuth-based credentials, also at the third-party. For SaaS-integration credentials specifically, the third-party-side revoke is the part most operators forget.

The 30-minute Friday drill

Three blocks, on a Friday morning when nothing is on fire.

Block one, 10 minutes: confirm the inventory. Open the AI tool inventory spreadsheet from the non-human identity starter kit. For each row, confirm the tool, the credential class, the location, and the access. If the spreadsheet is older than 90 days or new tools have joined the stack, refresh it before continuing. The drill depends on the inventory being current.

Block two, 10 minutes: drill one tool end-to-end. Pick the automation with the lowest blast radius (an internal Slack notifier, a daily summary email, a webhook with no downstream consequences). Execute the pause action through the actual tool UI. Wait for the next scheduled run or trigger it manually. Confirm the automation did not run. Document the time. Then revoke the credential it used (use a test credential where possible, or generate a new one and use the old one as the drill target). Confirm the credential is rejected on the next call. Document the time. The two timings are the basis of the runbook entries for that tool class.

Block three, 10 minutes: write the runbook entries. For each tool in the inventory, write three lines: the pause path, the revoke path, and the time-to-effect from the drill. For tools where the revoke does not propagate (the n8n OAuth case), write the second step explicitly. Pin the runbook in the team’s first channel. The runbook is now the artefact someone other than the founder can use on a Friday evening when the founder is in the back garden.

What this does not cover

The kill-switch routine handles the runtime containment layer. It does not handle the upstream selection question (which agent or automation to deploy in the first place, covered in picking the first AI agent for a small business), the shadow-AI capability layer (where an approved tool has shipped new agent capabilities you did not configure for, covered in the operator shadow-AI piece), or the credential-management layer (covered in the NHI starter kit). The kill-switch routine sits on top of the NHI work; without per-agent credentials, the revoke side of the routine cannot be selective.

The enterprise reading at AM-171 is reading-the-table material for an operator who sells AI services into enterprise clients; the four-primitive architecture is the language the client’s security team is using, and the small-team runbook here is the operator’s evidence that the equivalent control set exists at the operator’s own scale.

What “good” looks like at 1-15 people

A team that has run the drill can answer the kill question in three sentences to a client, an insurer, or a security questionnaire.

Every AI tool and automation running in our environment has a documented pause action and a documented credential-revoke action, with the path written next to the tool in our runbook. We tested the runbook end-to-end on (date) using a low-stakes automation; the pause took (time), and the revoke took (time) with downstream propagation confirmed. We re-test once per quarter and after any major tool change.

Three sentences. Same structural shape as the enterprise tabletop. Different scale; different cost; same operational answer to the same question.

Calendar this Friday morning

Thirty minutes, one person doing it. The inventory check is the longest block if the inventory is stale. The drill is fast on any single tool. The runbook entries are mechanical once the drill is done. Pin it before the day ends.

The cost is bounded. The absence of the cost surfaces the first time something goes wrong on a Friday night, the founder is unreachable, and the team is reading the Anthropic console for the first time trying to remember whether Revoke or Delete is the right button. Both are bad ways to learn.