AI Agents Have a Security Problem Nobody Is Ready For

Security researchers have a name for what happens when an AI agent gets compromised: the attack surface explodes. An agent can access real credentials, write files, send requests to external services, and execute code, all while appearing to traditional security tools like normal authorized behavior. This is a problem the industry has been slow to confront.

A new analysis from ISACA, published this April, maps four failure modes that compound each other: visibility gaps (conventional detection tools cannot distinguish legitimate agent activity from intrusion), prompt injection (attackers embed commands in content the agent reads, and the agent obeys), supply chain exposure (malicious packages in agent skill registries, including one top-ranked package that Cisco researchers found performing silent data exfiltration), and direct vulnerabilities like remote code execution flaws and weak authentication on exposed agent instances.

The same pattern shows up in a March 2026 Harvard Business Review piece that put it plainly: AI agents act a lot like malware. They request permissions, operate autonomously, call external services, and react to instructions embedded in their environment. The difference is that yours asked for those permissions, and your IT department approved them.

The numbers make the problem concrete. Attackers using AI agents can compress a ransomware attack from initial compromise to full exfiltration into about 25 minutes. Phishing campaigns have moved on from poorly-written emails to interactive agent-driven chatbots that modify their approach in real time based on how the target responds, using scraped data to personalize each attempt.

Meanwhile, adoption is racing ahead of controls. About 65% of organizations are now experimenting with AI agents, and machine-to-machine traffic surged 7,851% in the past year as autonomous systems increasingly handle communications without human involvement. SecurityWeek noted in April that organizations are deploying agents before defining trust boundaries, oversight regimes, or even who is accountable when something goes wrong.

The structural problem is this: agents operate using legitimate credentials. They call approved interfaces. They look authorized because, in a narrow sense, they are. "The agent interprets those instructions as part of its task and can execute them," the ISACA analysis notes of prompt injection. Nothing in that sentence is unusual from the agent's perspective. That is exactly the problem.

There is no consensus solution yet. Some researchers are pushing for formal agent identity standards, similar to how SSL certificates work for websites. Others argue the problem is primarily organizational: scope agent permissions tightly, limit what external data agents can consume, and monitor agent behavior the way you monitor privileged human users. Palo Alto Networks has proposed classifying agents by privilege level and treating high-privilege agents as their own distinct threat model.

The practical advice is tedious but consistent: limit agent permissions to the minimum required, never let agents consume untrusted external data without filtering, audit skill registries and dependencies, and build rollback capability before building autonomy. The industry learned these lessons the hard way with web applications in the early 2000s. It looks like we are about to learn them again.