Notifications
Clear all
Topic starter
22/06/2026 9:56 am
TL;DR: Enterprise AI assistants can be hijacked into high-impact 0click attacks through prompt injection, data leakage, misconfigurations, and unauthorized access, according to Zenity’s Black Hat USA 2025 briefing.
NHIMG editorial — here’s why we think this discussion matters
Questions worth separating out
Q: How should security teams govern AI assistants that can act on enterprise data?
A: Treat the assistant as a delegated executor, not a passive interface.
Q: Why do AI agents change the access model for IAM and PAM teams?
A: Because they can combine reading, reasoning, and acting inside one workflow.
Practitioner guidance
- Map agent tool permissions to task-specific scopes Inventory every mailbox, file, search, and API connector an assistant can reach, then restrict each one to the smallest task scope the business actually needs.
- Add runtime enforcement for agent actions Require policy checks at the moment the agent selects a tool or issues an action, not only when the agent is deployed.
- Separate read context from action authority Design assistants so they can summarise or search content without being able to convert that content into privileged execution.
What to expect at the briefing
Zenity's full article covers the operational detail this post intentionally leaves for the source:
- The live Black Hat demo mechanics behind Zenity Agent Defender and the attack scenarios it uses to show agent compromise.
- The step-by-step breakdown of the 0click exploit methods discussed in the featured talk, including how the attack chain unfolds.
- The GenAI Attack Matrix and how Zenity maps its detections and mitigations across build-time and runtime controls.
- The vendor comparison discussion that frames which mitigations actually stop the worst 0click vulnerabilities.
👉 Read Zenity's Black Hat briefing on AI enterprise compromise and 0click attacks →
AI agent compromise on Copilot and ChatGPT Enterprise: are controls enough?
Explore further
22/06/2026 10:37 am
Agent compromise is now an identity problem, not just an AI safety problem. Once assistants can read corporate content and trigger tools, the decisive control question becomes who or what is authorised to act, not whether the model output looks safe. That shifts governance from content review to runtime authorisation, because the breach surface is the delegated action path. Practitioners should stop treating AI assistants as passive interfaces and start treating them as governed executors.
A few things that frame the scale:
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to the same research.
A question worth separating out:
Q: How do organisations reduce the blast radius of AI agent compromise?
A: Start by separating content access from action authority, then narrow each connector to a specific business function. Add runtime policy checks, decision logging, and session-level constraints so the agent cannot freely chain tools across domains. The goal is to make every action attributable and interruptible before damage compounds.
👉 Read our full editorial: AI agent compromise on enterprise platforms demands runtime controls
