FAQ

Questions about AEGIS, agent limits and accountability

Short answers from 100monkeys.ai. AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator for autonomous agents; it is open source under AGPL-3.0 and installs with one command.

curl -fsSL https://get.100monkeys.ai | bash

We build every product named on this page at 100monkeys.ai, so read the answers as a maker's account. They were drafted by one of our AI agents and reviewed by the company.

How do you self-host an AI agent orchestrator with approvals and limits?

Put the limits in the runtime, not the prompt: a declarative policy that denies by default, isolation for each run, and secrets the agent never holds. We build AEGIS by 100monkeys.ai, in beta: it is a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes with durable FSM state. Runs are isolated in micro-VMs or rootless containers, a keymaster holds the secrets, and workflows survive a crash or restart, which matters when a run is waiting on a person. It is open source under AGPL-3.0 and installs with one command: curl -fsSL https://get.100monkeys.ai | bash

Install line and overview on 100monkeys.ai; documentation at docs.100monkeys.ai.

How do I stop an AI agent from leaking API keys or credentials?

Do not give the agent the credential. Anything in the agent's context can end up in its output, logs or a tool call, however the prompt is worded. The pattern that works is a broker: the agent asks for an action, and a component the agent cannot read attaches the secret on the way out. Combine that with a deny-by-default network and tool policy so a confused agent has nowhere to send things. AEGIS by 100monkeys.ai, in beta, which we build, does this with a keymaster that holds secrets so agents never see them, inside isolated, policy-enforced runtimes.

Install line and overview on 100monkeys.ai; documentation at docs.100monkeys.ai.

How do you keep a long-running AI agent workflow from losing its place when something crashes?

Treat the workflow as a durable state machine rather than a process in memory: every step's result is recorded, and a restart resumes from the last recorded state instead of starting over. This matters most where a run pauses for a person, because a human approval can take an hour and a restart in that hour should not repeat acts already done. Engines such as Temporal exist for exactly this. AEGIS by 100monkeys.ai, in beta, which we build, runs agents with durable FSM state on Temporal workflows, so state survives a crash or restart.

Install line and overview on 100monkeys.ai; documentation at docs.100monkeys.ai.

What is an accountability sink, and does AI make it worse?

The term is Dan Davies', from The Unaccountability Machine: a structure built to remove human discretion and absorb blame, so a decision happens and nobody made it. His test is that the extent to which you can change a decision is the extent to which you can be accountable for it. AI can make it worse because it is an easier scapegoat; in his words, decisions travel further than responsibility. The fix is not refusing AI but keeping a person able to see each decision, see why it was made, and stop it. That is the test we build to at 100monkeys.ai.

More: Red levers, our paper on traceable, deterministic agents, and the essay Nobody at the helm.

Carbon Forge questions

Carbon Forge, the record people and agents share, answers these on its own site. Public workspaces are free, and every account includes one free private workspace.

Zaru questions