Secure your AI agentsat the kernel level.

Launch AI agents inside isolated cgroups with Guardian Launcher. Enforce per-agent security policies at the Linux kernel level using eBPF, Landlock, seccomp, unspoofable identity, file access control, network enforcement, 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 four defense layers — Landlock, seccomp, eBPF, and cgroup isolation — with unspoofable identity and per-agent policies.

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.

Four-layer kernel enforcement

Cgroup agents are protected by Landlock (inode-level, symlink-immune file access), expanded seccomp (17 blocked syscalls), eBPF LSM hooks, and cgroup isolation. Symlink attacks, TOCTOU races, and privilege escalation are solved — not mitigated.

Per-agent security policies

Each cgroup-isolated agent gets its own TOML policy with allow, deny, and read_only rules. Claude Code can access your project directory while Aider is restricted to a different scope. Agents drop root privileges automatically after setup.

Interactive approval workflows

When an agent requests access to a sensitive resource, you get a real-time notification. Approve or deny via the CSRF-protected web dashboard or CLI with risk-based timeouts, grant accumulation limits, and weighted justification scoring.

Real-time dashboard, alerts, and anomaly detection

See every file access, command execution, and network connection in real time. Hourly anomaly detection flags rubber-stamping approvals and persistence attacks. Get alerts via Slack, email, or webhooks.

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 with O(1) agent lookup. No instrumentation or modification of agent code required. New agents get sensible default policies automatically. Deploys as a single binary.

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.

Linux security is fragmented. Guardian Shell unifies it.

File permissions, MAC, eBPF, cgroups, seccomp, Landlock — each solves one piece of the puzzle. Guardian Shell combines the best of all six into a single tool purpose-built for AI agents.

Traditional file permissions

chown + chmod + ACL

The original Unix security model. chown sets file ownership, chmod sets read/write/execute bits, and POSIX ACLs add per-user or per-group rules beyond the basic owner/group/other model. Every Linux system uses these by default.

“Necessary baseline, but invisible to AI agents. An agent running as your user inherits all your permissions — SSH keys, cloud credentials, everything.”

Strengths

  • Built into every Linux system — zero setup
  • Simple mental model: owner, group, others
  • ACLs extend granularity to specific users
  • Near-zero performance overhead

Limitations for AI agents

  • Cannot distinguish between you and your AI agent — both run as the same user
  • No awareness of processes or applications, only users
  • No network or command execution controls
  • Static rules — cannot adapt to runtime behavior
  • No audit trail of access attempts

How they stack up

Each mechanism covers part of the security surface. Guardian Shell combines eBPF enforcement, Landlock sandboxing, cgroup identity, seccomp filtering, and resource limits — four defense layers in a TOML config file.

Capabilitychmod / ACLSELinux / AppArmoreBPFcgroupsseccompLandlock
Guardian Shell
Per-agent policiesComplex
File path-level control
Symlink-immune enforcement
Command execution controlSyscall-levelPer-path
Network enforcementLimitedTCP only
Interactive approvalPossible
Runtime policy updatesReload required
Unspoofable identityLabelsWith cgroups
Resource limits
Anomaly detection
Audit trailWith auditdManual
Defense-in-depth layers1111114
Performance overhead~0%10-20%<3%~0%~0%~0%<3%
Setup complexityLowVery highHighMediumMediumMediumLow (TOML)
AI-agent aware

Stop stitching together six tools. Guardian Shell gives you Landlock sandboxing + eBPF enforcement + seccomp filtering + cgroup identity + resource limits + interactive approval + audit trail — in one binary.

Honest about today. Building for tomorrow.

No security tool is complete. We'd rather tell you what we can't do yet than let you find out the hard way. Here's where Guardian Shell stands — and where it's going.

What sets us apart

Kernel-enforced network blocking
TCP connections denied at the kernel via LSM socket_connect hooks. Deny rules always override allow rules — no race conditions, no userspace bypass.
Hardened against 25 attack vectors
Inode protection, exec hardening, fail-closed BPF maps with per-CPU overflow arrays, CSRF-protected dashboard, mandatory privilege dropping, and read_only file policies.
Behavioral anomaly detection
Hourly pattern analysis flags rubber-stamping approvals, high-volume agents, and persistence attack patterns. Security that watches the watchers.
Four-layer defense-in-depth
Cgroup agents get four defense layers: cgroup isolation, Landlock sandbox (inode-level, symlink-immune), expanded seccomp (17 blocked syscalls), and eBPF monitoring. Symlink and TOCTOU attacks are solved.

Known limitations

Linux-onlyRequires Linux 5.13+ for full Landlock protection, 5.7+ for eBPF-only mode. No macOS or Windows support.
Root required for daemon startupLoading eBPF programs needs root or CAP_BPF + CAP_PERFMON. Agents automatically drop privileges after setup — they never run as root.
Two-tier security modelCgroup agents (via Guardian Launcher) get full four-layer protection. Comm-based agents receive eBPF-only enforcement with known symlink and TOCTOU gaps.
UDP traffic not enforcedNetwork enforcement covers TCP connections only. UDP sendto() bypasses kernel filtering — DNS exfiltration over UDP remains a vector.
No DNS-based network policiesNetwork rules filter by port, not hostname. Agents could reach unintended IPs on allowed ports.
No container-native integration yetGuardian Shell runs on bare Linux today. Kubernetes admission controllers and OCI hooks are on the roadmap.

Coming next

IP/CIDR filtering & per-agent network isolationNext
Move beyond port-based rules to IP range filtering and per-agent network policies instead of global rules.
UDP enforcement & DNS inspectionNext
Extend kernel enforcement to UDP traffic and inspect DNS queries for hostname-based blocking.
Multi-party approval workflowsNext
Quorum-based approval requiring multiple sign-offs before agents access production credentials.
Kubernetes-native integrationFuture
Admission controllers and OCI hooks so Guardian Shell works inside container orchestration natively.
Hardware-backed attestationFuture
Verify agent binary integrity via IMA (Integrity Measurement Architecture). Tampered agents blocked before execution.

Want to shape what we build next? Talk to us about your security requirements.

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.

Anand Narayan

Anand Narayan