The insider threat playbook for the AI agent era. The credentials are legitimate. The behavior looks normal. The misuse runs at 100× the scale. Capability is not intent, and the response framework must separate them.

Part of the AI IR Overlay™ framework. See CONTENT_MAP.md for the full repository map.

Playbook 12: Insider Threat 3.0 (AI-Driven Misuse)

Insider Threat 1.0 was the disgruntled employee with credentials. Insider Threat 2.0 was the user with anomalous behavior. Insider Threat 3.0 is the AI agent with legitimate credentials performing expected actions for unintended purposes, or the human using an AI agent to execute insider misuse at scale that previously took weeks.

Premise

Twenty-five years of insider threat programs taught security teams how to catch humans abusing credentials. The programs were built around three patterns that AI agents break.

The first pattern was operational friction. Bulk searching, aggregation, and exfiltration took time, attention, and visible effort. DLP, UEBA, and SOC dashboards were tuned to the resulting patterns: large queries, multi-step exports, after-hours access. AI agents remove that friction. “Summarize every contract that mentions termination for convenience” compiles in seconds what previously took a paralegal weeks. The action does not require malicious code, technical expertise, or visible effort. It looks like a normal business request, while quietly producing the kind of dataset that previously tripped every DLP rule on the network.

The second pattern was identity-as-actor. Insider threat programs assumed a human at the keyboard. UEBA models built behavioral baselines on user accounts and flagged deviation. AI agents change that assumption. The credentials are the user’s. The session is the user’s. The audit logs attribute the action to the user. But the prompt that drove the action came from the user. The interpretation came from the agent. The retrieval scope came from the agent’s tooling. The output destination came from the agent’s defaults. The agent is a mediator between intent and action, and traditional insider programs do not model the mediator.

The third pattern was drift over time. Insider risk programs typically watched users for sudden behavioral changes. AI agents drift gradually. Memory accumulates context the user did not explicitly authorize. Tool authorizations granted for project A get used for project B. System prompts edited months ago shape behavior nobody currently audits. The agent’s effective behavior on June 27 is not the behavior shipped on March 1, and no insider threat program is configured to notice that drift unless something dramatic happens.

This playbook uses “Insider Threat 3.0” as a working label for the AI-mediated variant of insider risk. The 1.0/2.0/3.0 versioning is the framework’s own framing of how insider threat analysis has progressed (credential-era → behavior-era → AI-era), not an industry-accepted taxonomy. The label is intended as shorthand for the operational discipline below; readers attached to other labels (AI-mediated insider risk, agent-assisted misuse, AI-augmented insider threat) should feel free to substitute. What matters is that the response framework changes with it. The framework addresses two concrete scenarios that the prior insider threat generations conflate or miss entirely:

Both scenarios require the same investigative discipline: separate capability from intent from impact. Investigate each independently. Do not conflate “the agent could do X” with “the user wanted X” with “X actually caused harm.” Most insider threat investigations fail at this triad.

Mental Model clauses engaged: Acts (primary). The agent operates inside the user’s authorized perimeter; its tool list is a delegated extension of the user’s privileges. Remembers (secondary). Memory accumulates context the user did not explicitly authorize, and that context shapes the agent’s behavior over time. Retrieves (secondary). Corpus access at agent speeds scales beyond what the user could browse manually, which is the central attack pattern for the human-with-agent scenario.

Use this playbook when: an AI agent is suspected of operating against organizational intent (drift, compromise, prompt injection); a human user is suspected of using an AI agent to compile or exfiltrate sensitive data at scale; UEBA flags a user as anomalous and an AI agent is involved; HR or Legal opens an investigation involving AI agent use; or Playbook 11 (Monitoring) detection rules fire on capability-family signals that suggest scope abuse.

First-Hour Actions

The first hour of an Insider Threat 3.0 incident has one job that previous insider threat playbooks did not have to do: engage HR and Legal at minute zero, not minute sixty. AI-augmented insider cases are joint by default. Containment without HR concurrence creates remediation problems. Investigation without Legal concurrence creates discoverability problems. Both functions need to be in the room (or on the bridge) from the start.

The 60-minute Insider Threat 3.0 triage

