Insider risk programs are built around human access patterns: what someone can reach, how much they can take, how fast, and whether anyone notices. Agents change all four variables, and most insider risk programs have not been updated for them.

This is not primarily about malicious insiders, who are rare. It is about the much larger category of people who are careless, who take shortcuts under deadline pressure, or whose accounts are compromised — and the fact that agents make each of those situations considerably more expensive.

What Agents Change

Scale. A person exfiltrating records manually is limited by what they can query, download, and move. An agent with a read connection and a task can extract at machine speed, in volume, formatted for use. What used to take weeks of careful accumulation is now one prompt and a few minutes.

Speed. Detection windows shrink. A pattern that would have been caught by a weekly review of unusual access happens between two reviews.

Attribution decay. If your logs record "agent-7 read 40,000 records," they do not tell you which human directed it. Actions get attributed to a service identity, and the human disappears from the record. This is the single most consequential change, and it is a logging decision rather than a technical inevitability.

Plausible deniability. "The agent must have decided to do that" is a defence that did not previously exist. Agents are non-deterministic and sometimes do surprising things, which means a genuine ambiguity now exists that an insider can hide behind — unless the record establishes who asked.

A new privileged surface. Agent configuration — prompts, tool scopes, connection permissions, guardrail rules, budget ceilings — is now security-relevant configuration. Whoever can edit it can change what the agent does for everyone who uses it. In most organizations this surface has far weaker change controls than production code, often no review at all, because it is treated as application configuration rather than as policy.

The Configuration Surface Deserves Real Controls

This is where the sharpest gap usually is. Consider what a person with agent configuration access can do:

  • Widen a connection's scope so an agent can read data it previously could not.
  • Edit a system prompt to change what the agent will do or what it will disclose.
  • Disable or weaken a guardrail so PII stops being redacted.
  • Raise a spend ceiling.
  • Add a connection to a new destination, creating an egress path.
  • Register an MCP server that receives everything the agent sends it.

Each of these is a privilege escalation performed through configuration, and each affects every subsequent use of that agent by anyone. Meanwhile the same organization requires two approvals to merge a code change that touches an authorization check.

The fix is to treat agent configuration as privileged change:

Separate duty between building and granting. The people who build agents should not be the people who approve their permissions. This is the single most important control here, and it mirrors how database and cloud permission grants are already handled in mature organizations.

Maker-checker on sensitive changes. Scope widening, guardrail weakening, new connections, and budget increases require a second person's approval. Narrowing and disabling can proceed without it — the asymmetry keeps friction proportional to risk. See maker-checker for platform administration.

Versioned configuration with a full change record. Who changed what, when, from what to what, with what justification. Reviewable and revertible. See versioning and rollback for AI agents and policy as code and guardrail versioning.

Guardrails and audit settings as a distinct privilege tier. The ability to disable a control or reduce audit retention should be held by a different, smaller group than the ability to configure an agent's behavior. An operator who can silently turn off logging can do anything else without evidence.

Dual Attribution Is the Core Requirement

Every agent action needs two identities in the record: the agent that performed it and the principal it acted for.

That principal must come from the authenticated session, not from something the caller supplies. A tenant or user identifier passed as a parameter is forgeable, and an insider is precisely the person who knows it is forgeable.

With dual attribution, an insider using an agent to bulk-extract data produces a record naming them. Without it, they produce a record naming the agent, and the investigation stalls. This is the same requirement that post-incident forensics depends on, arriving from a different direction.

Two adjacent requirements:

Autonomous actions need a distinguishable identity. Scheduled and system-triggered work has no human principal, and it should be recorded as such rather than defaulting to a service identity that also appears on human-directed work. Conflating them creates exactly the ambiguity an insider needs.

The delegation chain must be preserved. In multi-agent systems, the originating principal must survive every hop. An orchestrator that drops the principal when dispatching to a sub-agent breaks attribution at the first hop. See token exchange for agent-to-tool authorization.

