Secure your AI agents
at the kernel level.

Launch AI agents inside isolated cgroups with Guardian Launcher. Enforce per-agent security policies at the Linux kernel level using eBPF — unspoofable identity, file access control, network monitoring, and interactive approvals. No agent code changes required.

guardian-shell

# Launch agents in isolated cgroups — the default, secure way

$ guardian-launch --agent claude-code -- claude

[INFO] Created cgroup: guardian/claude-code (unspoofable identity)

[INFO] Applied policy: agents.claude-code (3 allow, 5 deny rules)

[INFO] Resource limits: mem=4G, cpu=200%, pids=512

[OK] Agent "claude-code" running in enforced cgroup

 

$ guardian-launch --agent aider -- aider --model claude

[OK] Agent "aider" running in enforced cgroup

 

[DENY] claude-code blocked from reading ~/.ssh/id_rsa

[ALLOW] claude-code accessing ~/project/src/main.rs

[REQUEST] aider requests access to ~/.aws/credentials

         Awaiting human approval... (timeout: 120s)

Defense-in-depth for AI agents

Launch agents in isolated cgroups via Guardian Launcher. Each agent gets an unspoofable identity, per-agent policies, and kernel-level enforcement — without slowing them down.

Cgroup-based agent isolation (default)

Launch agents via Guardian Launcher into dedicated Linux cgroups. Each agent gets an unspoofable, kernel-enforced identity — no PID guessing, no process name spoofing. Cgroup identity is the default and recommended flow. Resource limits (memory, CPU, PIDs) are applied automatically.

Kernel-level enforcement with eBPF

Security policies are enforced at the Linux kernel level using LSM BPF hooks. When an agent is launched in its cgroup, all file access, command execution, and network connections are governed by kernel-enforced rules that the agent cannot bypass.

Per-agent security policies

Each cgroup-isolated agent gets its own TOML policy. Claude Code can access your project directory while Aider is restricted to a different scope. Guardian Launcher maps agent names to policies automatically.

Interactive approval workflows

When an agent requests access to a sensitive resource, you get a real-time notification. Approve or deny via the web dashboard with risk-colored banners and mandatory wait timers.

Real-time dashboard and alerts

See every file access, command execution, and network connection in real time. Get alerts via Slack, email, or webhooks. Export Prometheus metrics for your existing observability stack.

Complete audit trail

Every access decision is logged to a SQLite database with SIEM-compatible JSON format. Track who accessed what, when, and whether it was approved — perfect for compliance.

Lightweight, zero-config for agents

Less than 3% CPU overhead. No instrumentation or modification of agent code required. Works transparently with any LLM agent. Deploys as a single binary with embedded templates.

How it works

Three steps to kernel-level agent security. No Kubernetes required. No agent code changes.

01

Define per-agent policies in TOML

Specify which files, directories, and commands each agent is allowed to access. Use pattern matching with wildcards and recursive rules. Deny rules always take precedence. Set resource limits (memory, CPU, PIDs) per agent.

[agents.claude-code]
allow = [
  "~/project/**",
  "/tmp/**"
]
deny = [
  "~/.ssh/**",
  "~/.aws/**",
  "~/.config/gcloud/**"
]

[agents.claude-code.resources]
memory = "4G"
cpu = "200%"
pids = 512
02

Launch agents via Guardian Launcher

Use guardian-launch to start each agent inside an isolated Linux cgroup. The launcher creates a dedicated cgroup, applies your TOML policy, sets resource limits, and attaches eBPF enforcement — all automatically. The cgroup gives each agent an unspoofable kernel-enforced identity. Fallback to TGID/process-name tracking is available for agents you can't launch directly.

# Default flow: cgroup-based isolation
$ guardian-launch --agent claude-code \
    -- claude

[INFO] Created cgroup: guardian/claude-code
[INFO] Cgroup identity: unspoofable
[INFO] Policy applied, LSM hooks active
[OK] Agent running in enforced cgroup

# Manage agents with guardian-ctl
$ guardian-ctl list
AGENT         CGROUP                  STATUS
claude-code   guardian/claude-code    enforced
aider         guardian/aider          enforced
03

Monitor, approve, and audit

View real-time events on the web dashboard. When an agent in its cgroup requests access to a sensitive resource, approve or deny interactively with risk scoring and time-limited grants. Every decision is logged for audit. Get alerts in Slack when sensitive resources are accessed.

[DENY]  claude-code → ~/.ssh/id_rsa
[ALLOW] claude-code → ~/project/src/
[REQ]   aider → ~/.env (risk: HIGH)
        Awaiting approval... (120s timeout)
[APPROVED] aider → ~/.env (60s grant)
[EXPIRED] aider → ~/.env (grant ended)

Why Guardian Shell?

AI agents are transforming how you write code. But they run with your full privileges — access to SSH keys, cloud credentials, and every file on your machine. Traditional sandboxes and file permissions can't distinguish between you and your agent.

Guardian Shell changes this with cgroup-based isolation. Each agent is launched into its own Linux cgroup via Guardian Launcher — giving it an unspoofable kernel-enforced identity. No PID guessing. No process name spoofing. Just real, hardware-backed isolation with per-agent policies and resource limits.

 

Guardian Shell doesn't just monitor your agents. It isolates them in cgroups, enforces policies at the kernel, and lets you approve sensitive access in real time — so you have the confidence to let agents work at full speed.

Founder’s note

We built Guardian Shell because we hit the same wall every team using AI agents hits. We were running Claude Code, Cursor, and Aider in parallel — shipping faster than ever — until we realized these agents had access to our SSH keys, AWS credentials, and every secret on our machines. The existing solutions were either Kubernetes-only, monitor-only, or required modifying the agents themselves.

Guardian Shell was born from that gap. We wanted kernel-level enforcement that works on any Linux machine, with per-agent policies and interactive approvals — so you can let agents work fast while keeping your secrets safe.

Mission: Give every developer kernel-level control over their AI agents.

Vision: A world where AI agents are powerful and provably safe.

AN

Anand Narayan