One finding from early-2026 security research deserves more attention than it got: organizations that hand AI agents broad access permissions see several times as many security incidents as those that hold agents to least privilege. The multiplier varies by study, but the direction is unambiguous and the reason is structural. Broad permissions are risky for any automated system - but agents are uniquely dangerous to over-permission, because unlike a cron job running a fixed script, an agent decides at runtime which resources to touch and which tools to call, based on input, context, and its own interpretation of fuzzy instructions.

Why traditional IAM falls short for agents

Identity and access management was built for two kinds of actor: humans, who are slow and accountable, and services, which are fast but deterministic. An agent is a third kind - fast and non-deterministic. A human with broad access is constrained by being one person doing one thing at a time. A service with broad access only ever does what its code says. An agent with broad access can be talked into doing something its designers never intended, at machine speed, because its "code" is a prompt and its behavior bends to the input it receives. Static, coarse-grained roles that were fine for services become a liability when the thing holding the role can be socially engineered.

The incident patterns that recur

• Prompt injection turned into action - malicious instructions hidden in data the agent reads (a document, a webpage, a ticket) redirect it to exfiltrate or delete, using the permissions it legitimately holds.
• Over-broad data reads - an agent granted "read the database" to do one narrow task can be steered to read everything, including data it never needed.
• Tool chaining - an agent with several tools combines them in unintended ways, turning a benign set of capabilities into a harmful sequence.
• Irreversible actions without a gate - write, delete, or deploy permissions exercised on a confidently wrong decision, with no approval step to catch it.

Least-privilege patterns that work

The fix is to treat each agent as its own identity with the narrowest possible grant:

• Scope to the task, not the system. An agent that summarizes orders gets read access to the orders table, not the database.
• Separate identities per agent. Don't share one over-powered service account across many agents; give each its own role and audit trail.
• Gate the irreversible. Reads can be autonomous; writes, deletes, and deploys require human or policy approval proportional to blast radius.
• Make everything observable and reversible. Log every action with the identity that took it, and prefer operations you can roll back.
• Time-bound and just-in-time access. Grant elevated permissions for the duration of a task, then revoke, rather than standing access.

The identity gap

Most of this comes back to one unsolved problem: agents don't fit cleanly into existing identity models. They're not users and not quite services, so they get shoehorned into whichever role is convenient - usually an over-broad one. Closing the gap means giving agents first-class, narrowly-scoped identities with their own lifecycle, the way you'd never let a new hire share the admin login.

Practical steps for data teams

Start by inventorying what your agents can actually access today - the answer is often "more than anyone intended." Then ratchet down: scope each agent's role to its real task, split shared accounts, add approval gates on anything destructive, and turn on per-agent logging. None of this requires new technology; it requires applying least privilege, which security teams already know, to a new kind of actor that punishes its absence far more harshly than the systems that came before.