No Machine-Checkable Agent Deactivation Path
This page describes the
nowisor-ai-kill-switch-absentcheck from the nowisor Instance Scan Pack v1.2.0 (ai-agent-securitygroup, spec AIG-005). The check reports agent classes with no technical deactivation lever as INVESTIGATE, with a manual-attestation field - never as a failure.
What this finding means
One or more agent classes present on this instance expose no machine-checkable way to stop them. Four levers are tested, and any one satisfies the check:
| Lever | Meaning |
|---|---|
| per-class disable property | a property resolves that gates the class |
| plugin toggle | the class's plugin can be deactivated |
| per-entity active flag | an active column an operator can flip |
| revocable run-as role | removing a role stops execution |
Why this never fails. "A documented kill procedure exists" is not scannable. A runbook is invisible to a read-only scan, so an organisation with an excellent tested procedure would score identically to one with none. Emitting FAIL would assert the absence of something the scan cannot see - the inverse of the discipline the rest of this module holds to. So the check reports what it observes and asks you to attest to the rest, via a manual_attestation field in the evidence.
Why it matters for your compliance
NIS2 Article 21(2)(b) incident handling and 21(2)(c) business continuity and crisis management both assume you can contain a malfunctioning component. An agent you cannot stop from the platform is a containment gap.
ISO 27001 A.5.24 (information security incident management planning and preparation) is the operative control: it explicitly covers developing technical containment capability in advance, which is precisely what a kill switch is. A.5.26 (response to information security incidents) covers the procedural half - the part this check can only obtain by attestation.
DORA Article 9(4)(c) limits access to approved functions - withdrawing approval requires a mechanism.
The attack path
When you need this, you need it in minutes. An agent behaving unexpectedly - looping, mass-updating, acting on injected instruction - is a live incident. If the only lever is a vendor support ticket, containment time is measured in hours and bounded by someone else's SLA.
The untested-procedure failure. Many organisations have a documented procedure that has never been executed. It references a console that changed, or a role held by someone who left. The document exists; the capability does not. A technical lever is testable in a way a runbook is not, which is why the remediation prefers adding one over attesting to a procedure.
Availability, not just confidentiality. Most agent findings concern data or privilege. This one concerns your ability to make the agent stop - which is the control every incident response ultimately depends on.
How to fix it
Step 1 - answer the attestation. Does a documented procedure exist to stop each listed class, and has it been tested? Record the answer against the manual_attestation field.
Step 2 - prefer a technical lever. Add a per-entity active flag, or a dedicated revocable role that gates execution, so the control becomes verifiable rather than attested.
Step 3 - rehearse it. An untested kill switch is an assumption, and the moment you need it is the worst possible time to discover it does not work.
How this check stays honest
Every check in the ai-agent-security group is enumeration-driven: table and
field names are resolved from sys_db_object and sys_dictionary on your
instance, never asserted from a hardcoded list. The sn_aia namespace is
paid-SKU gated and cannot be verified against a ServiceNow developer instance, so
asserting its identifiers from documentation alone would risk exactly the
fabricated-identifier problem this codebase audits for.
Two consequences you will see in the output:
- An absent plugin produces
not_applicable, never a pass. The absence of Now Assist is not a security win; it means the control is out of scope. A check that silently passed would let a customer believe they were assessed on something that was never examined. - An unresolvable field produces
not_applicable, not a finding. Where the release does not expose the column a check needs, the check says so and names it. Firing anyway would flag healthy instances on releases we simply cannot read.
All detection is read-only. No record contents are inspected or transmitted.