Response Actions

A response action stops or tightens AI activity the moment something goes wrong. Netzilo takes response actions on its own: when an AI session is hijacked, for example by instructions hidden in an email the agent read, Netzilo places the session Under Inspection, and if it keeps going, isolates it within seconds, with no one watching.

Administrators take the same actions by hand. The widest of them is the AI Kill Switch: one isolation that stops all AI activity of a user, a group, a device, an agent or the whole account, on every device, browser and AI Gateway at once, with a clear reason, until you lift it. Isolating the Finance group, for example, stops every model call, tool call and AI chat of everyone in Finance, wherever they run.

You manage response actions under Edge > Governance, on the Actions tab. You also apply them directly from an AI session under Edge > Sessions.

2:01

Watch · 2:01

Contain a hijacked AI agent in seconds

A poisoned vendor email turns a finance AI agent against its company: Netzilo isolates the session on its own, then one AI Kill Switch stops all of Finance’s AI at once.

All how-to videos →YouTube ↗

How it works

There are two response actions:

When both apply to the same activity, isolation wins.

1. An administrator applies an action, or Netzilo applies one on its own when a guardrail catches a session, see Autonomous response.
2. The Netzilo Server keeps the action and sends it to every host that carries AI traffic: the Netzilo client on devices, the AI Gateway and the browser extension.
3. Each host enforces the action locally and reports back which actions it applied. Only then does the session show Under Isolation or Under Inspection.
4. The action holds until it is lifted, deleted or expires.

Where it applies and how fast

Each host keeps the actions on disk. An isolation holds across restarts of the host and while the Netzilo Server cannot be reached.

Group membership is followed automatically: a user who joins a group under isolation is isolated at the next sync, and one who leaves it is released.

The Actions list

The tab title shows the number of active actions when there is more than one.

Narrow the list with:

• the state: Active, Lifted, Expired or All;
• All actions, Isolation or Inspection;
• All sources, Administrator or Guardrail;
• the search box, Search response actions..., which matches the action and its reason.

Add a response action

Click Add Action. The Add Response Action dialog opens.

Click Add Action. The action reaches every host as described in Where it applies and how fast.

Scopes

Agent patterns. Enter an agent ID such as claude-code, or a glob pattern such as *-sdk-*, and press Enter. Matching ignores case and compares the pattern with the agent's program or name, as endpoint filters match agents.

All AI activity. Isolating all AI activity is the account-wide kill switch, so the dialog asks you to confirm it: All AI activity in your account will be blocked. Click Isolate All AI Activity to apply it.

One action holds up to 1,000 users, 1,000 devices, 200 groups, 200 sessions and 50 agent IDs or patterns. An account can have up to 500 administrator actions in force at a time.

Lift, edit or delete an action

• Edit: click the action's row. Edit Response Action opens, where you change the action, its scope, reason or expiry. Click Save Changes. A lifted action is a record and cannot be edited.
• Lift: choose Lift in the row's menu. The Lift response action? dialog shows what the action applies to and takes an optional reason for lifting. A lifted action stays in the list under Lifted, with who lifted it and why.
• Delete: choose Delete in the row's menu. The action is removed from the list and stops applying immediately.

To lift or delete several at once, select their rows and use Lift or Delete in the selection bar.

A lift reaches the hosts as fast as the action did. The session's badge clears once the host carrying it has applied the lift.

Act from an AI session

You can respond from where you see the problem, without opening the Actions tab.

In the session window, the header has a Response Action menu. It shows the action holding the session, if any, and offers:

Each item asks for a reason before it applies the action.

In the AI Sessions list, each row's menu (⋮) has Isolate, Inspect, Lift and Delete. Select several sessions to Isolate, Inspect or Lift them together. A lift from the list frees the selected sessions from the actions that name them; an action that covers them more widely, such as an isolation of their user or group, still applies, and the result names it with a link to Actions.

Status badges

The Status column of the AI Sessions list shows Under Isolation or Under Inspection, with the reason on hover. Other sessions show Active, Idle or Finished. The status filter next to the user filter, Any Status by default, shows only the sessions Under Isolation or only those Under Inspection.