Volume Ceilings on Read Paths

Traditional insider controls focus on write and delete authority. Agent-era insider risk is mostly about reads, because the amplification is on the read side and every individual read is permitted.

An agent with a legitimate read connection performing 40,000 reads is not violating any permission. It is exfiltrating. The control is a ceiling, not a permission:

  • Per-call result size caps.
  • Per-task cumulative volume caps.
  • Rate limits on read operations, distinct from write.
  • Alerts on volume deviation from the agent's baseline — agents are far more predictable than humans, which makes baselining effective.

Where the data is sensitive, cap by default and treat higher-volume access as a separate, gated operation. A support agent that reads one customer record per task should be capped at a handful, not permitted to read the table. See how to implement least privilege for agents and data exfiltration risks in agentic AI.

Detection Signals Worth Building

  • Volume anomalies per principal per agent. Not just per agent — a single human directing unusual volume through an otherwise-normal agent is the signal you want.
  • Access outside a principal's normal pattern. A support representative's tasks suddenly touching finance data through a shared agent.
  • Configuration changes that widen authority, especially outside business hours or by someone who does not usually make them.
  • Guardrail disablement or retention reduction. These should page.
  • Repeated near-misses. Blocked attempts clustered by principal indicate probing, whether by an insider or by someone using their account.
  • Off-hours agent invocation by a human principal where the agent is normally used interactively during working hours.
  • New destinations on existing connections, and new connections to external endpoints.

The account-compromise case is worth calling out: from the system's perspective a compromised employee account and a malicious insider are indistinguishable, so the same controls cover both. That is a good argument for building them even in organizations confident about their people.

Common questions

Is this not just standard insider risk management with agents added?

The principles carry over — least privilege, separation of duty, monitoring, attribution. What changes is where the controls have to sit and what they measure. Volume ceilings on read paths matter more than write permissions. Configuration change control matters as much as code change control. And attribution requires deliberate design because the default logging attributes to a service identity. Programs that simply extend existing DLP and access review to cover "AI tools" tend to miss all three.

How do I handle agents shared across many users?

Shared agents are efficient and they are the case where attribution matters most, because the agent's identity is not informative on its own. Requirements: the principal is established from the authenticated session, the agent's data access is scoped to what that principal may see rather than to the agent's own ceiling, and volume limits apply per principal rather than per agent. Without per-principal scoping, a shared agent becomes a permission-aggregation point that lets any user reach any other user's data — which is the confused deputy problem with an insider driving.

What about developers who need broad access to build and debug agents?

Give them broad access in a non-production environment with synthetic data, and narrow access in production. Where production access is genuinely needed for debugging, make it time-bounded, justified, approved, and heavily recorded — a break-glass path rather than standing authority. See break-glass and emergency access.

Does monitoring employees' agent usage raise privacy concerns?

Yes, and they should be addressed directly rather than avoided. What is being monitored is access to organizational data through organizational systems, which is generally well-established ground, but jurisdictions differ and works councils in some countries have specific requirements. Be explicit in policy about what is recorded, scope monitoring to the data access rather than to the content of an employee's prompts where possible, and restrict who can read the records. Monitoring that is disclosed and bounded is usually straightforward; monitoring discovered later is not.

How Praesidia approaches insider-side risk

Praesidia records both identities on every governed action — the acting agent and the asserted principal, taken from the authenticated session rather than from request content — so agent-mediated access is attributable to the human who directed it. Connections carry enumerated scopes and volume-relevant limits, and access is scoped to the principal being served rather than to the agent's own ceiling.

Configuration itself is governed: role and permission separation distinguishes building an agent from granting its authority, sensitive administrative changes can require a second approver, and changes are versioned with a full record. Guardrail and audit configuration sit in a distinct privilege tier, and every change is written to the tamper-evident audit trail. See RBAC and custom roles for AI operations and the Praesidia documentation.