Klanker Maker (km)
An agent runtime on your own AWS account - declarative, eBPF-enforced, Slack-native, with hard budgets that actually stop runaway loops.
Klanker Maker compiles a YAML profile into a real AWS sandbox: a scoped IAM role, a kernel-level network policy, a MITM proxy that meters every Bedrock/Anthropic/OpenAI token, a Slack channel that talks back to the agent, and a dollar ceiling that suspends compute when the money runs out. The point is to take agentic work off your laptop and put it on AWS at the size the work actually needs - a t3.medium for a quick fix, an r7i.48xlarge against EFS-backed datasets for a multi-day data pipeline, a GPU box for a training loop, or a crew of Claudes coordinating across all of the above. Drive any of it from a CLI, an at schedule, an inbound email, or a Slack thread - same control plane, same guardrails.
📊 Open the narrated walk-through
A profile is the contract - declare what's allowed, get the infrastructure as the artifact:
spec:
network:
enforcement: both # eBPF connect4 + transparent MITM proxy
egress:
allowedDNSSuffixes: [.amazonaws.com, .anthropic.com, .github.com]
budget:
compute: { maxSpendUSD: 0.50 }
ai: { maxSpendUSD: 1.00 }
sourceAccess:
mode: allowlist
github:
allowedRepos: [my-org/api, my-org/infra]
allowedRefs: [main, "feature/*"]
cli:
notifySlackEnabled: true
notifySlackPerSandbox: true
notifySlackInboundEnabled: true # bidirectional chat
notifySlackTranscriptEnabled: true # per-turn streaming + JSONL upload
$ ./km create profiles/g1.yaml
$ ./km list --wide
$ ./km agent run g1 --prompt "investigate the OOM in api-server" --wait
$ ./km destroy g1 --yes
Table of Contents
What Klanker Maker Is
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.
