AI Agent Security: Risks and Best Practices

Enterprises are handing AI agents (opens in new tab) real authority. An agent that reads email, queries a database, files a ticket, or moves money holds its own credentials, acts without asking, and consumes content from sources nobody vetted.

Attackers have worked out two things. Whoever gets text into an agent's path can give it instructions, and whoever copies an agent's name can borrow the trust employees place in it. Few enterprises have the controls to bound either move: among organizations that reported a breach of an AI model or application, 97% reported lacking (opens in new tab) proper AI access controls.

This article covers the six risks that recur across real agent incidents and the controls that limit damage on either side of your perimeter.

Key takeaways

• AI agent security covers five things: model inputs, agent credentials, tool permissions, persistent memory, and the trusted identities employees recognize.
• Six risks recur across recorded agent incidents: prompt injection, tool misuse, credential abuse, memory poisoning, supply chain compromise, and impersonated agents.
• Runtime controls limit what a compromised agent can do. Deception-layer controls dismantle the external infrastructure that feeds agents and fools people.

What AI agent security means

AI agent security protects the five things an autonomous agent depends on: its inputs, its credentials, its tool permissions, its memory, and the identity employees recognize. It covers more ground than application security because an agent acts with a user's authority and questions its inputs less than a person would.

The subject here is the agent as a target, distinct from agents doing security work (opens in new tab).

An agent holds credentials and acts on them without asking

Agents authenticate with service accounts, OAuth tokens, and API keys, then act on them without checking back. Those credentials routinely outlive their purpose and exceed their scope, so one compromised agent becomes a compromised set of systems.

Agent security spans the systems you run and the sources they trust

Agents read web pages, inbound email, calendar invites, form submissions, and third-party tool output, none of which you own or can patch. That puts a meaningful share of the attack surface in other people's infrastructure.

The main AI agent security risks

Six risks recur across the agent incidents on record:

1. Prompt injection hijacks the agent's goal

A model has no architectural boundary between the instructions it was given and the data it reads, so an attacker who plants instructions in content the agent will read can replace the agent's goal with their own, and no failsafe measures (opens in new tab) remove that today.

In EchoLeak, a crafted email drove Microsoft 365 Copilot to pull sensitive data from the user's context and embed it in a URL for exfiltration with zero user interaction (opens in new tab). Microsoft patched it as CVE-2025-32711.

2. Tool misuse turns granted permissions into unintended actions

A misdirected agent does its damage with the tools you granted it. A coding agent deleted a production database (opens in new tab) during an explicit code freeze, fabricated thousands of user records, then wrongly reported the data could not be restored.

No attacker was involved. The agent used permissions it already held, against instructions given repeatedly.

3. Credential abuse lets attackers inherit the agent's access

Stolen agent tokens hand the attacker everything the agent can touch, under a trusted application's identity. In the Salesloft Drift incident (opens in new tab), attackers took OAuth tokens from an AI chatbot integration and reached Salesforce, Google Workspace, and in some cases Slack at hundreds of organizations.

4. Memory poisoning persists a compromise across sessions

A poisoned memory outlives the session that planted it, and every later session inherits it. An attacker can delay the write until the user says something as ordinary as "yes," and it then sits in Gemini's long-term memory (opens in new tab) indefinitely.

5. Supply chain attacks reach the agent through its tools and connectors

Agents run code from MCP servers, packages, and extensions nobody on your side has vetted. The postmark-mcp server (opens in new tab) shipped clean for fifteen versions, then added one line that copied every outbound email to the developer's own address.

It was pulling roughly 1,500 downloads a week when it came down, and deletion does not uninstall it. Poisoned tool descriptions work differently: instructions hidden in the description steer the agent and read as ordinary metadata in review.

6. Impersonated agents exploit the trust employees place in them

Attackers copy the names and branding of legitimate AI tools to reach the people who use them.

Malicious browser extensions posing as AI assistants (opens in new tab) reached roughly 900,000 installs, with activity confirmed across more than 20,000 enterprise tenants (opens in new tab). Cloned download sites (opens in new tab) and search ads (opens in new tab) for popular AI tools deliver infostealers to employees searching for sanctioned software.

Prompt injection and impersonated agents are one problem in two directions

Prompt injection and impersonated agents both run on persuasion, which puts agent security in social engineering's territory. The other four are engineering problems: tool misuse is an authorization design failure, credential abuse is token replay, memory poisoning is a storage integrity failure, and supply chain compromise is a dependency problem.

A prompt injection payload carries no exploit code. Plain language convinces the model that the attacker's goal is the user's goal, the same way a pretext convinces an employee that a fraudulent wire request is routine.

