Your keys and your API

One key starts it. The port stays on your machine.

A fresh instance needs exactly one secret to be useful — an LLM provider key — and it listens on one port bound to loopback. Everything else here is the next key and the next call: where a second key goes so it does not widen what every agent can reach, every outside service the container can reach once you give it one, the token you deliberately do not set, and the handful of routes worth knowing before you learn the console.

Which key goes where — click a location

The blast radius is the point. Bundled agents share the hub .env. Every key you add there becomes reachable by every bundled agent you invoke — which is convenient on day one and too broad by week three. agent-env/<id>.env exists so a connector key can belong to one agent instead of all of them.

Every outside service this container can reach

Two defaults worth knowing before you add any of these. Notifications ship pointed at a file, not a network — DAL_COO_P2A_TRANSPORT=file writes to a local outbox, so an instance with no connectors still has somewhere to tell you things. And the switches above that read =0 or =1 — draft-only posting, dry-run code edits, email mutations — ship commented out in the template, which means the profile default applies rather than the value you see. If you want one of them guaranteed, uncomment it and set it yourself. The gate you can rely on without reading any of that: no key, no connector, and anything leaving the building still waits on Review.

Payments and live travel booking go further, and are deliberately not on this page. Both have real key blocks. Neither is a single credential you paste in: the payment path sits behind its own live-enable switch layered over amount ceilings, a currency allowlist, webhook verification, and an approval check before anything executes — and the travel skill draws its product boundary at research, leaving ticket purchase and merchant-of-record outside unless you deliberately turn a live connector on. Those blocks want real domain knowledge and caution to run, so the variables are not published here; they are documented in the kit beside the code that uses them — packages/payment/README.md and agents/saffron_agent/docs/providers.md.

Travel research, though, needs no new credential. Flight, hotel, and directions research all ride the search key you already set — they resolve through the same shared SerpAPI client as the rest of the kit. So the trip packet is reachable from the connector you configured for web search, and only live booking is a separate decision.

Two things about the door

What you can actually call — grouped by the spine

curl -fsS http://127.0.0.1:4040/api/status

curl -sS -X POST \
  http://127.0.0.1:4040/api/task \
  -H 'Content-Type: application/json' \
  -d '{"description":"…"}'

curl -fsS -X POST \
  http://127.0.0.1:4040/api/wake \
  -H 'Content-Type: application/json' \
  -d '{"max_items":10}'

curl -sS http://127.0.0.1:4040/api/review/pending

These are the Docker URLs. Every call above assumes the published loopback port, so if you changed DAL_COO_DOCKER_PORT, use yours. Command lists and version tags come from INSTALL.md; console surfaces from OPERATOR_GUIDE.md.

One secret in, one port out, and a token you never typed. That is the whole security posture a Principal needs to hold on day one — and the reason it stays true is placement, not promises: keys in a file read as environment, narrowed per agent when they get sensitive, absent from anything published, and never sitting in the tree an agent writes into. .env · .env.example · agent-env/<agent_id>.env · my-agents/<id>/.env · .dal-docker/ (generated token) Next: The disk — where those files live and what is mounted · Your agents — giving one of your own a key ← The kit that holds these keys