How do you secure an AI agent that can take actions?

Give the agent its own scoped identity with least-privilege permissions, require human approval for irreversible or high-value actions, validate tool inputs and outputs outside the model, restrict which data sources it can read, log every action, and enforce spending and rate limits.

Can enterprise data leak through an AI agent?

Yes, in three ways: the agent retrieving data the requesting user is not entitled to see, sensitive content being sent to a third-party model provider, and injected instructions causing the agent to exfiltrate data through a tool such as email or an outbound web request.

Securing Enterprise AI Agents: Injection & Tool Abuse

Q: What is prompt injection?

Prompt injection is an attack where instructions hidden in content the model processes — a web page, email, document, or ticket — cause it to take unintended actions. Because the model cannot reliably distinguish instructions from data, injection cannot be fully solved by prompting alone.

A chatbot that answers questions carries modest risk. An agent that reads your systems, decides, and then acts — sending email, updating records, moving money, provisioning access — is a different category of system entirely. It executes untrusted input with real permissions, which is a description security engineers recognise immediately.

The core problem: instructions and data are the same thing

Language models cannot reliably distinguish an instruction from content that looks like one. So text hidden in a web page, an inbound email, a support ticket, or a PDF can redirect the agent's behaviour. This is prompt injection, and it is not solvable by better system prompts — only by ensuring that a redirected agent cannot do anything consequential.

Design accordingly: assume the model will occasionally follow attacker instructions, and place the controls outside the model.

Constrain capability, not just behaviour

Give the agent its own identity. Never let it inherit broad service credentials; scope permissions to the minimum its task requires and log actions under that identity.
Separate read and write tools. A retrieval agent should have no write capability at all.
Require approval for irreversible actions. Payments, access grants, deletions, and external communications should present a proposal for human confirmation.
Validate outside the model. Enforce business rules in code — amount limits, allowed recipients, permitted record types — rather than trusting the model to respect them.
Set rate and spend limits. Bounds the damage from a looping or hijacked agent.

Respect user entitlements in retrieval

Risk	Control
Agent surfaces documents the user cannot access	Filter retrieval by the requesting user's permissions, not the agent's
Sensitive data sent to external model provider	Data classification gate before the call; redaction or self-hosted models for restricted classes
Injected instruction triggers exfiltration	Egress allow-listing; no unrestricted outbound HTTP tool
Training or logging retention by provider	Contractual controls plus verified zero-retention configuration

Permission-aware retrieval is the most frequently missed control. Indexing an entire document estate into one searchable store, then querying it with a single service identity, quietly bypasses years of access control work.

Isolate the untrusted content path

Where an agent must process external content — inbound email, scraped pages, uploaded files — treat that path as hostile. Separate the summarising step from the acting step, so content processing happens in a context with no tool access, and only structured, validated output crosses into the acting context. This single architectural split neutralises most practical injection attacks.

Observability and evaluation

Log every agent run with inputs, retrieved sources, tool calls, and outcomes, retained for investigation. Then test adversarially before deployment and on a schedule afterwards: injection attempts in each supported content type, attempts to induce out-of-scope tool use, entitlement bypass probes, and checks that limits and approvals actually hold.

Also monitor for behavioural drift. Model updates change behaviour, so maintain an evaluation suite that runs on every version change rather than assuming stability.

Governance that keeps pace

Maintain a register of agents in production with owner, permissions, data sources, tools, and approval requirements. Require review before an agent gains a new tool — capability expansion is where risk is actually introduced, and it typically happens through a small pull request nobody escalates. Set a review cadence and a retirement path for agents no longer used, because dormant agents retain live permissions.

Frequently asked questions

What is prompt injection?

Hidden instructions in content the model processes causing unintended actions. Because models cannot reliably separate instructions from data, it must be contained architecturally.

How do we secure an acting agent?

Scoped identity with least privilege, human approval for irreversible actions, validation in code outside the model, restricted data sources, full logging, and rate and spend limits.

Can data leak through an agent?

Yes — via over-broad retrieval, transmission to third-party providers, or injected instructions triggering exfiltration through a tool.

What is the single most important control?

Separating content processing from action-taking, so anything that reads untrusted input has no tools available.

Securing AI Agents in the Enterprise: Prompt Injection, Tool Abuse, and Data Leakage