Keel

The execution layer under AI agents.

Agents decide what to do. Keel decides what is allowed to become real — filesystem access, subprocesses, network egress, and credentials — without trusting the model’s story about what it “needs.”

┌─────────────────────────────┐
│  Agent runtime              │  Grok · Codex · Zene · custom hosts
│  (plans, tools, prompts)    │
└──────────────┬──────────────┘
               │ policy · spawn · SpaceFs · events
┌──────────────▼──────────────┐
│  Keel                       │  Policy · Enforce · Record · Lifecycle
│  Secure execution space     │
└─────────────────────────────┘

Named after a ship’s keel: the structural spine underneath. The agent rides on top; Keel keeps real host access from tearing things apart.

One line: Keel is the landing gate under the agent — bind reach first, execute under policy, audit what actually happened.

What Keel does

Four pillars

What Keel is not

• Not a chat UI or planning framework (not a replacement for Grok / Codex / your agent host).
• Not a full desktop app.
• Soft checks alone are not VM-grade isolation — use kernel backends when you need stronger FS/net enforcement. SpaceFs is a soft host-side API (TOCTOU still exists); hosts should keep O_NOFOLLOW and path re-checks where they already have them.

Status

v0.0.15 on crates.io as eero-keel-* (owner EeroEternal).

Windows Job Objects + AppContainer (path grants + CreateProcess); baseline denies; SpaceFs-first; hash-chain audit; Unix Landlock/Seatbelt/seccomp as before.

See CHANGELOG.md, design, and host integration.

Install

Requires Rust 1.93+.

CLI

cargo install eero-keel-cli
keel info

Library

[dependencies]
eero-keel-core = "0.0.15"

Rust imports use short crate names (keel_core, keel_policy, …), not the crates.io package prefix:

use keel_core::{
    profile_workspace, ProcessGuardBackend, Space, SpawnRequest, StdioMode,
};

crates.io package names

Notes:

• Plain names keel / keel-core / keel-cli / keel-enforce are taken by unrelated crates.
• Historical keel-exec-* is not maintained from this repo.
• Source directories remain crates/keel-*; use package names with cargo -p eero-keel-cli.

Quick start

From source

cargo build -p eero-keel-cli --release
./target/release/keel info

cargo run -p eero-keel-cli -- policy --profile workspace
cargo run -p eero-keel-cli -- check --profile workspace --write ./README.md
cargo run -p eero-keel-cli -- run --profile workspace -- echo hello

Library sketch

use std::sync::Arc;
use std::time::Duration;
use keel_core::{
    profile_workspace, MemorySink, ProcessGuardBackend, Space, SpaceOptions, SpawnRequest,
};

# async fn demo() -> anyhow::Result<()> {
let policy = profile_workspace(std::env::current_dir()?.as_path())?;
let sink = Arc::new(MemorySink::new());
let backend = Arc::new(ProcessGuardBackend::new());
let space = Space::create_with_sink(
    policy,
    backend,
    SpaceOptions {
        persist_events: false,
        memory_events: true,
        ..Default::default()
    },
    Some(sink),
)
.await?;

// Files under policy (prefer SpaceFs over raw std::fs + check_fs alone):
// space.fs().write("foo/bar.txt", b"ok").await?;

let exit = space
    .spawn(SpawnRequest::new("echo").args(["keel"]))
    .await?
    .wait_timeout(Duration::from_secs(5))
    .await?;
assert!(exit.success());

// Timeout + collect stdout/stderr:
// .wait_with_output_timeout(Duration::from_secs(30)).await?;

// MCP-style stdio:
// SpawnRequest::new("server").stdin(StdioMode::Piped).stdout(StdioMode::Piped)

space.destroy().await?;
# Ok(())
# }

Typical host flow:

open Space (bind policy)
  → space.fs() for file tools  /  space.spawn() for commands
  → wait with timeout or CancellationToken
  → destroy  →  keep audit log if needed

Backends

Windows notes: Jobs kill process trees on cancel/timeout/Drop. AppContainer profiles + icacls grants enforce OS-level FS reach for children when windows_appcontainer is enabled (default). Capability set is minimal (internetClient when network is not DenyAll).

# Kernel FS on children; events under ~/.keel/spaces/
cargo run -p eero-keel-cli -- run --backend local-process --profile workspace -- echo hello

# Egress allowlist (CONNECT proxy + ProxyOnly where supported)
cargo run -p eero-keel-cli -- check-egress evil.com --allow-host api.x.ai:443
cargo run -p eero-keel-cli -- run --backend local-process --allow-host example.com:80 -- \
  curl -sI http://example.com/

# Worktree + credential injection
cargo run -p eero-keel-cli -- run --worktree --cred API_TOKEN=env:MY_TOKEN -- echo ok

On Linux, true read-deny for nested paths often needs bubblewrap (bwrap on PATH or KEEL_BWRAP).

Policy profiles

Custom profiles: builder API, JSON/TOML, or sandbox.toml (~/.keel/sandbox.toml and project .keel/sandbox.toml).

Links

• Repository: github.com/EeroEternal/keel
• Design · Integration · Testing · Changelog

License

Apache-2.0