Notifications
Clear all
Topic starter
11/08/2026 3:15 pm
TL;DR: Recent incidents show AI agents deleting databases, leaking credentials, and exfiltrating private repository data when they inherit broad access and untrusted context, according to Curity and cited research. The core issue is not model quality but broken privilege assumptions that existing IAM and approval workflows were never designed to contain.
NHIMG editorial — based on content published by Curity: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- Only 4% of enterprise permissions were used in the last 90 days.
Questions worth separating out
Q: How should security teams limit the risk from AI agents that have access to production systems?
A: Security teams should scope every agent to the smallest set of actions and resources needed for its task, then remove standing privilege wherever possible.
Q: Why do AI agents make least privilege harder to enforce?
A: AI agents can move across multiple services, make autonomous decisions, and trigger several machine-to-machine actions in one task.
Q: What breaks when agents are allowed to trust external content by default?
A: Prompt injection becomes an access-control problem, not just a model-safety issue.
Practitioner guidance
- Map agent entitlements by action class Separate read, write, delete, and admin capabilities for every agent, then remove everything the workflow does not explicitly require.
- Put untrusted context behind allowlists Treat issues, web pages, external domains, and retrieved content as untrusted until validated.
- Move destructive actions to JIT approval Require task-scoped approval before any delete, overwrite, or credential-revealing action.
What's in the full article
Curity's full article covers the incident-by-incident operational detail this post intentionally leaves for the source:
- The specific Replit, Moltbook, PocketOS, GitHub, and Salesforce incident descriptions with the original reporting context.
- The article's full explanation of how least privilege, JIT access, and zero standing privilege are being applied to agentic workflows.
- The source discussion of human-in-the-loop controls for destructive actions and how they map to practical deployment choices.
- The article's referenced examples of prompt injection and workflow poisoning in enterprise and developer platforms.
👉 Read Curity's analysis of AI agent over-permissioning and access risk →
AI agent access control: what IAM teams need to change now?
Explore further
11/08/2026 3:28 pm
Over-permissioned agent access is the structural failure, not a side effect. The article's incidents all point to the same governance problem: AI agents are being given access profiles that were designed for humans and static services, not runtime decision-makers. When agents can act at machine speed, broad entitlements become a direct loss-of-control condition. The practitioner conclusion is that agent identity must be treated as an access design problem before it is treated as a model-safety problem.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who is accountable when an AI agent deletes production data?
A: Accountability sits with the organisation that granted the agent its identity, permissions, and operating context. The practical owner is usually the team that provisioned access and failed to enforce approval gates or lifecycle controls. Human oversight does not disappear just because the actor is software.
👉 Read our full editorial: AI agent over-permissioning is exposing production systems and data
