AI Agent Security: Shipping Agents Without the Breach

01 · The threat model

Agents are privileged users that read the internet

Traditional applications execute predictable routines. An AI agent with tool access decides for itself how to reach its goal — reading documents, calling APIs, querying databases, sending messages. That makes it a privileged user whose instructions can come from anywhere it reads. Every document retrieved, every webpage fetched, every tool output parsed is a potential instruction channel.

The industry has now catalogued this extensively. OWASP's Top 10 for LLM Applications ranks prompt injection (LLM01) and sensitive information disclosure (LLM02) as the two primary vulnerability classes. Real incidents keep arriving: indirect prompt injection through connected business data, agents exfiltrating through authorized tools, supply-chain compromises in agent frameworks. The pattern is consistent — the agent's capabilities (tools, data access, outbound channels) become the attacker's capabilities the moment untrusted content is treated as instructions.

And yet only about a third of organizations have deployed dedicated prompt-injection defenses. Most enterprise agent deployments are running with the attack surface of a privileged insider and the security posture of a chatbot. This article is the checklist that closes that gap.

02 · Injection

Prompt injection: the attack you must design for

Direct injection is the user typing "ignore your instructions and…" — important, but the easier case to defend. Indirect injection is the real enterprise threat: malicious instructions hidden in a document the agent retrieves, a webpage it reads, an email it processes, or a tool output it parses. The agent can't distinguish "content to summarize" from "instructions to follow" — that's the fundamental vulnerability, and no system prompt fully fixes it.

Defense layers, in order of effectiveness:

1. Instruction hierarchy and content boundaries. Architect the agent so untrusted content is always marked as data, never as instructions. This is a design property of your prompts and tool schemas, not a filter you bolt on. Tool outputs should arrive in clearly delimited channels that the agent's instruction-following treats as observations.

2. Approval gates on consequential actions. The highest-leverage control in the entire checklist: no external send, no data modification, no privilege-adjacent action without an approval — human or policy-based. An agent that can read anything but can only act through gates has a dramatically smaller blast radius. The OWASP agent guidance is explicit here: missing approval gates are the recurring root cause.

3. Input/output inspection. Runtime guardrails that scan agent inputs for injection patterns and outputs for sensitive data. Tools exist for this (gateway-level guardrails, DLP filters), but treat them as one layer — determined attackers bypass pattern matching. They catch the opportunistic, not the sophisticated.

4. Red-teaming before production. Adversarial testing with the actual agent, actual tools, actual data: injection via documents and tool outputs, privilege escalation through tool chaining, exfiltration paths through authorized outbound tools, resource-exhaustion loops. Automate what you can (adversarial prompt frameworks), but include human red-teamers for the creative attacks. Every finding gets tracked and re-tested like a security finding.

03 · Identity

Least privilege for non-human workers

Every agent gets its own identity. Not a shared service account — a dedicated identity with scoped permissions, so every action is attributable and revocation is clean. This is the single most impactful governance decision, and it's almost free to implement at design time and painful to retrofit.

Scope tools, not just data. An agent that only needs to read customer records should not have write access to them. An agent that queries the warehouse should not be able to drop tables. Define the tool allowlist per agent: which tools, which operations, which data scopes. Then keep trimming — permissions accrete over time as "temporary" grants become permanent.

Separate read paths from action paths. Many agents need broad read access (to answer questions) but narrow action rights (to change things). Architect these as separate permission sets with separate approval policies. Broad reading with gated writing is the safe default.

Credential hygiene. Agent identities get short-lived credentials, automatic rotation, and no standing access to production secrets. The agent that needs a database password should get it from a secrets manager at runtime, scoped and expiring — never embedded in a prompt or a config file that gets copied into a demo.

04 · Leakage

Data leakage: the inside-out threat

