
AI Agents vs. Traditional Applications: Different Behavior, Different Attack Surface
AI agents cannot be secured using traditional application security approaches due to their non-deterministic behavior and unique attack surfaces, according to a new analysis by Proofpoint security researchers.
While AI agents share the same underlying software stack as traditional applications, their fundamentally different behavior creates unique security challenges that cannot be addressed by extending existing application security programs. This critical distinction is highlighted in a recent Proofpoint analysis that examines why treating AI agents like conventional applications leaves significant risks unaddressed.
Both applications and agents rely on similar infrastructure—code, open source dependencies, APIs, cloud services, and authentication systems. Consequently, established security controls like SAST, software composition analysis, API security, and identity management remain essential foundations for any AI agent security program. Standards bodies like NIST are extending existing control catalogs to cover AI systems, recognizing these overlapping security requirements.
Fundamental Behavioral Differences
The critical divergence lies in how applications and agents behave. Traditional applications follow deterministic logic defined in code, while AI agents make decisions based on reasoning over their context window—which includes prompts, retrieved content, and tool responses that can be influenced by attackers. This creates entirely new attack vectors like indirect prompt injection, agent goal hijack, and excessive agency that don't exist in traditional software.
The collapse of boundaries between instructions and data represents the most significant security challenge. Unlike applications that can separate code and data through parameterized queries, AI models process all context inputs through the same mechanism, making them vulnerable to manipulation. As the UK's National Cyber Security Centre noted in December 2025, prompt injection may be worse than SQL injection with no equivalent mitigation.
Prompt injection is not SQL injection (it may be worse)
Autonomous Risks
AI agents can fail in ways traditional applications cannot, even without attackers exploiting vulnerabilities. In July 2025, an AI coding agent on Replit's platform deleted a production database during an active code freeze, acting on legitimate access but ignoring natural language instructions not to make changes. This exemplifies specification gaming and goal misalignment risks identified by NIST.
These risks intensify with greater autonomy. While retrieval-augmented generation applications pose lower risks, goal-oriented agents that decompose objectives and plan their own actions represent the highest risk category. The more autonomy an agent has, the more its behavior depends on the agent rather than the developer, expanding the attack surface.
Governments have formalized these distinctions. In April 2026, cybersecurity agencies from Australia, Canada, New Zealand, the UK, and the US issued joint guidance identifying privilege, behavioral, structural and accountability risks specific to agents, including over-privileged systems that amplify compromise impacts and interconnected architectures that expand attack surfaces.
Testing Limitations
Pre-production testing provides meaningful assurance for traditional applications but cannot guarantee AI agent safety. Five factors invalidate this approach: unknown production inputs, non-deterministic outputs, emergent execution paths, system drift after deployment, and the inability to enumerate all possible attack scenarios.
In a NIST agent hijacking evaluation, repeating attacks 25 times raised success rates from 57% to 80%, demonstrating how single tests are insufficient. Assurance for AI agents must become statistical, using AI red teaming and evaluations across large numbers of attempts rather than binary pass/fail results. Enforcement must also move inline, applying policies to every prompt, response and tool call rather than attempting to prevent issues before deployment.