Minute Action Owner
0–10 Convene HR + Legal + Incident Commander + Agent Owner, in that order. Insider cases are not security-only investigations. Document the convening time and attendees. Incident Commander
10–25 Classify the scenario. Human-with-agent (the user is the suspect), agent-as-insider (the agent itself is misaligned), or undetermined (investigate both branches). The classification determines the containment response. Misclassification at this step degrades every later step. Incident Commander + HR
25–35 Contain the agent’s access without containing the user yet. Suspend the agent for the suspect user. Do not suspend the user’s broader access. This preserves evidence (the user can still be observed) and follows HR/Legal protocols (suspending a user before investigation is closed creates wrongful-action exposure). SOC + IT Operations
35–45 Walk the Six Triage Questions with one extension: who prompted, and why? Pull the prompt history for the agent under suspicion. Identify the requesting user identity for every prompt in the suspicious window. The prompts are evidence. Incident Commander
45–55 Activate Mode M2 Approvals corpus-wide. Every bulk read, summarize-and-compile request, and export across all users in the affected corpus is queued for human approval. This catches downstream copycats and gives the investigation breathing room. Tier-1 SOC
55–60 Snapshot the Insider-Threat Evidence Set: A (prompts, with requesting user identity), B (tool calls), C (retrieval traces), F (downstream identity correlation). Plus the credential-event log from Playbook 07 and detection records from Playbook 11. The combined picture is the case file. Detection engineer + Incident Commander

Discipline: in single-user insider investigations, the user’s identity is the case. In AI-mediated insider investigations, the prompt is the case. Who asked is the question that drives the rest. Without prompt-level identity attribution, the investigation reverts to inference.

Critical rule from HR/Legal: the user under suspicion is not informed of the investigation. The user is not suspended. The user is not interviewed. This is HR and Legal’s call to make. Security’s role in minute zero is to preserve evidence and contain the agent, not to act on the user.

Containment Options

Containment for an Insider Threat 3.0 incident is more nuanced than other incident classes because containment affects three parties: the agent, the suspect user, and the corpus. Each requires a separate decision.

Mode mapping for insider-threat-class incidents

Mode Use when Containment scope
M1 Read-Only (corpus-wide) The corpus is sensitive (HR records, financial data, M&A documents) and broad write access is unnecessary during investigation All users in the corpus lose write through the AI agent. Reads continue.
M2 Approvals Required (corpus-wide) Bulk-summarize and export requests must be gated while the investigation runs Every Tier-2 read and write across the corpus queued for approval. This is the default first move for Insider Threat 3.0.
M3 Tool Tiering (export/share disabled) The specific harm vector is distribution (the data was retrieved; the export step is where it leaves the org) Disable export, share, and external-send tools across the agent fleet. The agent can still retrieve and summarize internally. Distribution is blocked.
Agent suspended for user Single user is the suspect; their broader access remains for investigation visibility The agent is unavailable to that user only. Other users continue normally.
M4 Full Disable (corpus-scoped) Active distribution is confirmed AND HR/Legal authorize Agent offline for the affected corpus. Playbook 07 snapshot-before-revocation sequence applies for any credential rotation.
M4 Full Disable (agent-wide) The agent-as-insider scenario is confirmed and drift or compromise is the diagnosis Agent offline entirely. Treat as a Playbook 11 capability-anomaly incident in parallel.

The classification-drives-containment principle

The first major investigative decision is which scenario you are in. The containment response differs by scenario:

Scenario classification Default containment Rationale
Human-with-agent (drift, compromise, intentional misuse by user) M2 Approvals corpus-wide, agent suspended for user, user NOT suspended Preserves evidence; respects HR/Legal investigation protocols
Agent-as-insider (drift, compromise of agent itself, prompt injection cascade) M4 Full Disable on agent; Playbook 07 credential sequence The agent is the entity acting against intent; containment is at the agent layer
Undetermined M2 Approvals corpus-wide, no agent suspension yet, preserve both investigative branches Cannot prejudge the case; preserve evidence for both possibilities

Misclassification is the most common Insider Threat 3.0 failure. The detection signal (an agent doing something concerning) does not name the cause. The investigator’s first job is to distinguish.

Evidence Priorities

The Insider Threat 3.0 evidence set extends the Minimum Evidence Set A–F with explicit attention to the capability/intent/impact investigator triad.

The investigator’s triad: separate, do not conflate

Dimension What it answers Where the evidence lives
Capability What could the agent do at the time of the incident? AI-BOM tools, retrieval, and identity sections at incident time (Type E)
Intent What did the requesting user ask for, and what was the agent’s role definition? Prompt records (Type A) with requesting user identity; system prompt and role definition; tool authorization rationale
Impact What actually happened in downstream systems? Tool-call ledger (Type B), retrieval traces (Type C), downstream SaaS audit logs (Type F)

