What should organisations do when insider cases involve both humans and AI counterparts?

When an Insider Case Spans Human and AI Actions, What Is the Real Unit of Investigation?

Insider events involving both a person and an AI counterpart are not just account misuse cases. They are workflow cases, because the material question is how human intent, model output, tool access, prompt content, and downstream execution combined into a single chain of action. That matters for attribution, containment, and whether the organisation can explain the behaviour without guessing. In practice, the investigation scope must follow the activity path, not stop at the login event.

That wider lens is especially important where AI systems can generate, transform, or trigger actions faster than a human reviewer can intervene. A narrow review of the person’s session often misses the more consequential control failure: a trusted workflow was allowed to turn a prompt, retrieval result, or automation into externalised impact. For that reason, the evidence set should include prompts, tool calls, approvals, output handoffs, and any policy exceptions that enabled the chain.

In practice, many security teams discover the accountability gap only after the AI-assisted action has already propagated into records, systems, or customer-facing outputs.

How Should Organisations Separate Human Misuse from AI-Assisted Misuse?

The first step is to treat the human and the AI as distinct actors with different forms of access and different evidentiary trails. A person may authorise or steer the task, but the AI may execute steps, synthesize data, or call tools in ways that the human did not explicitly intend. That is why identity evidence alone is insufficient. Teams need to reconstruct sequence, authority, and effect.

Useful investigation questions include: who initiated the workflow, what data the AI could see, what prompts or instructions shaped the output, what tools the AI could invoke, and which downstream system accepted the result. If the AI operated through short-lived tokens or delegated access, that credential path becomes part of the incident narrative. If the human approved a generated action without understanding the model’s confidence or source data, that also matters.

• Preserve prompts, completions, tool invocations, and approval events together as one case file.
• Correlate identity logs with application logs and automation logs before drawing conclusions about intent.
• Distinguish between misuse of privilege and misuse of generated output, because the response differs.
• Identify whether the AI had autonomous execution authority or only advisory influence.

This is where OWASP NHI Top 10 becomes useful as a lens on identity-bound agent risk, and CISA’s cyber threat advisories help frame the broader abuse and compromise patterns that can show up in mixed human-AI workflows.

These controls tend to break down when AI can act across multiple business systems with delegated access and the organisation cannot reconstruct which step was human-authored versus model-generated.

Where Do Mixed Human-AI Cases Create the Hardest Governance Edges?

Tighter oversight often slows legitimate automation, so organisations have to balance investigatory clarity against operational speed. The hardest edge cases are usually not obvious misconduct, but ambiguous responsibility: a human asked for one thing, the model produced another, and an automated integration executed the result.

Best practice is evolving, but current guidance suggests treating these cases by decision ownership rather than by a simple blame assignment. Legal and HR may need to assess employee conduct, while security evaluates access misuse and control failure, and identity teams verify whether delegated access or token scope was excessive. When the case involves model behaviour that was materially shaped by prompts or retrieval data, AI governance should review whether the workflow itself was permitted to behave that way.

Operationally, the organisations that cope best are the ones that can answer three questions quickly: what the human knew, what the AI was allowed to do, and what the system actually did. If they cannot answer all three, the case should be treated as a governance failure, not just an employee issue.

Practitioner Guidance:

What to prioritise: Build the case around the workflow boundary first. If the AI had any ability to transform, approve, or execute actions, capture those artefacts before interviewing the individual involved.

Decision rule: If you cannot separate advisory AI use from autonomous AI action, treat the event as a shared-control incident and escalate cross-functionally rather than forcing a single-owner narrative.

What good looks like: A mature response can show who initiated the action, which machine or model identity participated, what access was exercised, and where human oversight stopped being meaningful.

Practitioner takeaway: The key mistake is assuming that human intent alone determines accountability; in mixed cases, accountability depends on how authority was delegated, how the AI behaved, and whether the organisation can prove the chain end to end.

Related resources from NHI Mgmt Group

• How should organisations govern AI systems that route support cases between humans and machines?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• How do organisations operationalise NHI ownership at scale?