Tag: AI Security

Agent Breakout: The Risks of AI in Containerised Environments

Digital humanoid AI escaping from a secure container in a virtual environment
A digital AI figure breaks out of a secure container inside a glowing virtual infrastructure.

Initial Summary

We have spent the last two years hyper-focused on one primary question regarding enterprise AI: Data Privacy. “How do we prevent proprietary corporate data from leaking into public Large Language Models (LLMs) during training or inference?”

It was a valid concern that drove the initial wave of Private AI infrastructure. But as we pivot from passive chatbots and basic Retrieval-Augmented Generation (RAG) toward fully autonomous, agentic AI, the security landscape is shifting overnight.

The question is no longer just about what the AI knows. It’s about what the AI can do.

When you give an autonomous agent the power to write code, execute bash commands, manipulate file systems, and call APIs dynamically, you aren’t just deploying an application anymore. You are deploying a non-deterministic actor directly onto your infrastructure.

And if you are running those agents in standard Kubernetes (K8s) containers, you might be sitting on a security time bomb.

The Rise of “Agent Breakout”

In traditional software development, code is static. It goes through code reviews, vulnerability scanning, and CI/CD pipelines before reaching production. We know exactly what it’s supposed to do.

Autonomous AI agents throw that paradigm out the window. They generate and execute code on the fly in response to real-time prompts and objectives. If an agent encounters a problem, it might write a Python script to solve it, spin up a local shell instance, and execute it.

This introduces a massive, unprecedented vulnerability: Agent Breakout.

What happens if an autonomous agent—especially an advanced model with native cybersecurity capabilities, like Claude Mythos—suffers a prompt injection attack? What happens if it simply hallucinates a destructive system command, or decides to autonomously test the boundaries of its environment?

Recent benchmarking frameworks, such as SandboxEscapeBench, have delivered a harsh reality check. Frontier models are shockingly adept at identifying minor container misconfigurations (like an exposed Docker socket or unnecessary privileged flags) and weaponising them to escape the application environment entirely. Once an agent breaks out of its sandbox, it gains direct access to the underlying host infrastructure.

Containers Are Not Security Boundaries

For a decade, developers have treated containers like lightweight virtual machines. But from a strict security architecture perspective, containers are an illusion of isolation.

Containers rely on Linux namespaces and control groups (cgroups) to segment resources. Crucially, they share the host’s underlying operating system kernel.
+———————————–+
| Container A | Container B | <– AI Agents run here
+———————————–+
| Shared Host Kernel | <– Single point of failure
+———————————–+
| Physical Hardware |
+———————————–+

If an autonomous AI agent running inside a container executes a malicious script—either due to a prompt injection or a severe hallucination—and leverages an unpatched local privilege escalation (LPE) vulnerability in the Linux kernel, the game is over.

The moment the agent compromises the shared kernel, it doesn’t just own its container. It owns the entire physical or virtual node. It can peer into adjacent containers, scrape data from neighboring workloads, and move laterally across your enterprise network.

Giving an autonomous, code-generating entity access to a shared-kernel environment is an incident response nightmare waiting to happen.

—

## The Hypervisor Revenge: Why VMs Are Making a Comeback

This is where the structural architecture of the Virtual Machine (VM) reclaims its throne as the ultimate security boundary.

Unlike containers, a VM abstracts the physical hardware entirely via a Type-1 hypervisor, such as VMware ESXi. Each VM operates with its own completely isolated, independent Guest OS kernel.

