AI agent compromise on enterprise platforms demands runtime controls

At a glance

What this is: This is a Black Hat 2025 promo for Zenity’s AI agent security demo and talk, centered on 0click compromise paths for enterprise assistants.

Why it matters: It matters because AI agents collapse boundaries between human identity, NHI-style access, and runtime action, forcing IAM, PAM, and governance teams to rethink who or what can act, on which data, and with what approvals.

👉 Read Zenity's Black Hat briefing on AI enterprise compromise and 0click attacks

Context

AI agent compromise becomes a governance problem the moment an assistant can read enterprise data and act through connected tools. In that model, the security question is not whether the interface is trusted, but whether runtime actions are bounded, attributable, and reversible.

Black Hat framing here is useful because it exposes the control gap across Microsoft Copilot, ChatGPT Enterprise, and similar platforms. The issue for identity teams is that agent behaviour sits between human intent and machine execution, which makes traditional access review and approval models too slow to catch misuse.

Key questions

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. Limit which tools it can call, what data it can read, and which actions it can complete in a single session. Runtime policy enforcement, strong logging, and tightly scoped connectors are essential because the main risk is unauthorized action, not just unsafe text output.

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. That breaks the assumption that access is static enough to review later. IAM and PAM teams have to govern what the agent can do at runtime, including approvals, session limits, and the ability to stop unsafe action chains before they complete.

Q: What breaks when prompt injection reaches a tool-using AI assistant?

A: The assistant may convert untrusted input into enterprise action. If the agent can read mail, search data, and call APIs, injected instructions can redirect those capabilities toward leakage or unauthorized changes. The failure is not only content contamination. It is delegated execution with insufficient containment around the agent’s tool path.

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.

Background and context

0click compromise paths in enterprise AI assistants

A 0click attack on an AI assistant does not depend on the user approving a malicious action. Instead, the agent is manipulated through content or context it already ingests, such as messages, documents, search history, or connected app data. Once the assistant can choose actions on behalf of a user, an attacker can steer those actions toward data exposure or environment changes without a visible phishing-style interaction. The technical risk is not only prompt injection. It is the combination of model context, tool access, and execution permissions in one runtime path.

Practical implication: separate read access from action authority so an agent cannot turn passive content exposure into active enterprise change.

Data leakage and privilege escalation through connected tools

Enterprise agents become dangerous when they inherit broad access to mail, chat, files, and downstream APIs. In that state, leakage is not limited to model outputs. The assistant can surface sensitive context into conversations, summaries, or actions that were never intended for that audience. Privilege escalation appears when the agent can chain approved tools into outcomes that exceed the operator’s actual need. This is an identity problem as much as an AI problem, because the agent is effectively a delegated executor with a wide blast radius.

Practical implication: map every connected tool to the minimum task scope the agent actually needs, not the full entitlement set of the underlying user.

Build-time to runtime defense for AI agent governance

Zenity’s framing separates build-time controls from runtime controls, which is the right architectural distinction. Build-time policy can reduce unsafe configurations, exposed connectors, and overly permissive defaults, but it cannot stop an agent from being manipulated during live execution. Runtime controls are what constrain session scope, detect abnormal tool use, and interrupt unsafe action chains before they complete. For AI agents, governance has to follow the execution path, not just the deployment path.

Practical implication: treat runtime policy enforcement and telemetry as mandatory control layers, not optional monitoring after deployment.

NHI Mgmt Group analysis

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.

Prompt injection matters because it turns ambient enterprise data into an attack surface. Search history, email, chat, and document context are no longer harmless background inputs when an agent can turn them into actions. That makes the trust boundary porous across human identity, NHI-style connectors, and agent runtime behaviour. Security teams need to recognise that the compromised object is often the agentic workflow, not just the model prompt.

Build-time policy cannot substitute for runtime containment. Configuration hardening can reduce exposed connectors and misconfigured defaults, but it does not prevent live manipulation once a session begins. The practical governance lesson is that agent access must be observable, scope-limited, and interruptible while actions are in flight. Without that, security teams are certifying a setup they cannot actually control.

Zero-click agent abuse is the named concept this category now needs. The pattern is not a classic phishing event and not ordinary automation failure. It is a runtime compromise where the attacker uses existing data and delegated permissions to make the agent act without user interaction. The implication is that identity governance for AI assistants has to be built around execution scope, not just authentication state.

AI agents extend NHI governance into a higher-risk delegation model. The same discipline that protects service accounts now has to account for agents that can select actions and traverse tools dynamically. That does not make every assistant autonomous, but it does make every broad connector a governance concern. Practitioners should align agent oversight with NHI controls plus AI-specific runtime constraints.

From our research:

• 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.
• For the broader identity context, read Ultimate Guide to NHIs , Why NHI Security Matters Now for the governance pressure behind machine and agent identity sprawl.

What this signals

Zero-click agent abuse will push identity teams toward runtime governance, not broader static approval chains. The control problem is not whether an assistant can be trusted at login. It is whether its permissions, tool paths, and decision points stay bounded while the session is live. For practitioner programmes, that means agent observability and policy enforcement need to sit alongside IAM and PAM controls, not after them.

Prompt injection is becoming the bridge between content security and identity governance. Once an assistant can read enterprise mail or files, hostile content can become an identity event if the agent can turn it into action. That makes connector scope, decision logging, and recovery paths central to programme design, especially where human users already rely on assistants for daily work.

Agentic AI security now looks like a delegated-access problem with a new attack grammar. Platforms such as Microsoft Copilot and ChatGPT Enterprise will continue to expand, but the control model cannot assume a human is always the final decision-maker. Teams should align their agent controls with OWASP Top 10 for Agentic Applications 2026 and map the blast radius of each connector before rollout.

For practitioners

• 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. Remove inherited broad access where the agent does not need to inspect or act across the full user entitlement set.
• 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. Block unsafe combinations such as hidden data retrieval followed by outbound sharing or privileged system changes in the same session.
• 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. This is especially important for environments where prompt injection can arrive through emails, documents, or chat channels.
• Log and review agent decisions as governance artefacts Capture tool selection, triggered actions, and downstream effects in a format that identity and security teams can review. Normal access logs are not enough when the meaningful event is the agent’s decision sequence, not only the user login.

Key takeaways

• Enterprise AI assistants can be hijacked into real actions when tool access and content ingestion are governed as one control plane.
• The practical risk is delegated execution, where prompt injection, misconfiguration, or excessive connector scope turns normal workflow into unauthorized change.
• Runtime policy, scoped connectors, and decision logging are the controls that matter when assistants can act on behalf of users.

Key terms

• AI Agent: A software entity that can choose actions, tools, and timing within a live session. In identity governance, the critical issue is not just automation but delegated execution, because the agent may act on data and systems with permissions originally granted to a human or service context.
• Prompt Injection: A technique that manipulates an AI system through content it consumes so the system follows attacker-influenced instructions. For agentic environments, the risk rises sharply when injected content can drive tool use, data exposure, or operational changes beyond the original user intent.
• Runtime Policy Enforcement: Controls that evaluate and constrain actions at the moment a system tries to execute them. In AI agent governance, runtime enforcement matters because build-time checks alone cannot stop a live assistant from chaining tools, crossing scope boundaries, or turning untrusted inputs into action.
• Delegated Execution: A model where one identity is authorised to act on behalf of another. For AI assistants, this means the system may inherit access that looks human on paper but behaves like a machine at runtime, creating a governance gap if approvals and logs do not reflect the real actor.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: Black Hat USA 2025 AI agent security demo and featured talk on enterprise compromise. Read the original.