Agent Action Logging Disabled Or Below Retention Floor

This page describes the nowisor-ai-agent-audit-retention check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIG-003). The check flags auditing disabled on agent tables, a missing execution-log source, or retention shorter than the 90-day correlation lookback.

What this finding means

Agent action logging is insufficient for post-incident review. Two distinct failure modes, reported separately:

1. Auditing is off on the tables agent activity lands in - the obvious failure.
2. Retention is shorter than the review window - the silent one. The dashboard shows logs, the control looks satisfied, and evidence older than the window is gone.

The retention floor is 90 days, matching the default correlation lookback.

This check is also the precondition for the module's most valuable output. A DORMANT verdict - "this permission is held and never used, revoke it" - is only legitimate when retention spans the full lookback. Below the floor, the Agent Least-Privilege Report degrades every affected pair to UNKNOWN-USAGE rather than recommending revocations it cannot justify. The finding states that consequence, because it is the part customers do not expect.

Why it matters for your compliance

NIS2 Article 21(2)(b) - incident handling. The obligation implies logging sufficient to reconstruct an incident. Retention below the review window means reconstruction fails for anything older, silently.

ISO 27001 A.8.15 (logging) and A.8.16 (monitoring activities) both require logs that are produced and kept.

DORA Article 10(1) requires detection of anomalous activities, which depends on having the telemetry to detect them in.

The attack path

What you lose without the trail. You can establish that an agent acted. You cannot reconstruct what it read, what it changed, or which input drove it. For an agent that can be steered by untrusted text, that last question is the whole investigation.

The silent-failure property. An attacker does not need to disable logging if retention is already shorter than the time to detection. Waiting is sufficient - and unlike a disabled audit flag, short retention triggers no alert and looks like a working control on every dashboard.

Attribution compounds it. Combine short retention with a shared run-as identity and the investigation has neither a window nor an actor. Both checks fire independently for that reason.

How to fix it

Step 1 - enable auditing on the flagged tables: System Definition > Dictionary, filter Table =

Step 2 - confirm an execution-log source exists and is being written for your agent classes.

Step 3 - raise retention to at least 90 days on the execution log and on sys_audit.

Step 4 - re-run the Agent Least-Privilege Report. Permissions that reported UNKNOWN-USAGE can become actionable DORMANT verdicts once coverage spans the window. This is the step that converts a logging fix into privilege reduction.

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.