Llama Security: What Llama Guard, IAM Scoping, and the License Actually Cover
Securing a Llama deployment layers three separate mechanisms: Llama Guard and Prompt Guard filtering content, cloud-native IAM or RBAC scoping which identity can call the model, and Meta'"'"'s Acceptable Use Policy setting legal boundaries on use. None of the three evaluates a specific request against an enterprise'"'"'s own policy at the moment it is made. Two 2026 CVEs in the serving layer underneath Llama show what that gap costs.
Deploying Llama at enterprise scale means stacking three separate controls on top of the open-weight model itself. A safety classifier, usually Meta's own Llama Guard, screens prompts and completions for hazardous content. Cloud-native identity controls, IAM policies on Bedrock or RBAC on Azure AI Foundry, decide which caller can invoke the model at all. Meta's Acceptable Use Policy sets the legal boundary on what the license permits. I want to walk through what each one actually secures, then two 2026 vulnerabilities in the serving layer that show what none of them catch.
TL;DR
- Llama Guard and Prompt Guard classify prompt and completion content for safety hazards and jailbreak attempts; they are separate model calls, not built into base Llama inference.
- IAM policies on AWS Bedrock and RBAC plus private endpoints on Azure AI Foundry scope which identity can invoke a given Llama model, not what a permitted caller sends.
- Meta's Acceptable Use Policy is a licensing and legal control, enforced through terms of use, not a technical check on any specific request.
- Two 2026 CVEs in the inference-serving layer, one in vLLM and one in Ollama, show what happens when nothing but these three layers stands between an HTTP request and the model.
Llama Guard filters content, it does not authorize the request
Meta's Llama Guard classifies prompts and completions against a hazard taxonomy built with MLCommons, and the latest version, Llama Guard 4, is integrated into Meta's Llama Moderations API. Prompt Guard, part of the same Purple Llama suite, targets jailbreak attempts and prompt injection specifically. LlamaFirewall extends this approach to agentic deployments, screening for insecure code generation and risky tool calls.
These are real, useful controls, and they answer a content-safety question: does this text look hazardous, does this input look like a jailbreak attempt. None of them answer an authorization question: should this specific authenticated caller, given their role and the data classification of what they're sending, be allowed to make this request at all. A request that contains no hazardous content and no jailbreak pattern sails through Llama Guard cleanly, even if it's an unauthorized employee exfiltrating a customer's confidential contract terms into a prompt.
IAM and RBAC scope the caller, not the content
On AWS Bedrock, IAM policies scope `bedrock:InvokeModel` and `Converse` calls to specific foundation-model ARNs, letting an administrator grant or deny access to Bedrock's Llama models with the same least-privilege pattern used across AWS services. Azure AI Foundry pairs least-privilege RBAC, with roles for ML engineers and data scientists, with managed virtual networks and private endpoints that remove sensitive workloads from public network exposure entirely.
Both mechanisms control which identities can invoke which models. Once an identity clears that check, every request it sends is treated identically by IAM or RBAC, regardless of what the prompt contains, the post-authentication gap that shows up across nearly every cloud-hosted model deployment. A data scientist with legitimate access to a Llama deployment on Bedrock is authorized to call the model. IAM has nothing to say about whether the specific dataset they're about to paste into that call belongs in a prompt in the first place.
The Acceptable Use Policy is enforced through terms, not through traffic
Meta's Llama 4 Acceptable Use Policy prohibits illegal use, activities that risk bodily harm, fraud, disinformation, and impersonation, and it places specific restrictions on EU-domiciled entities using Llama 4's multimodal models. Hugging Face enforces the license at the point of download through gated repositories, requiring users to accept Meta's terms before the weights are released. Both mechanisms are real and meaningfully limit who can obtain and legitimately deploy Llama at all.
Neither mechanism inspects a request at inference time. The Acceptable Use Policy is a legal instrument, enforceable after the fact through the license agreement, not a filter sitting on the request path checking each prompt against its terms in real time.
Two 2026 CVEs in the layer underneath all three controls
None of Llama Guard, IAM scoping, or the license touches the software actually serving inference requests, and that software has had a rough 2026. CVE-2026-22778, a CVSS 9.8 flaw in vLLM, chains an information-disclosure bug with a heap overflow in a bundled video decoder to achieve pre-authentication remote code execution through the multimodal inference API, the same HTTP path a legitimate multimodal Llama request travels. Separately, CVE-2026-7482, nicknamed "Bleeding Llama," is an unauthenticated memory-leak vulnerability in Ollama, with researchers estimating roughly 300,000 exposed Ollama servers reachable without any authentication at all.
Neither of these bugs cares what Llama Guard or an IAM policy says, because both sit below that layer, in the code parsing the HTTP request before any content-safety or identity check gets a chance to run. A serving stack with a vulnerable request parser is exposed regardless of how well-configured the layers above it are, which is the same theme running through what actually gets logged across cloud-hosted and self-hosted Llama deployments: the hosting layer, not the model, decides what a security team can see.
DeepInspect
This is exactly what DeepInspect does. DeepInspect sits inline as a stateless proxy in front of any HTTP-based LLM endpoint, whether that's a Bedrock or Azure-hosted Llama deployment or a self-hosted vLLM or Ollama server, evaluating identity, role, and data classification on every request before it reaches the model or the serving software underneath it.
Llama Guard, IAM policies, and Meta's license keep doing their jobs: filtering hazardous content, scoping caller access, and setting the legal terms of use. DeepInspect adds the layer none of them provide, a per-request, identity-bound policy decision, sitting in front of the serving stack rather than depending entirely on it, with a signed audit record for every decision. Book a technical deep dive at deepinspect.ai.