Ambiguous Actor Attribution

Ambiguous actor attribution occurs when available logs or records show that an action happened, but do not identify the specific synthetic subject, human operator, tool, connector, workflow, or vendor-controlled component that caused it. The evidence may be intact and accurate, but still too general to support attribution.

This condition is distinct from log deletion or trace tampering. In ambiguous actor attribution, the problem is not necessarily that evidence was removed or altered. The problem is that the recorded actor is too broad, shared, or indirect to identify the real source of the action.

The primary risk is collapsed actor identity. A record update, message, tool call, or system change may be logged under a shared service account, delegated human identity, generic application identity, or workflow bot. The log may truthfully record that the shared identity acted, but fail to show which synthetic subject, operator prompt, tool call, or invocation path produced the action.

A related risk is containment uncertainty. If investigators cannot identify the responsible actor, they may have to disable broad identities, revoke multiple connectors, suspend unrelated workflows, or take larger containment actions than necessary. Conversely, they may fail to contain the true source if the apparent identity is only a shared proxy.

Investigators should review identity provider logs, service account ownership, non-human identity records, OAuth grants, connector identities, prompt and response logs, tool-call records, session context, agent identifiers, vendor audit fields, and actor attribution metadata. Particular attention should be given to shared service accounts, missing agent IDs, actions recorded only under a human identity, multiple agents using one credential, and vendor logs that collapse model, tool, and user activity into one actor.

Investigative Relevance

Ambiguous actor attribution is relevant because synthetic subjects often act through borrowed, shared, delegated, or vendor-managed identities. Even complete logs may be insufficient if they identify only the account used, not the synthetic subject or invocation that caused the action.

This condition is especially relevant where synthetic subjects use shared service accounts, delegated user sessions, marketplace connectors, Model Context Protocol (MCP) servers, human-attributed actions, vendor-hosted AI features, or orchestration platforms with multiple agents operating through the same identity.