Secure AI Agents, Everywhere: Why Prompt Injection Is Only Part of the Problem

The rules have changed. In every AI deployment, the agent itself is now part of the threat model, and that's a first for enterprise security. Prompt injection gets most of the attention, and for good reason: it doesn't require access to source code, credentials, or network infrastructure. It exploits the fundamental mechanism by which language models process instructions. But injection is only one way an AI agent goes wrong. Two others matter just as much, and most security programs aren't looking for them yet.

Common Agentic Threat Categories

Every enterprise environment is at risk for these threat categories: external, insider, and autonomous threats.

External: An adversary manipulates the agent. A malicious prompt hidden in a document, email, or webpage causes the agent to execute the attacker's intent using the victim's own access and permissions. This is prompt injection, and it comes in two forms:

• Direct prompt injection: A user submits input designed to override system instructions, for example, typing "ignore all previous instructions" into a customer-facing assistant.
• Indirect prompt injection: An agent retrieves external content, such as a webpage, email, document, or database record, containing hidden instructions. The model treats the content as data but executes the instructions buried inside it. Because the attack surface is every piece of external content an agent touches, this is generally the higher-risk form, and it doesn't require the attacker to interact with the application at all.

Insider: Someone hands the agent what it shouldn't have. An over-shared file, a broadened permission, a data source nobody questioned. No adversary, no injection, just an ordinary interaction that exposes something it shouldn't have.

Autonomous: The agent acts on its own reasoning, with no manipulation and no instruction gone wrong. It hits a problem mid-task, improvises, finds a credential it was never given, and acts on it. This category is the one that breaks the "we filtered for prompt injection, we're covered" assumption, because there's no injection to filter. In one widely cited incident, a coding agent debugging a staging mismatch autonomously located API tokens and deleted a full production database and volume, despite being explicitly told not to. Zero manipulation involved.

External, insider, or autonomous: every one of these threats becomes real at the decision an agent makes. That's the one place all three become visible, and stoppable.

Why the Existing Security Stack Can't See Any of This

Enterprise security tooling, including DSPM, IAM, EDR, and network controls, were built for a world where the actor is human. Each of these categories is currently staking a claim on this problem: DSPM says it's a data problem, IAM says it's an identity problem, EDR says it's an endpoint problem, and network says it's a shadow-access problem. None of them are enough, on their own, because none of them can see the decision an agent makes.

AI systems are also non-deterministic. The same input can produce different outputs across sessions, and an agent's tool-call sequence depends on a reasoning process shaped by everything in its context window, including content it retrieved itself. No static rule set can characterize what an agent should or shouldn't do across the full range of inputs it might encounter. What's required is a security layer built for the agent layer itself: one that understands agent sessions, inspects inputs and outputs in context, and enforces behavioral policy based on what an agent is actually doing.

Context Tells You What Happened. Intent Tells You Why.

The same technically-authorized action can be completely benign or completely malicious depending on context. An identity provider can confirm a credential is valid and correctly scoped, but it has no way to judge whether using it, right now, in this session, makes sense. That's the gap Zenity is built to close: identity and other systems tell you what's authorized; Zenity evaluates whether an authorized action is appropriate right now, given the full context of the session.

That evaluation runs across seven dimensions on every agent decision: intent (the goal, why), action (what's being done), data involved, identity (who, on behalf of whom), model (what's being reasoned through), execution plan (the chain of steps), and environment (the blast radius if it's wrong).

The Zenity Approach: Surface, Enforce, Protect

Zenity secures agents across three pillars, spanning the full agent lifecycle rather than a single point of inspection:

Surface: Know every agent, action, and risk, continuously. Before you can secure agents, you need an inventory of what exists: every agent, every connected tool, every data source it can reach, and the exposure paths between them. You can't enforce a policy on an agent you don't know is running.

Enforce: Define what agents are allowed to do, and stop everything else, in real time. This includes inspecting inputs before they reach the model, both direct user input and indirect content agents retrieve from the web, email, documents, and tool outputs, and evaluating every tool call an agent makes against its defined permission scope. On platforms with inline enforcement, including Microsoft Copilot, and Foundry, consequential, irreversible actions (data deletion, external exfiltration, unauthorized API calls) require explicit policy authorization before they're allowed to run. On platforms where the underlying model provider doesn't yet expose an inline control point, Zenity detects and alerts on the same violations in near-real-time, closing the gap as platform support expands.

Today this runs as deterministic policy evaluation: allow, modify, or block based on defined rules. Deeper, context-aware steering that adapts to what an agent is trying to accomplish is an active area of ongoing development.

Protect: Detect, investigate, and close the loop back into prevention. Inline detection alone isn't sufficient for sophisticated, multi-step attacks; some patterns only become visible when you read the full session transcript, not a single input or output in isolation. Zenity synthesizes findings across a session into a complete incident and feeds structured alerts into existing SIEM/SOAR workflows. Each incident becomes a candidate policy update: a proposed boundary that hardens the environment against the same pattern next time, with the goal of a fully closed loop from detection back into prevention.

Every AI agent interaction is captured in an audit log, so teams can replay any session and see exactly what an agent did and why.

What Security Teams Get With Zenity

• Complete visibility into every agent session, input, tool call, and output, inspectable and replayable after the fact.
• Policy-based enforcement: security teams define what agents can access, call, and produce; Zenity enforces it at runtime without changes to the AI application itself.
• Incident response integration with existing SIEM/SOAR tooling, so AI security events flow through the same workflows as everything else.
• Audit-ready logging suitable for compliance reporting and forensic investigation.

Getting Started

Request a demo to see how Zenity surfaces, enforces, and protects against real prompt injection, insider exposure, and autonomous-agent risk in your own environment.