Active AI Agent With No Review Or Approval Trail

This page describes the nowisor-ai-agent-unreviewed-prod check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIA-002). The check flags agents active on a production-looking instance with no review field value and no approval record. Production detection is an instance_name heuristic and is labelled as one.

What this finding means

Agents are active on what appears to be a production instance with no evidence that anyone reviewed them.

What counts as review evidence. Two sources only: a value in the resolved review/approval field, or an approval record against the agent. A recent sys_updated_on is deliberately not treated as review - an agent edited yesterday by the person who built it is not a reviewed agent, and inferring approval from activity would make the check pass exactly where governance is weakest.

Three honest limits.

• Non-production instances are skipped entirely - an unreviewed agent on a sandbox is not a production control failure.
• Where the instance reports no name, its production status cannot be established and the finding drops to INVESTIGATE.
• Where the release exposes no review field at all, the result is not_applicable: the platform is not recording review state, so its absence is not evidence of a gap.

Why it matters for your compliance

NIS2 Article 21(2)(e) covers security in systems acquisition, development and maintenance. An agent is a system component that reached production without a security gate.

NIS2 Article 21(2)(f) requires assessing the effectiveness of your measures - an unreviewed agent has never been assessed at all.

ISO 27001 A.8.25 (secure development life cycle) is the direct control: agents are built, configured and promoted like any other artifact and belong in the same lifecycle. A.5.16 covers the identity half.

DORA Article 9(4)(a) requires a documented information security policy; agents outside the review process are outside the policy.

The attack path

The drift problem. An agent approved at launch is not approved forever. Its tool access changes, the data it can reach grows as ACLs evolve, and its autonomy level can be raised by a single field edit. Without a review checkpoint, none of those changes meet a gate - and the agent that was safe in Q1 may not be in Q3.

The insider path. An agent created without review is the cleanest insider persistence mechanism the platform offers. It is a legitimate platform object, it runs on a trigger, and nothing in the change process asks about it. Contrast a business rule or scheduled job, both of which attract update-set scrutiny.

Why approval records matter more than a field. A review field can be backfilled by anyone with write access. An approval record carries an approver identity and a timestamp, which is what an auditor will actually ask for. The check accepts either, and the evidence records which source satisfied it.

How to fix it

Step 1 - review what the agent can actually do: its permissions, prompt/instructions, tool access, and autonomy level.

Step 2 - record the outcome where the platform can see it - the resolved review field, or an approval record against the agent. Evidence that lives only in a wiki does not survive an audit.

Step 3 - set a recurring review interval. Agents drift as their tools and data reach change; a one-time approval decays.

Step 4 - treat unrecognised agents as unsanctioned deployments. The evidence carries sys_created_by and sys_created_on.

If the finding is INVESTIGATE: the instance did not report an instance_name, so confirm the environment before treating this as a production gap.

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.