A growing number of analysts, vendors and security leaders describe AI as just another application in the environment: add it to the asset inventory, run it through the application security program and extend existing controls to cover it.
For AI agents, that framing is only partly correct. Agents do share the application stack. They run on code, open source dependencies, APIs and cloud infrastructure, authenticate as non-human identities, and need the same SAST, software composition analysis, API security, identity and access management and least privilege controls as any other workload.
But traditional applications are deterministic, and agents are not. An agent's behavior is driven by the model's reasoning over its context window, including retrieved content and tool responses an attacker can influence. Agents execute actions with delegated authority, chain tool calls across systems, and are exposed to indirect prompt injection, agent goal hijack and excessive agency, none of which appear as a code vulnerability.
Treating agents as just another application secures the shared stack and leaves the agent-specific attack surface unaddressed. It misreads where the risk is.
What applications and agents have in common
Every agent sits on top of a conventional software stack, and that stack carries the same attack surface as any other application. Agents are assembled from application code, orchestration frameworks and open source packages. They expose and consume APIs, authenticate as non-human identities using service principals, API keys and OAuth tokens, and read from and write to the same databases, file shares, SaaS platforms and vector stores the rest of the enterprise depends on.
That stack still requires the full set of established controls: a secure software development lifecycle with SAST and software composition analysis, API security, secrets management, identity and access management enforcing least privilege, data loss prevention, cloud security posture management, and centralized logging and monitoring. An agent deployed with vulnerable dependencies, hardcoded secrets, over-permissioned service accounts or exposed endpoints is compromised before its model makes a single decision.
Standards bodies treat this shared layer as foundational. In its January 2026 request for information on securing AI agent systems, NIST's Center for AI Standards and Innovation acknowledges that some agent risks, such as authentication and memory management flaws, overlap with traditional software security. NIST is also extending its existing SP 800-53 control catalog to AI through Control Overlays for Securing AI Systems, which include dedicated use cases for single-agent and multi-agent systems.
This foundation is necessary, and every agent security program has to be built on it. It is not sufficient. The controls that secure the stack were designed for software whose behavior is fixed in code, and that assumption does not hold for agents.
Where agents fundamentally differ
The differences show up in how agents behave, and each one changes what security has to do.
Characteristic | Applications | Agents |
Where behavior comes from | Deterministic logic defined in code and validated before release | The model's reasoning over its context window (prompts, retrieved content, tool responses and memory), much of which comes from untrusted sources |
Instructions and data | Separable by design, for example with parameterized queries and input validation | No reliable separation between instructions and data in the context window, which enables indirect prompt injection |
How access is used | Service accounts and API permissions exercised only through predefined code paths | Delegated credentials and tool permissions the agent invokes autonomously, creating the risk of excessive agency |
How work is performed | Predefined workflows and business logic | Autonomous planning and tool chaining across systems, including multi-agent workflows |
How it fails | Vulnerabilities in code, dependencies or configuration | The same vulnerabilities, plus goal misalignment, specification gaming and misuse of legitimate access, even without an attacker |
How it's attacked | Exploitation of vulnerabilities and misconfigurations, injection attacks and credential theft | All of those, plus indirect prompt injection, agent goal hijack, tool misuse and memory poisoning |
How it's tested | Pre-production testing (SAST, DAST, QA) validates the deterministic behavior that runs in production | Non-deterministic output can't be proven safe before release. Testing becomes statistical (AI red teaming and evals), and enforcement moves inline to prompts, responses and tool calls. |
The collapse of the boundary between instructions and data is the most consequential of these differences. Application security addressed injection classes such as SQL injection through structural controls: parameterized queries and input validation keep executable logic separate from user-supplied data. Large language models offer no equivalent mechanism. System prompts, user requests, retrieved documents and tool outputs share a single context window, and the model cannot reliably distinguish trusted instructions from untrusted content. The UK's National Cyber Security Centre made this argument in a December 2025 analysis titled Prompt injection is not SQL injection (it may be worse), cautioning that the risk may never be fully mitigated and must be managed through architecture and operational controls. Adversaries are already operationalizing it. Proofpoint threat researchers have documented underground tooling that generates indirect prompt injection payloads in emails, PDFs, calendar invites and web pages for roughly $150 a month.
Agents also fail in ways applications do not. In July 2025, an AI coding agent on Replit's platform deleted a production database during an active code freeze, despite explicit instructions not to make changes without approval. No vulnerability was exploited and no attacker was involved. The agent acted with access it had been legitimately granted, and the change freeze existed only as a natural language instruction rather than an enforced control. NIST's request for information anticipates exactly this class of failure, warning that agents may take actions that harm security "even in the absence of adversarial inputs," through specification gaming or the pursuit of misaligned objectives.
These differences intensify with autonomy. A retrieval-augmented generation (RAG) application that grounds its responses in enterprise content, a task-oriented agent that executes a defined workflow through tool calls, and a goal-oriented agent that decomposes an objective and plans its own course of action occupy progressively riskier positions. The greater the autonomy, the more behavior is determined by the agent rather than the developer, and the larger the agent-specific attack surface becomes.
Standards bodies and governments have formalized the distinction. NIST's AI Risk Management Framework devotes an appendix to how AI risks differ from traditional software risks, and OWASP publishes a dedicated Top 10 for Agentic Applications rather than folding agent risk into its application security lists. In April 2026, cybersecurity agencies from Australia, Canada, New Zealand, the UK and the US issued joint guidance, Careful Adoption of Agentic AI Services, which distinguishes autonomous agentic systems from traditional generative AI that typically requires human validation. It identifies privilege, behavioral, structural and accountability risks specific to agents: over-privileged agents that amplify the impact of a single compromise, goal misalignment and emergent capabilities that produce unexpected outcomes, interconnected architectures that expand the attack surface, and opacity that complicates auditing and compliance.
Why agents can't be tested the same way before production
Pre-production testing provides meaningful assurance for traditional applications because the code that ships is the behavior that executes. SAST, DAST and functional QA validate that code before release, and absent a code change, production behavior remains consistent. Agents invalidate that assumption in five ways.
- Production inputs are unknown at test time. An agent's behavior is conditioned on the emails, documents, tickets and retrieved content in its context window. Most of that content does not exist when the agent is tested, and some of it will be authored by adversaries specifically to manipulate it.
- Outputs are non-deterministic. The same input can yield different outputs, so a single passing test establishes little, and adversaries can iterate. In a NIST agent hijacking evaluation, repeating each attack 25 times raised average attack success from 57% to 80%.
- Execution paths are emergent. A goal-oriented agent decomposes its objective and selects each next action based on intermediate results. Test cases cannot enumerate execution paths that do not exist until the agent constructs them.
- The system drifts after deployment. Agents acquire new tools and MCP connections, permissions change, persistent memory accumulates, and the underlying model can be updated by its provider. The configuration that was tested is rarely the configuration running in production.
Pre-production testing remains necessary, but its role changes. Because agent behavior is non-deterministic, assurance becomes statistical: AI red teaming and evaluations (evals) measure failure rates across large numbers of attempts rather than issuing a single pass or fail. And because no pre-deployment test can establish that an agent is safe, enforcement must move inline, with policy applied to every prompt, response and tool call.
AppSec, SAST and API security are now table stakes
This is where the "just another application" framing does real damage. Secure an agent only as an application and you cover the shared foundation while missing every difference above.
Application security tools each answer a specific question. SAST asks whether source code contains a flaw. DAST asks whether a running application mishandles malicious input. Software composition analysis asks whether a dependency has a known vulnerability. API security asks whether traffic to an interface looks like abuse. Those questions still need answers, because agents are built on code, dependencies and APIs.
But ask them of an agent that was just redirected by a calendar invite, and every answer can come back clean. The code has no flaw. The input is an ordinary sentence. The dependency has no CVE. The API call is authenticated and well formed. The agent still did something it should never have done.
Our own research shows the effect. In Proofpoint's 2026 AI and Human Risk Landscape, half of the organizations that already had AI security controls in place still experienced a suspicious or confirmed AI-related incident. In our State of AI Security 2025 research, security and technology leaders named runtime as the most vulnerable phase of AI (38%) and the one they're least prepared to address (27%). That's the phase where agents differ most from applications, and where application security tools aren't looking.
That's why AppSec, SAST and API security are now table stakes for AI rather than the front line. They protect the foundation agents share with applications. The risk has moved to what makes agents different: what they read, what they're allowed to do and what they decide to do with access they already hold. As Proofpoint CEO Sumit Dhawan said when we launched Proofpoint AI Security, "Humans and AI agents share similar risks: both can be manipulated and both can take actions that diverge from their intended purpose, yet traditional security was never designed to validate intent."
Securing agents for what they are
Effective agent security starts from the shared foundation and then addresses the differences directly. That means enforcing limits outside the model itself and evaluating three things together, continuously, while an agent runs:
- Access: what the agent can reach, including data, tools, credentials and other agents.
- Intent: whether what it's doing still matches what the user asked for and the purpose it was given.
- Behavior: what it actually does, step by step, across tools and sessions.
Any one alone falls short. Access controls miss the agent that misuses permissions it legitimately holds. Behavioral monitoring sees an action without knowing whether it was authorized or aligned. Intent without access and behavior is a guess. Integrity comes from evaluating all three at the moment an agent acts, with the ability to block, not just log.
The bottom line
Applications and agents share a foundation, and every agent security program has to be grounded in it. But agents are not just another application. Their behavior is set by the content they read rather than the code they run. They can't reliably separate instructions from data, they act with delegated authority, and they can fail with nothing broken. Security that doesn't account for those differences will report that everything is covered while an agent does something it never should.
Keep the fundamentals. Then secure what makes agents different.