Injection is outside-in. Leakage is inside-out: the agent, operating legitimately, exposes sensitive data — to the wrong user, through the wrong channel, or into the wrong system. The vectors: RAG retrieval surfacing restricted documents to unauthorized users, agent outputs containing PII pasted into external tools, training/fine-tuning data memorized and reproduced, and employees pasting confidential data into the agent's context.

The controls: access-aware retrieval (permissions enforced at retrieval time, per user — not post-filtered), output DLP (scan agent responses for PII, secrets, and classified patterns before delivery), data classification (the agent can't protect what hasn't been labeled), and channel controls (which external systems the agent may send data to, with what approval). Shadow AI — employees using unsanctioned tools — is the parallel battle: nearly a third of enterprise employees have entered confidential data into public AI tools. Your agent strategy and your shadow-AI policy are the same problem.

05 · Operations

Monitoring, audit, and the kill switch

Log everything. Every agent action — tool calls, data accessed, decisions made — with the agent's identity attached. This is your audit trail for incidents and your evidence for compliance. If you can't reconstruct what an agent did last Tuesday, you're not operating it; you're hosting it.

Baseline and alert. Normal agent behavior has a shape: typical tools, typical data volumes, typical hours. Alert on deviations — activity spikes, out-of-scope access attempts, unusual data exfiltration patterns. Agents don't get tired or bored; anomalous behavior is signal, not noise.

Human oversight tiers. Not every agent action needs a human in the loop — that would defeat the purpose. Tier it: autonomous for low-risk reads, policy-gated for standard actions, human-approved for high-stakes actions (external sends, financial transactions, data deletion). Define the tiers before deployment, not after the first incident.

The kill switch. Every agent needs an immediate, tested shutdown path — revoke the identity, suspend the tools, freeze the actions. "We'll just turn it off" is not a plan until you've tested that turning it off actually stops in-flight tool chains. Test it in staging. Then test it again after every architecture change.

06 · Supply chain

Your agent is only as secure as its supply chain

Agents are assembled from frameworks, plugins, model providers, and tool integrations — each a trust decision. The supply-chain incidents are already here: trojanized agent framework packages, malicious model-context-protocol servers, compromised dependencies exfiltrating credentials. An agent that loads a poisoned tool or plugin inherits the attacker's code with the agent's permissions.

The controls are unglamorous: pin and hash dependencies, vet every tool and MCP server like you'd vet a vendor (who maintains it, what's its permission scope, what does it actually do), run agents with the minimum tool set (every installed-but-unused tool is attack surface), and monitor for anomalous tool behavior — a tool that suddenly starts making unexpected network calls is compromised until proven otherwise.

Model supply chain matters too: know which models your agents use, where they're hosted, and what data they retain. A model provider change — version update, hosting migration — is a supply-chain event for every agent built on it. Version-pin models in production, test model updates against your eval suite before promoting, and maintain the ability to roll back. The agent that silently upgraded to a new model version overnight is an incident you chose not to prevent.

07 · Deployment checklist

The pre-production security gate

Before any agent touches production data or users, it passes this gate:

• Dedicated identity with least-privilege tool and data scopes — documented and reviewed.
• Approval gates on all consequential actions (external sends, writes, privilege-adjacent operations).
• Untrusted content handled as data, never as instructions — verified in the prompt/tool architecture.
• Access-aware retrieval and output DLP in place for the data the agent touches.
• Full audit logging: every action attributable to the agent identity, retained and reviewable.
• Red-team pass completed: injection via documents/tool outputs, privilege escalation, exfiltration paths, resource exhaustion — findings tracked and re-tested.
• Monitoring baselines defined with anomaly alerts; kill switch tested in staging.
• Supply chain vetted: pinned dependencies, reviewed tools/plugins, version-pinned models.
• Incident runbook written: who gets paged, how to revoke, how to investigate, how to communicate.
• Risk tier assigned and owner named — someone who can answer the five governance questions.

Agents that pass this gate aren't invulnerable — nothing is. But they're operated, not just deployed. And when something goes wrong, you'll know what happened, who did it, and how to stop it. That's the difference between a security program and security theater.