Conflating these dimensions is the most common investigative failure. “The agent could do X” is not “the user wanted X.” “The user wanted X” is not “X actually caused harm.” HR and Legal will challenge investigations that confuse the three. Anchor every finding to a specific dimension.

Evidence priorities ranked for Insider Threat 3.0

Code Evidence Type Priority Why it matters
A Prompt and Response Record Critical The prompt is the intent evidence. Capture verbatim with the requesting user identity attached. Without prompt-level identity attribution, the agent cannot be distinguished from the user.
C Retrieval Traces Critical What documents the agent retrieved, with versions, scores, and corpus identity. The retrieval traces show the capability the user accessed through the agent.
B Tool-Call Ledger Critical The actions the agent took based on the prompt. Particularly: bulk operations, export calls, and external-share calls.
F Identity and SaaS Audit-Log Correlation Critical The downstream blast radius. Where the agent’s output went after the agent produced it.
E Configuration Snapshot High System prompt at incident time, role definition, tool authorization rationale. The intent vector lives here. Drift between the documented intent and the active configuration is itself a finding.
D Memory Snapshot High if memory scope: shared or per-user with significant retention Memory drift contributes to rogue behavior over time. For the agent-as-insider scenario, the memory at incident time is causally relevant.

Insider-Threat-specific captures

In addition to A–F, capture:

Operational requirement: the full insider-threat evidence set must be exportable within 60 minutes of incident declaration, with the requesting user identity correctly attributed to every prompt in the window. If the identity attribution gap exceeds 5% of prompts in the window, this is the highest-priority Playbook 18 hardening item from this incident.

CIA+T Impact Assessment for Insider Threat 3.0 incidents

The investigator’s triad (capability / intent / impact) is the internal forensic discipline; the CIA+T impact framing from Playbook 05 (Executive Decision-Making) is the external accountability discipline the Executive Decision Packet uses for materiality and disclosure. The two are complementary: the triad determines what happened; CIA+T determines what to communicate to executives, regulators, and customers. Both frameworks apply to insider-threat scenarios.

Dimension Insider-threat question What to capture
Confidentiality What regulated or sensitive data did the agent access on the user’s behalf? Was access scope appropriate to the documented business need? The full retrieval trail (Type C) per user, with corpus classifications; the per-corpus access scope vs the user’s role-based authorization; PII/PHI/payment-card exposure counts
Integrity Were any records altered or created by the agent’s actions during the misuse window? Did the agent’s outputs become inputs to downstream systems-of-record (CRM, ERP, code, ticketing)? Tool-call ledger (Type B) for write actions; SaaS audit logs (Type F) for record-modification timestamps; the change-log discipline per Playbook 22 where applicable
Availability Was service disrupted by the containment response? Did the user’s access revocation cascade to other users via shared service accounts? The TTSM and containment-mode change history; downstream-service-impact records during the incident window
Trust Did the misuse produce externally-visible impact (incorrect customer record, leaked communication, external recipient affected)? What is the affected-stakeholder count and the identifiability of those stakeholders? The output distribution map per Playbook 09 Type F extension; the affected-customer count; the visibility classification (private to user, visible to user’s organization, visible externally); HR and Legal joint review of the trust-impact framing before any external communication

The Trust dimension is particularly relevant for insider-threat scenarios because the investigative posture (HR/Legal joint engagement, capability-intent-impact separation, soft-cap and hard-cap evidence) is itself communicated externally as evidence of the customer’s discipline. The CIA+T framing in the Executive Decision Packet is the artifact that translates the investigative discipline into the customer’s regulatory and board-facing posture. A response team that documents the triad without the CIA+T framing has the investigative substance but not the communication-ready artifact.

Recovery Sequence

