AI agents have stopped being a demo. They sit inside ticketing systems, source code repositories, chat platforms, and cloud dashboards, and at a growing number of companies they can open pull requests, query production databases, and start automated workflows without a person watching. Cisco's State of AI Security 2026 describes exactly this pattern: assistants wired into core business systems, holding a level of access that used to require a human account and a manager's approval.

Security leaders know it. A Dark Reading poll found that 48 percent of cybersecurity professionals named agentic AI and autonomous systems the top attack vector heading into 2026, ahead of deepfakes and passwordless adoption. Darktrace's State of AI Cybersecurity 2026 put the share of concerned professionals at 92 percent. Separately, 87 percent of security teams told Ivanti that adopting agentic AI is a priority, in a survey of more than 1,200 practitioners.

Those numbers do not contradict each other. They describe the same problem from two directions. Teams are deploying the technology they are most worried about, because the business has already decided it wants the productivity. The gap between wanting agents and being able to secure them is where the next wave of incidents is forming, and most enterprises have not closed it.

Agents scale the vulnerabilities you already have

OWASP's Top 10 for Agentic Applications, published in December 2025, is blunt on this point. Agents mostly amplify existing weaknesses rather than inventing new ones. A weak credential is still a weak credential. A tool that was never scoped is still unscoped. What changes is speed and blast radius. An agent that can call an API a thousand times an hour will find the gap you left open far faster than a person clicking through a UI.

Each risk on that list maps onto work engineering teams already do.

Read that table through an identity lens and a pattern appears. Most of the ten come back to a non-human identity that holds too much authority for too long. OWASP drew the same conclusion: its agentic list maps directly onto its Top 10 for Non-Human Identities, where over-privileged accounts, exposed secrets, and long-lived credentials show up as root causes rather than symptoms.

The MCP problem: a protocol that made the attack surface bigger

Most agents reach their tools through the Model Context Protocol, the standard Anthropic released and the industry adopted with unusual speed. MCP gave every agent a common way to call every tool, which is exactly why it is now the busiest place to look for trouble. In April 2026, The Register reported a design flaw that put roughly 200,000 MCP servers at risk, and the Cloud Security Alliance published a research note calling the situation a security crisis in agent infrastructure. The NSA followed in May 2026 with its own MCP security design guidance, which tells you how far this has moved from academic curiosity.

The failure modes are specific, and none of them are exotic. Tool poisoning hides instructions inside a tool's description, which the model then reads as trusted configuration. Resource and data poisoning plants malicious content in the external sources a tool fetches from, so the agent picks up instructions along with the data it asked for. Context poisoning changes shared state that other agents later trust. Every one of them is the same class of bug as deserializing untrusted input, wearing new clothes.

Why your existing AppSec tooling does not catch it

Static analysis reads code. Dynamic scanners poke endpoints. Neither one watches what an agent decides to do at 2am with the credentials it was handed. A secret scanner will find a leaked token. It says nothing about a token being used exactly as designed, for a purpose no one authorized.

Sonatype's 2026 State of the Software Supply Chain report adds a second layer of risk. AI-assisted development speeds up dependency changes, and the automation can select a version that does not exist or a package nobody vetted. A data quality problem that used to be a harmless typo now propagates at machine speed.

The threat is not hypothetical. In July 2026, Hunt.io published research into a suspected China-based intrusion against government and financial services targets. The attackers had wired Claude Code and a DeepSeek model into their workflow for attack reasoning, script generation, exploit adaptation, and phishing page development. The models were not the vulnerability. They were the accelerant.

A practical playbook for securing agents

The following eight controls are ordered roughly by how quickly they pay off, starting with the one that pays off first.

1. Inventory non-human identities

Every agent gets an identity, and every identity goes into the same inventory as your human accounts. You cannot apply least privilege to something you have not named. Most enterprises already hold more machine identities than people, and the ones attached to agents are the newest and the least governed.

2. Cut tool scope to least agency

An agent that drafts emails does not need write access to the CRM. Give each agent the smallest set of tools that completes its job, and validate parameters on the way in. Deny by default, allow by exception, and revisit the list when the task changes.

3. Replace long-lived tokens with short-lived, scoped credentials

Static API keys that live for a year are the most common mistake in agent deployments. Issue per-agent, per-task credentials that expire in minutes, tie them to a workload identity, and keep them out of memory and logs where a downstream tool can read them.

4. Sandbox code execution and lock down egress

If an agent can write and run code, that code runs in a container with no network by default and no path to the host. Treat every execution as hostile until proven otherwise.

5. Treat retrieved content as untrusted input

Web pages, documents, tickets, and tool descriptions are all attacker-reachable. Strip or neutralize embedded instructions, and keep the agent's objective narrow enough that a hijack has nowhere useful to go.

6. Sign the agentic supply chain

Generate an AI bill of materials next to your software bill of materials. Pin versions, verify signatures, and refuse packages without provenance. If you cannot say which tools and models an agent is built from, you cannot patch it when one of them turns out to be compromised.

7. Put the agent identity in every audit log

When an agent acts, the log should name the agent, the tool it called, the credential it used, and the human or system that delegated the authority. An audit trail that records a generic API request tells you nothing useful after an incident.

8. Red-team the workflows, not just the model

Attack your own agent flows. Inject a poisoned tool description, plant instructions in a fetched document, and watch what the agent does. The goal hijack you find in a test is the one you never find in production.

If you are building agent features into a product

For product teams shipping agents to their own customers, the same controls turn into features buyers ask about. Log every agent action in a way the customer can see. Give administrators a kill switch. Let them scope which tools an agent may touch and which data it may read. Enterprises running procurement in 2026 put these questions on the security questionnaire, and a product that answers them wins deals that a product without them loses to a failed review.

That runs in both directions. A development team that builds agent features with per-agent identity and short-lived credentials from the first sprint spends far less time retrofitting them when a client's security team starts asking. It ships something that survives an audit instead of something that needs a rewrite.

Model safety is not system security

A common mistake is to treat this as a model problem and hand it to the team that owns the LLM. Guardrails on the model help, and they are worth having. They do not cover the blast radius. A perfectly aligned model told to read a poisoned document will still follow the poisoned instruction if nothing in the surrounding system stops it. The controls that matter sit around the model: the identity it runs as, the tools it can reach, how long its credentials last, and what happens when it tries something no one asked for. That is system security, and it belongs to the platform and application teams, not to the AI group alone.

The first 90 days

If none of this exists yet inside your organization, a sensible sequence looks like this.

• Weeks 1 to 4: inventory machine identities, flag long-lived tokens, and list every agent with write access to production.
• Weeks 5 to 8: scope tools down, rotate credentials, and turn on egress logging.
• Weeks 9 to 12: sign the supply chain, add provenance to audit logs, and run the first agent red-team exercise.

None of those steps requires a new platform. Most of them are configuration and process, applied to identities that until now had none.

Agent security is the discipline you already have

Securing agents is not a new field. It is identity management, least privilege, sandboxing, and logging applied to machines that act on their own. The tools are new and the speed is new. The controls are the ones good engineering teams have used for twenty years, pointed at a new kind of account.

Security teams that treat an agent as an untrusted service account get through an incident review with something to show for it. Teams that hand an agent a permanent key to production and assume the model will behave find out otherwise, usually from a third party who noticed first.