The classic insider threat profile: an employee with valid credentials, a trusted role, and access to production systems. They don't need to break in. They're already inside. The attack surface is their judgment, their incentives, their state of mind.
Now describe an AI agent: valid credentials, trusted process, access to production systems. Doesn't need to break in. Already inside. The attack surface is its training, its context window, its instructions.
The profiles are structurally identical. Most security teams are thinking about AI agents as external attack vectors — prompt injection, adversarial inputs, model jailbreaks. That's real but it's the wrong frame. The deeper problem is that your agents are, functionally, insider threats by design.
Why This Frame Matters
Insider threat programs work differently from perimeter defenses. They focus on:
- Behavioral analytics — what's normal, what's anomalous
- Least privilege over time — access shrinks after peak need
- Activity logging with business context — not just what happened, but why
- Psychological and situational triggers — what conditions lead to bad actions
- Offboarding and access revocation — when someone leaves, their access leaves
Every one of those applies directly to AI agents. None of them are in the standard AI security checklist, which tends to focus on input validation, output filtering, and sandboxing. Those are necessary. They're not sufficient.
The Three Insider Threat Patterns Agents Exhibit
1. The Negligent Insider
The most common insider threat isn't malicious — it's careless. An employee with too much access, moving too fast, making mistakes that cause damage they didn't intend.
Agents exhibit this constantly. Over-broad credentials. Commands that affect more systems than intended. Cleanup operations that delete the wrong things because the scope wasn't explicitly constrained. The agent isn't trying to cause harm — it's optimizing for task completion with insufficient guardrails.
The negligent insider problem in agents is a permission architecture problem. If an agent can delete anything, eventually it will delete something you didn't want deleted. Not because it's broken. Because you gave it the keys.
2. The Compromised Insider
An employee whose credentials are stolen becomes a vector for an external attacker. The damage comes from legitimacy — the attacker is using valid creds, valid processes, valid access patterns. Detection is hard because everything looks normal.
Agents are compromised through prompt injection. An attacker embeds instructions in content the agent processes — a document, a web page, a database record, an email. The agent executes those instructions with its full set of permissions. From the outside, it looks like normal agent activity: legitimate credentials, expected process, real systems.
The compromised insider defense is the same for humans and agents: behavioral analytics that flag deviations from baseline, and approval gates that introduce friction for unusual actions. If the agent normally reads files and suddenly wants to exfiltrate data to an external endpoint, that should require a human to sign off — regardless of what the agent was "asked" to do.
3. The Malicious Insider
This is the edge case, but it's worth thinking through. An agent trained or fine-tuned with adversarial goals. An agent whose instructions were tampered with during deployment. An agent operating under a compromised system prompt.
The malicious insider analog in agents isn't the agent going rogue on its own — it's someone in the supply chain poisoning the agent's objective. And unlike a human malicious insider, the agent will execute perfectly and at scale, without hesitation, at any hour.
This is why human-in-the-loop for high-impact actions isn't just about catching mistakes. It's a structural check against the scenario where the agent's goals aren't what you think they are.
What Insider Threat Programs Do That AI Security Programs Don't
| Insider Threat Control | Human Employee | AI Agent (typical) |
|---|---|---|
| Behavioral baseline | UEBA tools, login analytics | Rarely implemented |
| Access reviews | Quarterly IAM reviews | Almost never |
| Offboarding / deprovisioning | HR-triggered access removal | No equivalent process |
| Activity logging with context | SIEM with business context | Often raw command logs only |
| Separation of duties | Four-eyes for sensitive ops | Agent approves its own actions |
| Triggered escalation | Manager alerts on anomalous access | Rarely configured |
The gap is stark. The same controls your organization applies to employees with production access are not applied to AI agents with equivalent or greater access.
Applying Insider Threat Controls to AI Agents
Behavioral Baseline and Anomaly Detection
What does this agent normally do? Which systems does it touch, which command types does it run, what volume of operations does it execute per session? Build that baseline and alert — or halt — when the agent deviates significantly.
This is harder for agents than humans because their activity can be more variable. But the principle is the same: unusual behavior is a signal, and the signal should trigger friction. The agent that suddenly wants to access a database table it's never touched before should have to explain itself — or route through human approval.
Time-Bounded Access
Employees get access for a role, and that access gets reviewed. Agents often get access once and keep it indefinitely. Credentials don't expire. Permissions don't shrink after the peak task. The agent that needed prod access for a migration three months ago still has it today.
Implement TTLs on agent credentials. Require re-authorization for sensitive operations after a period of inactivity. Treat agent access like a contractor badge, not a permanent employee card.
Separation of Duties
Agents shouldn't approve their own high-impact actions. This sounds obvious, but most agentic systems don't have this boundary. The agent decides to delete files, the agent executes the deletion, the agent logs the deletion. There's no second set of eyes.
For sensitive operations — data deletion, external communications, access grants, schema changes — require a human approval step. This mirrors the four-eyes principle used for privileged human access.
Deprovisioning Agents
When a project ends, when an agent is retrained, when a use case changes — agent credentials should be revoked just as employee access is revoked during offboarding. There should be a process for this. In most organizations, there isn't.
Maintain a registry of active agents, their credential sets, and their purpose. Review it quarterly. Revoke access for agents that are no longer active or whose scope has changed.
Immutable Audit Logs with Context
What the agent did is not enough. You need to know why it did it — what goal it was pursuing, what instructions it was acting on, what context it had at the time. This is what makes an audit trail useful for insider threat investigation rather than just a list of events.
Store the agent's stated intent alongside its actions. If it ran a database query, log the task it was executing, the session context, and the approval state. You want to be able to reconstruct the agent's decision-making, not just its outputs.
The Conversation Your Security Team Needs to Have
Most security teams categorize AI agents under one of two existing buckets: external attack surface (prompt injection, model attacks) or third-party risk (vendor AI, data egress). Neither bucket triggers the controls that actually matter for agent risk.
The right bucket is privileged insider. When you start asking "what would we do if this were an employee with this level of access?", the right controls become obvious. And so does the gap between what you have and what you need.
AI agents aren't going to go rogue in the Hollywood sense. But they will make mistakes at scale, execute compromised instructions without hesitation, and retain access they shouldn't have. That's the insider threat profile. Build the controls accordingly.
How Expacti Helps
Expacti applies insider threat controls to AI agent shell access:
- Command interception — every action goes through a review gate before execution
- Behavioral anomaly detection — 8 detection rules flag unusual patterns and route to human review
- Immutable audit log — every command with session context, approval chain, and stated intent
- Risk scoring — 14 categories, 25 modifiers, surfaces high-risk commands for mandatory review
- Session-scoped access — tokens can be scoped and revoked per session, not just per agent
- Multi-party approval — require two reviewers for destructive or sensitive operations
The result is a system that treats AI agent shell access the way mature organizations treat privileged human access: not with blind trust, but with structured oversight.