The superuser problem: why AI agents are 2026's “biggest insider threat”

Jan 21, 2026

Jan 21, 2026

Share

Summarize this article with AI

The primary security issue with AI agents is their access.

Wendi Whitmore, Palo Alto Networks' chief security intelligence officer, recently named AI agents the “biggest insider threat.” 

When organizations deploy AI agents, they grant permissions. The agent needs calendar access to schedule meetings, email access to draft responses, CRM access to update records. Each permission seems reasonable in isolation. Combined, they create a non-human actor with broader access than most employees will ever have.

Security researchers call this the superuser problem.

The scale of adoption

McKinsey's 2025 State of AI survey found 23% of organizations are scaling agentic AI systems, with another 39% experimenting. 

The big enterprise names are leading the way. Microsoft says organizations built more than 400,000 custom agents in Copilot Studio by early 2025. Salesforce runs Agentforce on its Atlas Reasoning Engine. ServiceNow offers thousands of prebuilt agents through its platform.

Plenty of vendors are adding "agent" on rebranded chatbots, but the real ones, systems that plan, reason, and execute multi-step tasks, are already running at scale. The hard part is adopting them without handing out superuser access to software that moves faster than your security team.

How superusers emerge

Traditional software stays in its lane. A calendar app handles calendar data, an email client handles email. 

AI agents work differently because their value comes from connecting contexts, synthesizing information across systems to take action on your behalf. An agent that can only access your calendar isn't much more useful than a calendar app. An agent that can access your calendar, email, documents, and financial systems can get work done.

The problem is that this cross-system access creates what security professionals call "chained permissions." The agent has access to everything System A can reach and everything System B can reach. When autonomous agents chain together access to sensitive applications and resources, they operate without security teams' knowledge or approval.

Cisco's 2025 State of AI Security Report found only 34% of enterprises have AI-specific security controls in place, and fewer than 40% run regular security testing on AI workflows.

In the 2010s, shadow IT ate up 30 to 40% of enterprise IT budgets in untracked resources. Organizations that didn't govern early spent years cleaning up the mess. Shadow AI follows the same pattern but moves faster, and these tools don't just store data. They act on it.

Cascading failures at machine speed

In December 2025, Galileo AI published research on compromised agents in networked environments. The team measured how quickly failures spread.

A single compromised agent poisoned 87% of downstream decision-making within four hours.

Four hours. That's faster than most incident response teams can even identify a breach, let alone contain it. The speed comes from the same capability that makes agents useful: they take action autonomously, without waiting for human approval.

Traditional security models assume human-speed threats. An attacker gains access, explores the environment, identifies targets, and exfiltrates data over days or weeks. Detection systems look for these patterns. But when the "attacker" is an autonomous agent with legitimate credentials operating at machine speed, detection patterns fail.

Memory poisoning deserves particular attention. Lakera AI's research showed how prompt injection via poisoned data sources can cause agents to develop persistent false beliefs and defend those beliefs as correct when questioned.

Vendor risk

Teams tend to integrate Copilot, deploy Agentforce, or embed ServiceNow agents rather than building from scratch. That means the vendor's security posture becomes yours.

Traditional SOC 2 audits were never created for AI vulnerabilities. The NIST COSAIS framework acknowledges that AI systems introduce risks distinct from traditional software, particularly around model integrity and training data security. Before deploying any platform, look at:

  • Model security: Prompt injection defenses, guardrails, and adversarial testing. BaxBench research found even the best models produce correct and secure code only 38% of the time.

  • Data handling: Where context persists, how long it's kept, and whether it feeds back into training.

  • Audit capabilities: Can you reconstruct decision chains? Are access logs detailed enough?

  • Fourth-party risk: Your vendor has vendors, so map the downstream dependencies.

Request SOC 2 Type II reports and penetration testing results. Vendors who won't share them are telling you something.

Least privilege, revisited

Traditional IAM doesn’t cope well with non-human actors that need permissions changing on the fly. Your IAM assumes predictable lifecycles, static roles, and manual oversight, but agents break all three assumptions.

Scoped access patterns

Row-level access control matters more for agents than humans. A support agent should access only the ticket it's working on. Delegated access lets the agent borrow the user's identity instead of having its own credentials. If the user loses access to a record, the agent loses it too. Token scoping gives each tool its own token. The Order tool gets order:read, the Promotions tool gets promotions:write, and each service sees only what it needs.

Time-bounded permissions

Short-lived credentials, typically JWTs valid for 15 to 60 minutes, force regular re-authentication. When tasks complete, access expires automatically. Just-in-time escalation means an agent needing write access to a financial system requests temporary elevation, completes its task, and returns to read-only. The system logs every elevation.

Tools and access models

Implementing scoped access and time-bounded permissions requires the right tooling.

  • SPIFFE gives agents cryptographically verifiable identities that expire within an hour

  • HashiCorp Vault Enterprise supports it natively

  • Aembit handles continuous identity verification for agents

  • Cerbos manages fine-grained authorization across agents and MCP servers

Agents need access rules that adapt to context because their requirements change with every task. Centralized policy engines handle this well. Write your policies as version-controlled code.

Human-in-the-loop as architecture

The deeper solution involves rethinking when agents can act autonomously and when they must wait for human approval.

Security researchers recommend mandatory human checkpoints for any action with financial, operational, or security impact. An agent should never transfer funds, delete data, or change access control policies without explicit human approval. The slight friction is worth the protection.

Implementation matters because confirmation dialogs users click through provide no real protection. Effective human-in-the-loop design surfaces the right information at the right moment: what action the agent wants to take, what data it will access, and what the consequences might be. Users need enough context to make real decisions rather than rubber-stamp automated requests.

Some organizations are experimenting with tiered autonomy:

  • Low-risk actions (scheduling meetings, drafting emails for review) proceed without interruption. 

  • Medium-risk actions (sending emails, updating records) require lightweight confirmation. 

  • High-risk actions (financial transactions, permission changes, data deletion) require explicit approval with full context. 

Autonomy creates an accountability problem. The more autonomously an agent acts, the fewer opportunities humans have to catch mistakes before they cascade.

A pragmatic security posture

You can't avoid agents, and you probably don't want to. PwC found 88% of executives plan to increase AI-related budgets in the next 12 months. Your competitors are already using them.

Organizations that get this right will build security into agent architecture now:

  1. Start with delegated access. Agents borrow user permissions and don’t accumulate their own, which caps the blast radius.

  2. Issue scoped, time-bounded tokens from day one. Narrow permissions for specific tasks that expire automatically.

  3. Push vendors on AI-specific controls. SOC 2 isn’t enough. Ask for prompt injection defenses, adversarial testing, and audit trails.

  4. Define tiered autonomy before production. Decide which actions need approval before agents start taking them.

  5. Write policies as code. Static roles cannot keep up with agents that need different permissions for every task.

The systems acting on your behalf should operate with boundaries you can verify. Get the architecture wrong and you've built an insider threat with API access.