I came across an interesting article authored by Palo Alto Networks stating that AI security is fundamentally a cloud issue. This statement reminded me of a thread I found on the Reddit Cybersecurity subreddit where practitioners stated various angles upon which they believe AI security is based upon; I had to go back and read it over again. Secure your IAM policies, harden your cloud configurations, apply AppSec principles, etc.
Their views from the infrastructure angle are actually correct because many AI vulnerabilities stem from familiar problems: over-permissioned service accounts, especially when it comes to AI agents, broken access controls, poor input validation, and the like. But by focusing on the container, which is the infrastructure, we risk ignoring what’s inside. The source, data that trains, fine-tunes, and informs AI systems, represents a fundamentally different class of risk that infrastructure hardening cannot address.
The Infrastructure Argument
According to Palo Alto Networks’ recent report based on a survey of 2,800 executives and security practitioners, 99% of the organizations experienced at least one attack on an AI system in the past year. This assessment was in line with the discussion on Reddit, where the security professionals working in the trenches report that most AI failures look like traditional appsec and cloud security problems wearing new costumes. Prompt injection resembles bad input handling, overpowered agents reflect absent least-privilege principles, and RAG data leaks stem from broken access controls. The skills that matter, they argue, remain the same: API security, authentication, threat modeling, and cloud IAM.
Based on these statements, the recommendation follows logically: treat identity management as a tier-one priority, integrate cloud security into the SOC, and streamline incident response. There’s a consensus on identity as the primary attack surface. When over half of organizations identify overly lenient identity practices as a top challenge, the prescription seems obvious.
This framing has appeal precisely because it’s actionable; security teams know how to address cloud misconfigurations. They have tools, frameworks, and institutional knowledge built over a decade of cloud adoption. If AI security is just cloud security, organizations can bank on existing capabilities rather than building new ones from scratch.
The Blind Spot: Data as the Seed
The uncomfortable truth is that looking at AI security from an infrastructure angle treats AI systems as a black box to be protected, rather than examining what’s inside that box. When data is poisoned, whether it's training data, fine-tuning datasets, or RAG knowledge bases, every other component in the pipeline becomes tainted. You can build the most sophisticated fortress imaginable around something already corrupted.
Data poisoning operates through the front door; the malicious content wasn’t smuggled past access controls; it was ingested through legitimate pipelines functioning exactly as designed. The attack surface isn’t a misconfigured port or an overprivileged service account; it’s the data itself.
Consider the AI supply chain: Organizations routinely pull base models from platforms like Hugging Face with minimal verification. Datasets are selected because they fit the use case, not because they’ve been audited. Fine-tuning proceeds on trusted internal data, but that data may include contributions from contractors, vendors, or compromised systems. RAG systems connect to knowledge bases that continuously ingest external content.
At each stage, a pervasive “it’ll be fine” culture prevails. Each individual decision seems reasonable. Collectively, they create a pipeline where poisoned data can enter at multiple points, propagate downstream, and never face serious scrutiny.
Why Data Gets Underweighted
Several factors explain why practitioners tend to favor infrastructure while underweighting data integrity.
Familiarity. Cloud security, IAM, and AppSec are known quantities with established tooling and frameworks. Data integrity for AI is murkier. How do you audit a training dataset with billions of tokens? What does “clean” even mean when dealing with web-scraped content?
Visibility. You can see a misconfigured permission in a dashboard. You can’t easily see that 0.1% of your training data was subtly poisoned to create a backdoor that activates on specific triggers. The attack is invisible until it isn’t.
Accountability. Infrastructure has clear owners. Data provenance across the AI supply chain: base models from public repositories, datasets from various sources, fine-tuning on internal data is diffused and often undocumented. Who is responsible for verifying what entered the pipeline six months ago?
Timing. Infrastructure problems manifest at deployment and runtime, where monitoring exists. Data poisoning problems were introduced weeks or months earlier, during training, and may not manifest until specific conditions are met. By the time you discover the problem, the damage is baked in.
The Full Attack Surface
A complete view of AI security must account for threats across the entire lifecycle, not just deployment and runtime.
Model Supply Chain
Base models present opaque risks. Organizations have limited insight into training data composition, potential biases, or embedded behaviors. The model file format itself can be dangerous: “pickled” Python models can execute arbitrary code on load. More sophisticated threats involve backdoors baked directly into model weights. The model performs correctly 99.9% of the time but triggers malicious behavior on rare, specific inputs.
Training and Fine-Tuning Data
Poisoned training data can introduce vulnerabilities that persist through deployment. If a model memorizes sensitive information during fine-tuning, clever attackers can extract that data through targeted inference; no system prompt filter will prevent it. The integrity of fine-tuning datasets is often assumed rather than verified, particularly when the data is “internal.”
RAG and Knowledge Bases
Retrieval-augmented generation systems are only as trustworthy as the documents they retrieve. If the knowledge base ingests external content such as web pages, vendor documents, or user uploads, an attacker can inject content designed to influence model outputs. This isn’t a hypothetical; researchers have demonstrated practical attacks against RAG systems through poisoned documents.
Runtime and Infrastructure
This is where the traditional security model applies most directly. Overpermissioned agents, broken access controls, insufficient input validation, and poor identity management create exploitable vulnerabilities. An AI agent with write permissions it shouldn’t have is dangerous regardless of whether its training data was clean. These problems are real, significant, and addressable with existing tools.
The Human Layer
One practitioner offered an intriguing reframe: prompt injection is essentially social engineering for LLMs. When developers train AI to be helpful and harmless, they’re teaching it social norms. Attackers learn to social engineer around these guardrails the same way they’d manipulate a human: pretending to be researchers, framing requests as educational, using roleplay. This creates a feedback loop where more guardrails generate more sophisticated workarounds.
The Organizational Challenge
The gaps across this attack surface aren’t primarily technical; they’re organizational and cultural. Teams under pressure to ship AI features don’t have time for data validation, which is slow, expensive, and doesn’t produce visible results. The entire ecosystem — from open model repositories to internal data pipelines — operates on implicit trust.
This mirrors early cloud adoption, when the mantra was “just spin up an instance, we’ll secure it later.” But with data poisoning, “later” might mean the damage is already baked into production models. You can’t patch a backdoor embedded in model weights the way you’d patch a vulnerable library.
Organizations also lack mature processes for evaluating AI-specific vulnerabilities. Bug bounty programs report that triage for AI security issues often takes days or weeks because the institutional knowledge simply doesn’t exist yet. Security teams are playing catch-up with threats they don’t fully understand.
Toward Comprehensive AI Security
None of this means the infrastructure-focused advice is wrong. Identity management, cloud hardening, and AppSec fundamentals absolutely matter. The practitioners reporting that “hands-on labs beat theory” and that breaking your own RAG apps teaches more than any course are sharing genuine wisdom.
But comprehensive AI security requires expanding the aperture. Organizations should consider several additional priorities.
Data provenance and integrity. Establish clear documentation of where training and fine-tuning data originates. Implement verification processes for external datasets. Treat data curation as a security function, not just a data engineering task.
Supply chain verification. Audit base models before adoption. Understand what’s in the training data, or acknowledge that you don’t know. Implement controls around model loading to prevent arbitrary code execution.
RAG content controls. Apply the same scrutiny to knowledge base content that you would to code dependencies. Monitor what enters the retrieval corpus. Consider the poisoning risk of external content sources.
Defense in depth. Assume the model may behave unexpectedly. Implement output validation, constrain agent permissions regardless of assumed trustworthiness, and maintain human oversight for high-stakes decisions.
Institutional knowledge building. Invest in understanding AI-specific threats. The security team that only knows how to harden infrastructure will miss the vulnerabilities that infrastructure hardening can’t address.
Conclusion
The infrastructure angle of AI security isn’t wrong; it’s incomplete. Yes, secure your cloud. Yes, fix your IAM. Yes, apply AppSec principles. These fundamentals matter and will prevent many attacks.
But don’t mistake the container for the contents. When data is poisoned at the source, no amount of infrastructure hardening will save you. The most sophisticated perimeter security is worthless if the threat is already inside, baked into the very weights and behaviors of the models you’re protecting.
AI security requires thinking about the entire pipeline, from the provenance of base models to the integrity of training data to the content flowing into RAG systems to the permissions granted at runtime. Organizations that focus exclusively on any single layer will find themselves vulnerable to the others.
The attack surface hasn’t just moved to the cloud. It runs through every dataset, every model checkpoint, every document in the knowledge base. Security strategies need to be followed.