Multiple AI Agents Share One Execution Identity

This page describes the nowisor-ai-shared-runas-identity check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIA-006). The check flags multiple agentic entities executing under one service account. Severity depends on whether the shared identity holds platform roles.

What this finding means

Two or more agents on your instance execute as the same identity. Every record they write therefore carries the same actor in sys_created_by.

Two consequences follow, and they are different problems:

1. Attribution loss. Post-incident you can establish that an agent acted, but never which agent, under whose prompt, from which trigger.
2. Least privilege becomes unreachable. The shared account's role set is necessarily the union of what every agent needs, so each agent inherits the reach of all the others.

Severity does not scale with the number of agents; it scales with whether the identity holds roles. A shared read-only reporting identity is untidy (MEDIUM); a shared role-holder is an attribution hole with real blast radius (HIGH). The evidence separates the two via any_identity_holds_roles.

Why it matters for your compliance

NIS2 Article 21(2)(b) - incident handling. The obligation implies logging sufficient to reconstruct an incident. Shared agent identities put a hard ceiling on reconstruction: the log records the account, and the account maps to N agents.

ISO 27001 A.8.15 (logging) requires logs of activities to be produced and kept - a log that cannot distinguish actors satisfies the letter and fails the purpose. A.5.16 (identity management) expects one identity per lifecycle, which a shared agent account breaks.

NIS2 Article 21(2)(i) and DORA Article 9(4)(c) are the least-privilege half of the finding.

The attack path

The union-of-privileges effect. Five agents share svc_ai. Agent A needs to read incident. Agent B needs to write sys_user_has_role. The shared account holds both, so Agent A - whose only job is summarising incidents - can write role grants. An injection against the least sensitive agent in the group reaches the most sensitive capability in the group.

The forensic dead end. An unexpected role grant appears, created by svc_ai. Which of the five agents did it? Which input triggered it? With a shared identity the investigation stops at the account boundary unless per-agent execution logs exist and can be correlated by timestamp - and the Agent Least-Privilege Report will tell you honestly whether your log retention even covers the window.

Why it happens. Creating one service account is easier than creating five, and the platform does not object. The cost only appears during an incident, which is the worst possible time to discover it.

How to fix it

Step 1 - one identity per agent. Create a dedicated service identity for each agent listed in the evidence.

Step 2 - grant each the minimum reach that agent needs. Do not copy the shared account's role set across - that reproduces the union problem with extra steps.

Step 3 - repoint each agent's run-as field to its own identity and re-test.

Step 4 - retire the shared account once nothing references it. Confirm first that no integration outside the agent estate depended on it; shared service accounts accumulate consumers quietly.

The payoff is that every subsequent agent finding becomes actionable: per-agent identities are what make per-agent usage correlation - and therefore evidence-grade privilege reduction - possible at all.

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.