Your AI Models Are Your New Attack Surface: A CISO's Complete Guide to AI Infrastructure Security

When your organisation adopted its first language model, someone on the security team probably asked: "Do we need to scan this?" The answer at the time was almost certainly "we'll figure it out later." That later has arrived — and most security programs are under-prepared for what they find.

AI infrastructure is not simply another category of software to scan. It introduces new classes of vulnerability that have no CVE numbers, no CVSS scores, and no patch Tuesday. Model endpoints can be exploited through the inputs they accept. RAG pipelines can be poisoned through the data they retrieve. Autonomous agents can be manipulated into taking actions that no developer explicitly authorised. This guide maps every layer of that attack surface so you can build a defensible posture before your next external audit — or breach.

Layer 1: Model Serving Endpoints

Every model in production is exposed through an API. Whether that is a hosted endpoint from a hyperscaler, a self-hosted FastAPI wrapper around an open-weight model, or a Triton Inference Server cluster on-premises, the security properties are similar: there is an HTTP surface accepting structured input that influences model behaviour.

What attackers target at this layer

• Unauthenticated or under-authenticated inference endpoints. In the rush to stand up pilots, teams frequently deploy models with shared API keys stored in frontend bundles, or with no authentication at all on internal network segments assumed to be trusted.
• Input validation gaps. Unlike traditional APIs that validate schema, model endpoints typically accept free-form text. There is no WAF rule that reliably blocks a well-crafted prompt injection.
• Rate limiting absent at the model level. An endpoint protected by a gateway may still accept batched requests that trigger enormous compute spend or exhaust GPU memory — a denial-of-service vector that bypasses conventional DDoS protections.
• Verbose error responses. A model endpoint that returns stack traces, system prompt fragments, or internal embedding distances in error conditions leaks architecture details that refine subsequent attacks.

Layer 2: RAG Pipelines and Vector Databases

Retrieval-Augmented Generation has become the dominant pattern for grounding LLM responses in enterprise data. A RAG pipeline typically involves a user query being embedded, searched against a vector store, and the retrieved chunks being injected into the model's context window alongside the query. Every step of that pipeline is an attack surface.

Retrieval poisoning

If an attacker can write to the document corpus that populates the vector store — through a compromised ingestion pipeline, a malicious document upload, or a supply-chain attack on a connected data source — they can inject text chunks specifically crafted to appear semantically similar to high-value queries. When a user asks about wire transfer procedures, the poisoned chunk is retrieved and included in context, steering the model toward the attacker's desired output.

Cross-tenant data leakage

Multi-tenant RAG systems must ensure that embedding-similarity search is scoped to the requesting tenant. Metadata filters applied after retrieval are insufficient — a malformed query can occasionally surface results from adjacent tenant partitions depending on how the vector store handles filter pushdown. The correct architecture applies tenant isolation as a hard constraint at index time, not as a post-retrieval filter.

Vector store access controls

Vector databases — Pinecone, Weaviate, Qdrant, pgvector, Chroma — are frequently treated as append-only data stores and granted broad write access to ingestion service accounts. In practice they should have read-only service accounts for the inference path, append-only accounts for the ingestion path, and administrative access (including deletion) restricted to break-glass procedures with audit logging.

Layer 3: LLM Gateways and Proxy Infrastructure

Enterprise deployments increasingly route all LLM traffic through a central gateway — tools like LiteLLM, Kong AI Gateway, Portkey, or custom middleware — to manage costs, enforce rate limits, log requests, and redact PII. These gateways become high-value targets precisely because they sit on the critical path for all AI traffic.

Gateway security properties to audit

• Request logging completeness. Does the gateway log the full prompt and completion, including system prompt? Without this, forensic investigation of a prompt injection incident is blind. Logs must be tamper-evident and streamed to a SIEM with retention matching your incident response policy.
• PII redaction accuracy. Gateway-level PII filters typically use regex or NER models. Test them with adversarial inputs that encode PII in formats the filter does not recognise — reversed text, homoglyph substitutions, split across tokens — and with context-dependent PII that requires semantic understanding to detect.
• System prompt confidentiality. Gateways that inject system prompts on behalf of applications must ensure those prompts are not reflected in completions or accessible through the API. System prompt extraction is a well-documented technique; your gateway should actively resist it.
• Model routing integrity. If the gateway routes requests to different backend models based on a policy (e.g., cheaper models for low-risk tasks), verify that the routing logic cannot be influenced by user-controlled input to escalate to a more capable or less-restricted model.

Layer 4: Autonomous AI Agents

Agents are LLMs equipped with tools — the ability to search the web, query databases, execute code, call external APIs, send emails, create calendar events, or modify files. That tool-use capability is also a privilege escalation surface. An agent with access to a code execution sandbox and an outbound network connection is, from a security perspective, a remote code execution primitive waiting for the right prompt to trigger it.

The effective permissions problem

Agent service accounts are rarely provisioned with least privilege. The typical deployment pattern is: configure the agent with the credentials needed for the most complex task it might ever need to perform, then rely on the model's instruction-following to constrain what it actually does. This is security through politeness, not security through access control.

Map every tool an agent has access to against the minimum permissions required for each tool. An agent that summarises documents from a SharePoint site does not need write access to that site. An agent that queries a database for reporting does not need UPDATE or DELETE privileges. Enforce these constraints in the service account permissions, not in the system prompt.

Indirect prompt injection through tool outputs

When an agent retrieves external data through its tools — a web page, a document, an email, a database row — that data becomes part of the context the model reasons over. If an attacker can control the content of that data, they can inject instructions that the agent interprets as legitimate task directives. This is indirect prompt injection: the attack surface is not the user's query but the data the agent fetches.

Building a Defensible AI Security Program

The four layers described above do not map neatly onto any existing security framework. SAST cannot scan a model's behaviour. DAST cannot fuzz a prompt injection surface systematically. Vulnerability management tools do not have CVEs for training data poisoning. What is required is a purpose-built approach:

1. Inventory all AI components. Model endpoints, vector stores, embedding pipelines, agent runtimes, fine-tuning infrastructure, and training data sources all belong in your AI asset inventory. You cannot protect what you cannot see.
2. Apply contextual security testing. Each component type requires tests appropriate to its attack surface — not a generic vulnerability scan. Model endpoints need prompt injection testing. RAG pipelines need retrieval poisoning simulation. Agents need privilege audit and indirect injection testing.
3. Enforce architectural controls. Authentication, least-privilege service accounts, tenant isolation, and tamper-evident logging are architectural properties that must be designed in, not bolted on after a finding.
4. Instrument for behavioural monitoring. Production AI systems should emit signals that allow detection of anomalous behaviour — unusually long completions, systematic prompt probing patterns, unexpected tool invocations, and retrieval patterns inconsistent with the user's role.
5. Map to a compliance framework early. NIST AI RMF, ISO 42001, and the EU AI Act all have technical control requirements that are much easier to satisfy if the architecture is designed with them in mind. Retrofitting compliance evidence onto a deployed system is expensive and incomplete.

AI infrastructure security is not a specialisation that only applies to AI companies. Any organisation that uses a language model in a business-critical workflow — and that is most organisations today — has AI attack surface to manage. The question is not whether to build an AI security program but whether to build it before or after your first incident involving your AI infrastructure.