Security teams often treat AI agents like advanced APIs, but they're not. The recent Zscaler research revealing indirect prompt injection vulnerabilities in four models highlights a critical issue: your approach to AI security might be flawed.
These myths persist because AI security is still being shaped by those who built traditional application security programs. The architectural differences are more significant than most teams realize.
Myth 1: "We can test AI agents like we test web applications"
Reality: AI behavior is unpredictable and context-dependent, breaking traditional testing frameworks.
When Zscaler tested models like Llama3-3-70b-instruct and Gemini-3-flash against indirect prompt injection, they found vulnerabilities. However, as Noah Kenney noted, these results aren't generalizable. The same model can behave differently based on temperature settings, system prompts, or even the time of day.
Your web application vulnerability scanner gives consistent results. Run it on different days, and you'll get the same findings. AI agents don't work that way. The attack surface shifts with every context window, every token generated, and every piece of data processed.
Your testing strategy needs continuous validation, not point-in-time assessments. You can't run a penetration test in Q1 and assume the findings hold through Q4.
Myth 2: "Binary safety classifications tell us which models to use"
Reality: Labeling a model as "safe" or "vulnerable" oversimplifies how AI systems fail.
Your procurement team wants a straightforward vendor risk assessment: is this model secure? Yes or no. That's not how it works.
The Zscaler test showed specific models were vulnerable to a payment scam scenario where an agent paid a fake $3 developer license fee. But that vulnerability is in the architecture, not just the model. Swap in a "safer" model without changing your system design, and you're still exposed.
The vulnerability lies in how you're building context windows, validating external data sources, and constraining agent actions. A model that resists prompt injection in one architecture might be easily exploited in another.
Stop asking vendors "is your model secure?" Start asking "what architectural controls do we need around this model?"
Myth 3: "Input validation solves prompt injection"
Reality: AI agents process context from sources you don't control, and traditional input sanitization doesn't work on natural language.
You know how to validate an email field: regex, length limits, character whitelists. None of that applies when an AI agent is reading a support ticket, processing a document, or scraping a webpage.
Aman Mahapatra highlighted the architectural nature of these vulnerabilities. The attack surface isn't just user input. It's every piece of text the agent processes. That support ticket? Could contain an injection. That API response? Could be malicious. That internal wiki page? Compromised three months ago.
You can't sanitize natural language without destroying its utility. "Remove all instructions" breaks legitimate content. "Filter suspicious patterns" gets bypassed by rephrasing.
The architectural defense isn't input validation. It's limiting what actions an agent can take, sandboxing execution environments, and requiring human approval for sensitive operations.
Myth 4: "We'll add AI security after we prove the business value"
Reality: Retrofitting security controls onto production AI systems is exponentially harder than building them in.
Your development team wants to ship the AI feature now, add security later. They're thinking about AI like a web form. Ship the form, add rate limiting later if abuse happens.
But AI agents don't just accept input. They make decisions, take actions, and access systems. The Zscaler payment scam scenario demonstrates this: the agent didn't just process bad data, it executed a financial transaction.
Once you've given an agent access to your payment system, your email, your database, you can't easily revoke capabilities without breaking the feature. Users expect the agent to "just work." Introducing approval workflows or access restrictions after launch feels like taking features away.
Build constraint systems from day one. Define what resources an agent can access, what actions require human approval, and what failure modes trigger automatic shutdowns. These aren't features you can bolt on later.
Myth 5: "Monitoring will catch AI security incidents"
Reality: You can't detect what you haven't defined, and AI failures don't look like traditional security events.
Your SIEM knows what a SQL injection looks like. It knows what credential stuffing looks like. What does a successful prompt injection look like in your logs?
The agent processed a document. The agent made an API call. The agent sent an email. Which of those was malicious? Your monitoring system doesn't know because the agent's behavior appears legitimate. It used valid credentials, followed proper protocols, and stayed within rate limits.
Monitoring is necessary but not sufficient. You need architectural controls that prevent bad outcomes regardless of how the agent was compromised. If an agent can't transfer more than $100 without human approval, monitoring becomes less critical. If an agent can't access production databases, you don't need perfect detection of data exfiltration attempts.
Define your blast radius first, then monitor for breaches of those boundaries.
Myth 6: "AI security is an AI team problem"
Reality: AI agents touch every part of your infrastructure, making this an enterprise architecture problem.
Your AI team built a chatbot. It queries your customer database, sends emails through your mail server, creates tickets in your support system, and updates records in your CRM. Which team owns the security?
The AI team says they're not infrastructure experts. The infrastructure team says they don't understand AI. The security team says they're still learning about large language models. Meanwhile, the agent has access to everything.
AI security requires collaboration between teams that traditionally don't work together. Your network segmentation strategy needs to account for AI agents. Your identity and access management needs to handle non-human actors. Your incident response playbook needs procedures for compromised AI systems.
This isn't a new silo. It's a forcing function for breaking down existing ones.
What to do instead
Start with architectural constraints. Before you deploy an AI agent, define what it absolutely cannot do. No financial transactions over $X. No access to production data. No irreversible actions without approval. Build these constraints into the system architecture, not the agent's instructions.
Implement continuous validation. AI behavior changes. Your testing needs to match that reality. Automated checks that run daily, not quarterly assessments.
Require human-in-the-loop for sensitive operations. The Zscaler payment scenario succeeded because the agent could complete a financial transaction autonomously. Don't give agents that authority.
Build monitoring around outcomes, not inputs. Don't try to detect every possible prompt injection. Monitor for unauthorized data access, unusual API patterns, and constraint violations.
Treat AI agents as untrusted actors. They get the same network segmentation, access controls, and audit logging as any external service. More, actually, because they're processing untrusted data by design.
The architectural vulnerabilities in AI systems aren't going away. Your security strategy needs to account for agents that can be manipulated, that behave unpredictably, and that have access to critical systems. Build defenses that work regardless of how clever the next attack gets.