Downstream systems see the agent's identity and nothing about who wrote its inputs, which makes the agent a confused deputy (opens in new tab) spending your credentials on an attacker's instructions. In the other direction, employees treat a message from the company assistant or an extension carrying a familiar AI logo as internal and safe, and attackers work that reflex.

Best practices for securing the agents you deploy

Five runtime controls bound how much damage a persuaded agent can do:

1. Scope every agent to least privilege and short-lived credentials

Provision a unique identity per agent, grant only what the current task requires, and replace long-lived API keys with tokens that expire when the task does. Register every agent identity centrally, because an unregistered agent is shadow infrastructure.

Do not widen permissions after an access error until the security team verifies the need.

2. Treat external sources the agent reads as untrusted

Assume every external input is attacker-controllable: web pages, inbound email, calendar invites, and tool responses. Enforce authorization downstream rather than trusting the agent to decide what it may do, and hold each agent to at most two of three properties: it processes untrusted input, it touches sensitive data, or it acts and communicates externally.

An agent that needs all three belongs under human review (opens in new tab).

3. Put independent approval in front of high-impact actions

Route financial transfers, code deployments, credential changes, and data exports through human sign-off, and build the approval check as deterministic logic rather than another model an attacker can talk around.

Agents should fail safe and escalate under uncertainty rather than guess, the baseline expectation (opens in new tab) for agentic deployments.

4. Log agent decisions, tool calls, and approvals

Capture step-by-step traces of the agent's reasoning, its tool calls, and the identity behind each action, then export them to your SIEM. Logging can also be a legal requirement: systems in the EU AI Act's high-risk categories must support automatic event recording (opens in new tab) from August 2026.

5. Test agents adversarially before and after material changes

Run structured adversarial testing (opens in new tab), indirect prompt injection included, before production and after any material change to the model or its tools. Fold them into CI/CD so behavioral drift surfaces before an attacker finds it, cover tool-poisoning and memory-write scenarios, and treat every new connector as a new attack surface (opens in new tab).

Best practices for the deception layer around your agents

Those controls bound the damage inside your environment. None reaches the infrastructure outside it, which takes three more:

1. Find the AI tools and assistants impersonating your brand

A fake assistant carrying your logo works because employees already trust the logo, and you cannot take down what you have not found.

Attackers distribute them through search ads, app stores, extension marketplaces, and cloned download sites, so all four need continuous detection (opens in new tab) on your brand and on the assistants your employees already use.

2. Dismantle the infrastructure that reaches your agents

Finding hostile infrastructure and removing it are two separate jobs, and only the second protects an agent. Injection payloads are hosted somewhere: a lookalike domain, a poisoned page, a throwaway sender.

Enumerate the sources your agents read, watch for newly registered permutations of the domains they trust (opens in new tab), and get the hostile ones taken down before an agent reads them.

3. Rehearse employees against agent-shaped lures

An employee who has never met a convincing fake assistant has no reflex to question one.

Run phishing simulations (opens in new tab) on impersonated-assistant scenarios and AI-themed lures drawn from attacks your employees are likely to see, and apply your existing callback rule when a request arrives from an agent or cites one.

How Doppel defends the deception layer around AI agents

Runtime controls cannot reach a counterfeit AI tool or the infrastructure carrying an agent-themed lure. At that layer, Doppel runs an AI-native Social Engineering Defense (opens in new tab) (SED) platform that unifies Digital Risk Protection (opens in new tab) and Human Risk Management (opens in new tab) on one Threat Graph (opens in new tab), so a single fraudulent listing resolves to the full campaign (opens in new tab) behind it.

Brand Protection (opens in new tab) detects fake assistants, spoofed AI tools, and the lookalike domains and cloned download pages that distribute them, then executes takedowns across registrars, hosts, ad networks, and social platforms in one action.

Doppel Vision (opens in new tab) drives that work with agentic AI, so a detection moves to enforcement without a ticket queue, and routes the escalations that need judgment to human analysts.

Executive Protection (opens in new tab) extends that protection to the administrators, developers, and leaders whose credentials open the agents, clearing leaked personal data from data broker sites, dark web forums (opens in new tab), and social platforms before attackers build it into a pretext, and flagging deepfake material (opens in new tab) impersonating those people.

Doppel Simulation (opens in new tab) converts a detected campaign into an employee drill in one click and runs it through Microsoft Teams meetings, voice phishing (opens in new tab) calls, and SMS lures (opens in new tab), where those lures actually arrive.

Secure the agent's judgment and its permissions

Permissions, sandboxes, and approval gates define what an agent can do. They say nothing about who gets to tell it what to do or who gets to wear its name. Pair runtime controls with defenses aimed at the deception layer, and keep raising the cost of impersonation campaigns against your brand.

Request a Demo (opens in new tab) to see how Doppel dismantles the infrastructure targeting your agents and your people.