A badge means the host carrying the session (the device, the AI Gateway or the browser) has really applied the action, not only that an administrator asked for it. A session whose host has not applied it yet shows no badge; the Response Action menu already shows the action in force.

Autonomous response

Netzilo responds to a hijacked AI session on its own, in seconds, with no one watching. It does this through guardrails that apply response actions, bound in a filter like any other guardrail. The Applied by column shows Guardrail and the guardrail's name, and the source filter Guardrail lists them.

The Cruise Control guardrails work in two steps:

The rules that keep autonomous response in check:

• An administrator's lift wins. An action an administrator lifted is not applied again by the same guardrail for that session.
• Actions applied by guardrails expire after 7 days, unless they are lifted earlier.
• An administrator can place a session Under Inspection by hand; the Cruise Control guardrails then treat it as flagged. Lifting the inspection ends the stricter checks.
• These guardrails declare the controls capability and load only on hosts that support response actions; older hosts skip them.

To write your own guardrail that reads or applies a response action, see Detection Rules.

What people and agents see

An isolated call is refused with one line that the person or the agent can read:

Response action: AI access is isolated by an administrator. Reason: Investigating a suspected data leak. Reference: <action id>.

When a guardrail applied the action, it reads isolated by a guardrail, with the guardrail's reason.

• Coding agents and apps on a device and agents through the AI Gateway receive the refusal as the answer to their call, and most show it to the user.
• In the browser, the extension shows the message as a notification on the page, since the web app itself shows only a generic error.
• A stream in progress is cut when the isolation arrives.

Inspection alone shows nothing to the person or the agent. What they see depends on what the guardrails do with the session.

Activity log

Every change is recorded in Activity > Events:

Each row names the action, its scope, the reason and the expiry, for example Isolation applied to Finance. Reason: …. Calls refused by an isolation are recorded with the response action's reason. See Event reference.

Use the API

Response actions are managed through the Netzilo Server REST API with a personal access token of an administrator or an agent (service user).

The body of POST and PUT /api/ai/controls:

When one action names several of these lists, a call must match each of them: users, groups and devices together say who, agents which agent, sessions which session.

curl -s -X POST -H "Authorization: Token $NZ_TOKEN" -H "Content-Type: application/json" \
  https://srv.netzilo.com/api/ai/controls \
  -d '{"effect": "kill", "groups": ["<group id>"], "reason": "Suspected compromise of the finance agent", "expires_at": "2026-10-23T09:00:00Z"}'

On a self-hosted server, use your own domain instead of srv.netzilo.com. Each action in the list carries its state (active, lifted or expired) and, while active, hosts, the hosts it reaches that reported in the last day, and applied, how many of them applied its latest change.

Requirements

• Netzilo Server v5.3.590 or later.
• Browser extension 5.2.578 or later. Older extensions do not apply response actions.
• Netzilo clients and AI Gateways of this release. A host older than this release does not apply response actions, its sessions never show a badge, and the guardrails that apply response actions do not load on it.
• Agent patterns need this release on the host as well: an older host treats a pattern such as *-sdk-* as a literal agent name.

Troubleshooting

The session does not show Under Isolation. The host carrying it has not applied the action yet. A device applies it in under a second, the AI Gateway within about 2 seconds and the browser extension within about 30 seconds. A host that is offline applies it when it reconnects; an older host never does, see Requirements.

A user is still isolated after you lifted the action. Another action covers them: their group, their device, their agent or all AI activity. Filter the Actions tab by Active and look for the wider action. A lift from a session names the wider actions that still apply.

A guardrail isolated a session that was legitimate. Lift the action. The same guardrail does not apply it again for that session. If it happens often, review the guardrail's events in Activity > Events.

The agent pattern does not match. Check the agent's ID in the session's User · Agent column. Matching ignores case; a host older than this release matches only the literal name.

You cannot add an action. The account has 500 administrator actions in force. Lift or delete actions you no longer need.

Related Documentation

• AI Sessions - status badges, the status filter and the session menus
• Guardrails - the guardrails that apply response actions
• Detection Rules - session_control() and raise_control() in scripts
• Browser Extension - response actions in the browser
• AI Gateway - where gateway traffic is isolated
• Event reference - the response action events