Insider Threat 3.0 recovery follows MVO-4 Controlled Re-Enable with two insider-threat-specific gates added. Both gates respect HR and Legal participation that began at minute zero.

  1. HR/Legal sign-off on remediation scope (insider-threat gate). Before re-enabling the agent for the affected user pool, HR and Legal must concur on what changes (if any) to the user’s access, role, or status. Security cannot make this call alone. The sign-off is documented; the decision log lives in the case file.
  2. Re-enable the agent in Mode M1 Read-Only for the affected user pool. Reads continue with monitoring on every retrieval. Writes are blocked.
  3. Enable approval gates on bulk and export workflows. Per-corpus soft and hard caps activate before re-enabling Tier-2 actions. Soft caps trigger approval; hard caps block and alert.
  4. Validate the intent-realignment gate (insider-threat gate). The agent’s intent vector (system prompt, role definition, tool authorization rationale) is compared against current organizational intent. Drift between the two is itself a finding. Update the AI-BOM agent section to reflect current intent before proceeding.
  5. Replay the triggering prompt pattern in a sandbox. Confirm that the new soft cap, hard cap, or approval gate fires correctly. If it does not, the recovery is incomplete. Return to step 3.
  6. Re-enable Tier-2 tools incrementally, starting with the lowest-risk export channel. Monitor every Tier-2 call for the first 14 days post-incident. Lower the Playbook 11 detection threshold for this agent to mean + 2σ during the observation window.
  7. Resume normal operation with elevated monitoring. Return Playbook 11 detection thresholds to mean + 3σ only after 14 days of clean operation.
  8. Schedule the post-incident review with HR and Legal within 5 business days per Playbook 18. The review covers: what happened, what hardening shipped, what policy changes (if any) are required, and what the next quarterly review will measure.

Approver: CISO or designated Incident Commander, with HR and Legal sign-off documented. The agent owner alone is not sufficient. The user under investigation is not consulted on re-enablement.

Post-Incident Hardening

Insider Threat 3.0 hardening organizes around four boundaries. Each has an owner, an artifact, and a measurable acceptance criterion.

Boundary 1: Role-scoped retrieval

Boundary 2: Approval gates for bulk and export actions

Boundary 3: Intent documentation and drift detection

Common Pitfalls

These are the highest-frequency failure modes specific to Insider Threat 3.0. Each has been observed often enough to name as a pattern.

Pitfall Why it happens Consequence
Treating insider risk as access-control only DLP and UEBA were the legacy answers Misses the bulk-retrieval-via-authorized-access pattern. Insider Threat 3.0 fires no DLP rules.
Logging tool calls but not the requesting prompts The application’s logging schema was designed pre-agent Cannot prove intent. The “what was the user asking for?” question goes unanswered.
No approval gate on bulk reads Soft and hard caps are an operational discipline, not a default Misuse looks identical to normal work. The compounding scale advantage of AI insider misuse is fully realized.
HR and Legal not engaged at minute zero Security tradition: secure the perimeter first, brief HR later Investigation contaminated. HR remedies unavailable. Discoverability problems for any future action.
Conflating capability and intent The detection signal that fires says “the agent did X” The investigation reverts to “did the user mean it?” without evidence. HR cannot act on inference.
Suspending the user at minute zero Security reflex when a user is suspected Destroys evidence (the user cannot be observed). Creates wrongful-action exposure if the user is later cleared.
Trusting employees as the entire control “We hire good people” Trust is not a control. Approval gates are. AI-augmented misuse runs faster than trust-based oversight catches.
No intent documentation in the AI-BOM The agent was built; the intent was implicit When the agent drifts, there is no documented intent to compare against. Drift is invisible.
System prompt changes happen outside code review The system prompt is “configuration” to engineers, not “code” Untracked prompt changes produce silent drift. The agent on Tuesday is not the agent on Monday.
UEBA modeled on humans applied to agent-mediated actions Existing tools, existing models Anomalous prompts come from “normal” users; baselines look fine. The agent layer is invisible to UEBA configured for human behavior.

The Question to Carry Forward

If an insider used your AI agent to compile sensitive data today, could you rapidly and confidently prove who initiated the action, what was retrieved, and where the output went? If your AI agent’s behavior has drifted slightly over the last 90 days in ways that look like “better adaptation to user needs,” would your team recognize that as rogue agent drift, or would you celebrate it as the agent learning?

If either answer is uncertain, PB12 is the work plan. Engage HR and Legal as joint owners. Document one agent’s intent in the AI-BOM this week. Establish soft caps on one sensitive corpus this month. Run an Insider Threat 3.0 drill with HR and Legal participation this quarter. Compare the agent’s documented intent against its operational behavior next quarter, and treat the difference as a finding.

That is how insider threat moves from a 1.0 program (humans with credentials) through 2.0 (humans with anomalous behavior) to 3.0 (agents and humans together, with intent as the load-bearing investigative dimension). The framework’s capability/intent/impact triad is the discipline that holds across all three generations.

Source: AI IR Overlay newsletter, Issue #12, “Insider Threat 3.0: AI-Driven Misuse,” by Jacob Ideji. https://www.linkedin.com/in/jacobideji/