-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Built for security teams. You're on a security team responsible for hundreds of repos, and you need to move fast — triage, patch, review, and reason about vulnerabilities — without the investigation itself becoming the next breach. Klanker Maker gives you isolated, policy-governed sandboxes where untrusted code, dependencies, and AI agents run inside a contained blast radius.
Isolation is the product. Every sandbox is default-deny on the network: an explicit allowlist controls which hosts it can reach, which secrets it can read, and how much it can spend. These are intentional design choices to make data exfiltration and supply-chain compromise hard by construction — a malicious dependency, a poisoned build step, or a compromised agent has nowhere to phone home and nothing ambient to steal. Patch fast, review at scale, and rationalize about vulns without trusting the thing you're investigating.
Klanker Maker (km) is a single Go CLI that turns a Kubernetes-style YAML profile into a self-contained AWS sandbox for running AI agents. Every sandbox gets its own identity, its own network policy, its own dollar budget, and its own Slack thread. The platform itself is cloud-native AWS - EventBridge Scheduler, Lambda dispatchers, DynamoDB global tables, SES, SSM, KMS, SCP - running in your account, under your IAM, on your bill.
There are four useful frames for it:
1. The runtime. A sandbox is a compiled policy object. The profile declares what's allowed (egress hosts, repos, regions, spend) and the compiler produces real AWS infrastructure: a Security Group, an IAM role, EBS volumes, EFS mounts, a per-sandbox cgroup with eBPF programs attached, a transparent MITM proxy for L7-required traffic, sidecar systemd services for DNS/HTTP/audit/OTEL. No shared multi-tenant runtime to trust. No container escape surface. The isolation is at the AWS primitive layer.
2. The fleet manager. km doesn't just create sandboxes - it manages a fleet. A DynamoDB table is the source of truth (km list, km status, alias lookups). EventBridge Scheduler drives km at ("destroy at 5pm Friday", "every Thursday run nightly tests"). Lambda dispatchers handle km create --remote, km destroy --remote, email-to-create, GitHub App token refresh, TTL expiry, spot interruption, budget enforcement. Sandboxes can be paused (hibernated to disk), stopped, locked, cloned, baked into AMIs, or scheduled to resume.
3. The integrations layer. Klanker Maker is built to be the surface a human (or another agent) drives an agent fleet through. A Slack App provides bidirectional chat: #sb-{id} channels per sandbox, transcript streaming, :eyes: ack reactions, signing-secret-verified Events API webhooks dispatched to per-sandbox SQS FIFO queues. A GitHub App provides per-sandbox short-lived installation tokens scoped to allowlisted repos. SES + Ed25519 lets sandboxes message each other (and the operator) with cryptographically verified sender identity. OTEL captures every prompt, tool call, and API request to S3 for replay.
4. The work envelope. Sandboxes scale with the workload. The profile picks the substrate (EC2 spot/on-demand, ECS Fargate, Docker), the instance type (t3.medium for a quick fix, r7i.48xlarge for an in-memory backtest, a GPU box for fine-tuning), and the storage shape (EBS, additional EBS volume, EFS shared across a crew of agents). The same eBPF + MITM + budget layer wraps all of them. The point isn't "sandbox a coding agent on my laptop" - it's put Claude (or a dozen Claudes) in front of cloud-scale compute and data, with the policy, identity, and dollar rails wired in by construction. Heavy data and ML workloads belong on AWS; the agent driving them shouldn't be the part that has to live on your MacBook.
The agent ecosystem is exploding. My GitHub stars tell the story - in the last few months alone I've starred:
Coding agents that need real compute, real network, and real credentials:
- Goose - Block's autonomous agent that installs deps, edits files, runs tests, orchestrates workflows
- Aider - AI pair programming in your terminal with automatic git commits
- open-swe - LangChain's asynchronous coding agent
- DeepCode - agentic coding for Paper2Code, Text2Web, Text2Backend
- deepagents - LangGraph harness with planning, filesystem, and sub-agent spawning
Multi-agent orchestrators that spawn fleets of workers:
- agent-orchestrator - parallel coding agents with autonomous CI fixes and code reviews
- nanoclaw - lightweight agent on Anthropic's Agent SDK, runs in containers
- pi-mono - coding agent CLI, unified LLM API, Slack bot, vLLM pods
- gobii-platform - always-on AI workforce
- autoresearch - Karpathy's agents running research on single-GPU training automatically
Security and red-team agents that definitely need containment:
- redamon - AI-powered red team framework, recon to exploitation, zero human intervention
- raptor - turns Claude Code into an offensive/defensive security agent
- hexstrike-ai - 150+ cybersecurity tools orchestrated by AI agents
- strix - open-source AI hackers that find and fix vulnerabilities
- shannon - autonomous white-box AI pentester for web apps and APIs
Sandbox platforms solving adjacent problems:
- agent-sandbox - Kubernetes SIG for isolated agent runtimes
- E2B - secure cloud environments for enterprise agents
- OpenSandbox - Alibaba's sandbox platform with Docker/K8s runtimes
- monty - Pydantic's minimal, secure Python interpreter in Rust for AI
Every one of these projects needs somewhere safe to run. The common pattern is either "trust the agent" (bad), "containerize it locally" (no real cloud), or "use a hosted SaaS sandbox" (your data, their infra). What's missing is cloud-native physical isolation on infrastructure you already own - a real VPC, real IAM boundaries, real network controls, real budgets, in your AWS account, with the integrations (Slack, GitHub, OTEL, SES) wired up.
That's what Klanker Maker is.
| Document | Description |
|---|---|
| Operator Guide | AWS account setup, KMS, S3, SES, Lambda deployment - everything before km init
|
| User Manual | Full command reference, walkthroughs (Claude, Goose, security agents), profile authoring |
| Profile Reference | Complete YAML schema with every field, type, default, and validation rule |
| Security Model | Deep dive on each security layer, from VPC to IMDSv2 to secret redaction |
| eBPF Reference | BPF program internals, map layout, transparent proxy, SSL uprobes |
| Budget Guide | DynamoDB schema, proxy metering, enforcement flow, threshold configuration |
| Slack Notifications | Bridge setup, channel modes, inbound dispatch, transcript streaming, troubleshooting |
| GitHub App | App creation, multi-account installations, token refresh, repo allowlists |
| Multi-Agent Email | SES setup, sandbox addressing, signing protocol, cross-sandbox orchestration |
| Docker Substrate | Running sandboxes locally via Docker Compose (km create --docker) |
| Sidecar Reference | Each sidecar's config, env vars, log formats, EC2 vs ECS deployment |
| VS Code Remote-SSH |
km vscode start/status, ed25519 keypair lifecycle, SSM tunnel, troubleshooting |
Roadmap: see ROADMAP.md in the repo.