+——————-+ +——————-+
| VM 1 | | VM 2 |
| +————-+ | | +————-+ |
| | AI Agent | | | | Safe Workld | |
| +————-+ | | +————-+ |
| Guest OS Kernel | | Guest OS Kernel | <– Completely Isolated
+——————-+ +——————-+
| ESXi Hypervisor | <– Hardware-level separation
+——————————————-+
| Physical Hardware |
+——————————————-+
“`

If an AI agent goes rogue inside a dedicated virtual machine, the blast radius is exactly zero from an infrastructure standpoint.

Even if the agent achieves full root privileges inside the VM, it is trapped inside that specific Guest OS. It cannot cross the hypervisor boundary to see other virtual machines, it cannot access unallocated memory blocks, and it cannot compromise the physical host. The hypervisor natively enforces strict cryptographic and physical isolation.

The “Sandbox-within-a-Sandbox” Strategy

Does this mean developers have to abandon the containerised ecosystems, microservices, and rapid deployment tools they love?

Not at all. The smartest architectural play for enterprises today is the Sandbox-within-a-Sandbox approach.

Platforms like VMware Private AI (powered by VMware Cloud Foundation) are perfectly positioned for this shift. Instead of forcing developers to choose between the agility of containers and the security of VMs, you combine them:

  1. The Inner Sandbox: Developers build, test, and deploy their autonomous agents using containerised microservices and tools they are familiar with.
  2. The Outer Sandbox: The entire containerised agent execution environment is wrapped inside a hardened Deep Learning Virtual Machine (DLVM) template enforced by the ESXi hypervisor.

If an agent achieves a container breakout, it merely breaks out into the guest operating system of a single, isolated VM. It hits a brick wall at the hypervisor layer, completely neutralising the threat to the broader enterprise.

The New Battleground for Private AI

We are moving past the era of the simple corporate chatbot. The next generation of enterprise value will be unlocked by autonomous agents that actually work for us—compiling data, writing patches, managing networks, and executing workflows.

But as we hand over the keys to autonomous code-generation, security cannot be an afterthought.

The public cloud and bare-metal Kubernetes distributions are built on the assumption that container-level boundaries are sufficient. In the era of agentic AI, they aren’t. By grounding your Private AI strategy in hypervisor-enforced compute isolation, you aren’t just protecting your data privacy—you are protecting your entire operational infrastructure from the unpredictability of autonomous code.

What are your thoughts? Is your organisation already experimenting with autonomous AI agents, and how are your security teams handling the runtime risk? Let’s discuss in the comments below.

Implementing Granular Access Control in RAG Applications

A Guide to Implementing Granular Access Control in RAG Applications

Audience: Security Architects, AI/ML Engineers, Application Developers

Version: 1.0

Date: 11 September 2025

1. Overview

This document outlines the technical implementation for enforcing granular, “need-to-know” access controls within a Retrieval-Augmented Generation (RAG) application. The primary mechanism for achieving this is through metadata filtering at the vector database level, which allows for robust Attribute-Based Access Control (ABAC) or Role-Based Access Control (RBAC). This ensures that a user can only retrieve information they are explicitly authorised to access, even after the source documents have been chunked and embedded.

2. Core Architecture: Metadata-Driven Access Control

The solution architecture is based on attaching security attributes as metadata to every data chunk stored in the vector database. At query time, the system authenticates the user, retrieves their permissions, and constructs a filter to ensure that the vector search is performed only on the subset of data to which the user is permitted access.

3. Step-by-Step Implementation

3.1. Data Ingestion & Metadata Propagation

The integrity of the access control system is established during the data ingestion phase.

  1. Define a Metadata Schema: Standardise the security tags. This schema should be expressive enough to capture all required access controls.
  • Example Schema:
  • doc_id: (String) Unique identifier for the source document.
  • classification: (String) e.g., ‘SECRET’.
  • access_groups: (Array of Strings) e.g., [‘NTK_PROJECT_X’, ‘EYES_ONLY_LEADERSHIP’].
  • authorized_users: (Array of Strings) e.g., [‘user_id_1’, ‘user_id_2’].
  1. Ensure Metadata Inheritance: During the document chunking process, it is critical that every resulting chunk inherits the complete metadata object of its parent document. This ensures consistent policy enforcement across all fragments of a sensitive document.
    Conceptual Code:
    Python
    def process_document(doc_path, doc_metadata):
        chunks = chunker.split(doc_path)
        processed_chunks = []
        for i, chunk_text in enumerate(chunks):
            # Each chunk gets a copy of the parent metadata
            chunk_metadata = doc_metadata.copy()
            chunk_metadata[‘chunk_id’] = f”{doc_metadata[‘doc_id’]}-{i}”
            processed_chunks.append({
                “text”: chunk_text,
                “metadata”: chunk_metadata
            })
        return processed_chunks

3.2. Vector Storage

Modern vector databases natively support metadata storage. This feature must be utilised to store the security context alongside the vector embedding.

  1. Generate Embeddings: Create a vector embedding for each chunk’s text.
  2. Upsert with Metadata: When writing to the vector database, store the embedding, a unique chunk ID, and the whole metadata object together.
    Conceptual Code (using Pinecone SDK v3 syntax):
    Python
    # 'vectors' is a list of embedding arrays
    # 'processed_chunks' is from the previous step

    vectors_to_upsert = []
    for i, chunk in enumerate(processed_chunks):
        vectors_to_upsert.append({
            "id": chunk['metadata']['chunk_id'],
            "values": vectors[i],
            "metadata": chunk['metadata']
        })

    # Batch upsert for efficiency
    index.upsert(vectors=vectors_to_upsert)

3.3. Query-Time Enforcement

Access control is enforced dynamically with every user query.

  1. User Authentication & Authorisation: The RAG application backend must integrate with an identity provider (e.g., Active Directory, LDAP, or OAuth provider) to securely authenticate the user and retrieve their group memberships or security attributes.
  2. Dynamic Filter Construction: Based on the user’s attributes, the application constructs a metadata filter that reflects their access rights.
  3. Filtered Vector Search: Execute the similarity search query against the vector database, applying the constructed filter. This fundamentally restricts the search space to only authorised data before the similarity comparison occurs.
    Conceptual Code:
    Python
    def execute_secure_query(user_id, query_text):
        # Authenticate user and get their permissions
        user_permissions = identity_provider.get_user_groups(user_id)
        # Example: returns ['NTK_PROJECT_X', 'GENERAL_USER']

        query_embedding = embedding_model.embed(query_text)

        # Construct the filter
        # This query will only match chunks where 'access_groups' contains AT LEAST ONE of the user's permissions
        metadata_filter = {
            "access_groups": {"$in": user_permissions}
        }

        # Execute the filtered search
        search_results = index.query(
            vector=query_embedding,
            top_k=5,
            filter=metadata_filter
        )

        # Context is now securely retrieved for the LLM
        return build_context_for_llm(search_results)

4. Secondary Defence: LLM Guardrails

While metadata filtering is the primary control, output-level guardrails should be implemented as a defence-in-depth measure. These can be configured to:

  • Block Metaprompting: Detect and block queries attempting to discover the security structure (e.g., “List all access groups”).
  • Prevent Information Leakage: Scan the final LLM-generated response for sensitive keywords or patterns that may indicate a failure in the upstream filtering.

Generative AI RAG Applications: Protecting Sensitive Data Safely

The Challenge: Lost in Translation

Retrieval-Augmented Generation (RAG) is revolutionising how we access information. By connecting powerful Large Language Models (LLMs) to our private data, we can create incredibly smart assistants. But there’s a hidden security challenge: RAG applications work by shredding documents into hundreds of small chunks. What happens to the “Top Secret” stamp or the “Eyes-Only for the Finance Team” note on the original document?

Without a proper security design, these critical access controls can be lost. A user asking a general question could receive an answer synthesised from a highly sensitive chunk they were never meant to see. In secure environments, this is a non-starter.

So, how do you ensure your RAG system respects your organisation’s “need-to-know” policies?

The answer lies in making your data’s security permissions a first-class citizen throughout the entire AI pipeline.

The Solution: Smart Data with Metadata Filtering

The most robust solution is to embed your access rules directly into your data using metadata. Think of it like a digital security tag attached to every single chunk of information. When a user asks a question, the system first checks their ID card against the security tag on every chunk before even beginning its search. This is metadata filtering, and it’s the gold standard for a secure RAG.

Here are the most common approaches to implementing it.

Option 1: Attribute-Based Access Control (ABAC)

This is the most flexible and powerful approach. Each data chunk is tagged with specific attributes (e.g., caveat: ‘PROJECT_X’, department: ‘LEGAL’), and each user is assigned a set of attributes. The system grants access if the user’s attributes match the data’s attributes.

  • Pros:
    • Extremely Granular: Control access down to a single document for a single user.
    • Highly Scalable: Policies are dynamic and don’t require changing roles for every new project.
  • Cons:
    • Complex Setup: Requires a mature identity management system and careful planning to define all the attributes.

Option 2: Role-Based Access Control (RBAC)

RBAC is a more traditional and often simpler approach. Instead of fine-grained attributes, users are assigned roles (e.g., ‘Project_X_Analyst’, ‘Compliance_Officer’). Each document chunk is then tagged with the roles that are allowed to see it.

  • Pros:
    • Easier Management: Simpler to manage permissions for large groups of users.
    • Intuitive: Often aligns with existing organisational structures and roles.
  • Cons:
    • Less Flexible: Can lead to “role explosion” where you need to create dozens of roles to cover all permissions. Not great for handling one-off “eyes-only” exceptions.

Option 3: Access Control Lists (ACLs)

This is the simplest method, where each document chunk’s metadata contains a literal list of the user IDs or group IDs allowed to view it.

  • Pros:
    • Simple to Implement: Very straightforward logic for small-scale projects.
  • Cons:
    • Doesn’t Scale: Managing lists of thousands of users across thousands of documents is unmanageable and prone to errors. Best avoided for enterprise systems.

How It Works in Practice

Regardless of the model you choose (ABAC is typically best), the implementation follows four key steps:

  1. Tag at the Source: During ingestion, extract the security classifications from each document and attach them as metadata.
  2. Chunk with Inheritance: When you split the document into pieces, ensure every single chunk inherits the parent’s security metadata. This is the most critical step.
  3. Store Together: In your vector database, store the vector embedding and its rich metadata object side by side.
  4. Filter Before Searching: When a user makes a query, the system first verifies their identity and permissions. It then builds a security filter and tells the database, “Only search for answers within the chunks that match this user’s permissions.”

This ensures the LLM only ever sees data the user is already cleared to see, effectively eliminating the risk of accidental data leakage.

Final Summary

Building a RAG application for a secure environment requires treating access control as a core design pillar, not an afterthought. By embedding permissions as metadata and enforcing filtering at the database level, you can build a powerful AI tool that is not only intelligent but also trustworthy and secure. This approach transforms security from a simple gatekeeper into an integral part of the data itself, ensuring your sensitive information stays that way.