No Data-Protection Control Over Agent-Readable Data
This page describes the
nowisor-ai-llm-payload-maskingcheck from the nowisor Instance Scan Pack v1.2.0 (ai-agent-securitygroup, spec AIG-002). The check flags an active agentic surface on an instance with no data policies, classification records, field encryption or encrypted dictionary attributes configured.
What this finding means
Active agents operate on this instance and no platform data-protection mechanism is configured over the data they can read. Any one of these satisfies the check:
- an active data policy
- a data classification record
- field-level encryption
- an encrypted dictionary attribute (
password2,encrypted_text)
What this finding does not claim. A read-only scan sees configuration, never payloads. No assertion is made that any prompt carried personal data - that would be an accusation the scan cannot support. The finding is narrower and verifiable: the platform is applying no data-protection control to what these agents can read.
The check stays silent when every agent is inactive, because the control is moot there.
Why it matters for your compliance
NIS2 Article 21(2)(h) covers policies on the use of cryptography and encryption - the mechanism class this finding says is absent. 21(2)(i) covers access control.
ISO 27001 A.8.24 (use of cryptography) is the direct control.
DORA Article 9(3)(b) requires minimising the risk of unauthorised access to data. An unprotected field readable by an agent that can call an external endpoint is that risk, unmitigated.
OWASP LLM02:2025 (Sensitive Information Disclosure) is the industry framing.
The attack path
The path is short. An agent reads a record. The record contains personal data. The agent's prompt, including that data, goes to a model endpoint. Whether it is retained, logged or trained on is the provider's decision, governed by terms someone may or may not have read.
Why configuration is the right thing to check. You cannot inspect every prompt, and neither can we. What you can do is ensure the sensitive fields are protected before they can be read - so the question becomes structural rather than per-request. That is why the absence of any mechanism is the finding.
Combines with residency and shadow endpoints. Unprotected data plus an unsanctioned endpoint plus a non-EU region is the full exposure. Each check reports its own layer honestly rather than one check overclaiming all three.
How to fix it
Step 1 - determine actual read reach. The Agent Least-Privilege Report resolves this per agent where log coverage permits; otherwise start from the run-as identity's roles.
Step 2 - apply at least one mechanism over the sensitive fields: a data policy, a classification record, or field-level encryption.
Step 3 - configure Now Assist data handling in the Now Assist Admin console. Those settings are UI-only and expose no property this check can read, so they must be verified by hand.
Step 4 - re-run to confirm the mechanism is visible to the scan.
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.