Agent Security Stack — bondage + envchain-xtra + nono | Learn to Prompt

⌨️">

architecture

agent-stack security

analytics-privacy privacy

vendor-independence stack

claude-to-codex-plugins stack

visual-inspection stack

sandbox-profiles stack

agents

claude-code cloud

opencode cloud

codex cloud

pi cloud

local inference

llama.cpp local

ollama local

qwen3-tts mlx local

ds4 mbp m5-128 local

dgx-spark local

evaluation

benchmarks eval

llm hardware calculator calc

workflow

claude-md

mcp-servers

prompting

hooks

context

llm-wiki 慄

tools

bondage ↗

envchain-xtra ↗

nono ↗

learn to bitcoin ↗

Reality check: this stack is still experimental. It is a practical local hardening pattern, not a finished security product. If you want the strongest isolation boundary for an agent, a dedicated VM is still better than a host-local CLI sandbox.

The point of the stack is not ceremony. It is to narrow trust around secrets, dependency drift, and host access.

1. Why this stack exists

By default, most agent setups inherit too much trust from the surrounding shell session. That means too many secrets, too much filesystem visibility, and too much confidence in whatever dependency tree happens to answer on PATH.

The actual reasons for hardening this are not abstract:

you do not want agents running loose with live API keys and other secrets

you cannot assume the dependency tree behind a familiar command is clean or stable

you do not want broad ambient access to shell state, config files, and local environment by default

The old pattern for hardening CLI agents was to stuff everything into shell wrappers: secret injection, Touch ID gates, sandbox flags, target resolution, and sometimes even binary verification. That can work, but it makes your shell script the real security boundary.

The cleaner model is to separate the jobs:

shell name → bondage → [envchain-xtra] → [nono] → exact pinned tool<br>convenience launch policy secret release sandbox actual agent

That split matters because each layer addresses a different failure mode: bondage decides what exact artifact chain is allowed to launch, envchain-xtra decides when secrets are released, and nono decides what the launched process can actually touch.

It also deliberately leans on the OS where the OS is stronger than userland glue: macOS code-signing identity can be used as part of artifact approval, and Keychain remains the underlying secret store rather than re-implementing secret storage in the launcher.

If you want the implementation detail rather than the overview, start with agentbondage.org, then read the Getting Started and Trust Model docs.

2. Philosophy

This stack is opinionated. The philosophy is not “wrap everything in enough cleverness and call it secure.” It is to reduce ambient trust and make the risky decisions explicit.

Prefer explicit trust over ambient trust. Exact paths, exact hashes, explicit profiles, explicit secret release.

Use the OS for what the OS is good at. Keychain for secret storage, signing identity where available, kernel sandboxing for enforcement.

Keep layers narrow. Launch policy is not secret storage. Secret storage is not sandbox policy. Shell convenience is not a trust boundary.

Assume upgrades are security events. If a binary or package tree changed, re-approve it deliberately.

Make escape hatches obvious. If there is a no-sandbox path, it should be explicit and ugly, not a quiet profile drift.

In short: less magic, less ambient authority, more deliberate boundaries.

3. Layer responsibilities

LayerWhat it should doWhat it should not do

Shell wrapper<br>Short names, prompt shaping, convenience aliases<br>Decide which binary is trusted or which sandbox policy applies

bondage<br>Verify exact targets, interpreters, package trees, and choose the launch policy<br>Store secrets or enforce filesystem policy by itself

envchain-xtra<br>Release secrets from Keychain-backed namespaces to one process tree<br>Own the whole launch-policy story

nono<br>Enforce filesystem, process, and network restrictions<br>Resolve which launch artifact chain is trusted

4. Practical patterns

In practical terms: your secrets are already being shipped to frontier labs as tokens they can decode. Don't panic — you can hand this article to your coding agent and ask it to set the stack up for you.

The stack guide should explain the worldview, not carry every operational nuance inline. The sharp edges are better captured as repeatable patterns.

vendor-independence — keep instructions, plugins, tool access, and security layers portable across clients instead of baking the workflow into one vendor.

claude-to-codex-plugins — take a Claude-first plugin and make Codex first-class without forking the real workflow, using llm-wiki as the case study.

visual-inspection — use accessibility trees first, then a narrow localhost screenshot service when pixels actually matter.

sandbox-profiles — keep normal coding tight, make broader access explicit, and make true...