AI Agent Can Write Without A Human Gate

This page describes the nowisor-ai-guardrail-hitl check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIG-001). The check flags active agents holding a write-capable role that are neither in supervised execution mode nor covered by an approval record.

What this finding means

One or more active agents can change platform state with nobody in the loop.

Two gates are recognised, and either satisfies the check:

After-the-fact log review is deliberately NOT a gate. Reviewing a write once it has landed is oversight, not control - if the only safeguard is that somebody may read the audit log later, the agent is unattended.

Write capability comes from the run-as identity's roles, not from the agent's instructions. An identity holding no roles cannot write regardless of what its prompt says, and is not reported.

Why it matters for your compliance

NIS2 Article 21(2)(a) requires policies on risk analysis; an unattended write path is an unassessed risk. 21(2)(i) covers access control.

ISO 27001 A.8.2 (privileged access rights) is the operative control - an agent with unattended write access is a privileged actor with no approval step.

DORA Article 9(4)(c) limits access to approved functions. "Approved" implies an approval act, which is exactly what this finding says is missing.

OWASP LLM06:2025 (Excessive Agency) is the canonical framing. EU AI Act Article 26 may apply, but only for high-risk deployments under Annex III - marked conditional.

The attack path

The compounding path. This finding is rarely dangerous alone; it is dangerous in combination. Pair it with the prompt-injection exposure check and the sequence becomes: untrusted text reaches the agent's context, the agent decides to act, and no gate exists between the decision and the write. Each check reports one link; the chain is the actual exposure.

Why unattended is the default. Approval steps add latency, and agents are usually bought to remove latency. The gate gets skipped for exactly the reason the agent was deployed - which is why this needs a scanner rather than a policy document.

Blast radius follows the identity. An ungated agent whose identity holds admin is a different proposition from one that can update a single field. The evidence lists the write roles per agent so triage can be ordered by consequence.

How to fix it

Step 1 - supervised mode where available. The cheapest fix: the platform's own gate, no flow changes.

Step 2 - otherwise, an approval activity in the flow the agent triggers, so a human accepts the action before it commits.

Step 3 - or reduce write reach until unattended action is acceptable. An agent that can only read needs no gate, and read-only is often enough for the use case.

Order the work by the write_roles in the evidence: agents holding broad roles first.

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.