AI Agent Without Assigned Owner

This page describes the nowisor-ai-agent-unowned check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIA-001). The check flags agentic entities whose owner field exists on this release but is blank. It resolves the owner column from sys_dictionary rather than assuming a name, and reports not_applicable where the release exposes no owner column at all.

What this finding means

One or more AI agents on your instance have no owner recorded. The check distinguishes three states and only one of them is a finding:

That split matters. If the check fired whenever it could not find an owner field, it would flag every agent on every release whose owner column happens to be named differently - a false positive dressed up as a governance gap. Absence of evidence is not evidence of absence, and the evidence object names the exact column that produced each verdict (owner_fields_resolved) so every value is auditable back to a real field.

Why it matters for your compliance

An agent is a non-human identity that acts on your data. Ownership is the control that makes every other agent control enforceable: without a named owner there is nobody to approve its permissions, nobody to review its prompt when the business process changes, and nobody accountable for retiring it.

NIS2 Article 21(2)(i) covers access control policies and asset management. An unowned agent fails the asset-management half outright - it is an active asset with no custodian.

ISO 27001 A.5.16 (identity management) requires the full lifecycle of identities to be managed. An agent identity with no owner has no lifecycle: nothing triggers its review and nothing triggers its removal.

DORA Article 9(4)(c) requires logical access to be limited to approved functions. Approval implies an approver; an unowned agent has none.

The attack path

The exposure is not that an unowned agent is itself malicious - it is that an unowned agent is operationally indistinguishable from one an attacker deployed.

An attacker with enough access to create an agent gains a durable, policy-shaped foothold: the agent runs on a schedule or on a trigger, under a service identity, doing exactly what agents legitimately do. Detection depends entirely on somebody noticing an agent nobody claims. If your estate already contains unowned agents, that signal is gone - the attacker's agent looks like the others.

This is why ownership pairs with registry coverage (nowisor-ai-control-tower-coverage-gap): ownership tells you who is accountable, registration tells you whether the agent was ever sanctioned. An agent missing both is the highest-priority triage item in the module.

How to fix it

Step 1 - assign an accountable owner. For each flagged entity, open the record in the source table named in the evidence and set the owner field to a named person or group with authority over the agent's permissions. A distribution list is not an owner.

Step 2 - reconcile with your catalog. Record the same owner in AI Control Tower (or whatever sanctioned catalog you keep) so ownership and registration agree. Divergence between the two is how agents get orphaned again after a reorganisation.

Step 3 - close the creation path. Ownership drift is a process defect, not a data defect. Decide who may create agents, and make the owner field mandatory at creation so this check has nothing to find next quarter.

If the check reports not_applicable: your release does not expose an owner column on the agent tables. Track agent ownership outside the agent record (your AI asset catalog is the right place) and re-run after any platform upgrade that adds one.

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.