What nanny guarantees
When you run an agent under nanny, these three things are true:- It will not call a tool you did not allow.
- It will not take an action a rule refuses.
- Every verdict, allow and refuse alike, is written down.
ExecutionStopped event is emitted with the exact reason, and Nanny
exits non-zero.
Liability attaches to what an agent was allowed to do, not to how much it used.
Nobody is accountable for a token count; people are accountable when an agent
emails the wrong customer or moves money it should not have.
What nanny is not
Nanny enforces what you declared. It adds no intelligence: it never reads your prompts, interprets your agent’s reasoning, or decides anything for you. It evaluates the identity, arguments, labels, and ordering of actions, and nothing else.Who it is for
Nanny is for developers and teams running agents in production, or preparing to. It is a good fit if you:- Are building multi-agent systems where different agents have different roles and tool access
- Are running autonomous agents that call external tools, browse the web, or write to APIs
- Need to prove an agent could not have done something, not just that it did not
- Want a structured audit trail of every tool call and stop reason for every execution
- Are building with CrewAI, LangChain, or any Python or Rust agent framework
- Want enforcement that is not tied to any agent framework, use CrewAI, LangGraph, or any Python or Rust framework without lock-in
The multi-agent scenario
An outreach agent searches the web for context, then emails a prospect. Both actions are legitimate. Doing the second after the first is how an instruction hidden in a web page becomes an email you did not write. Nanny governs the ordering, not the content:no_send_after_read ships in that pack. It denies any external_effect call
once a reads_untrusted call has happened in the same run. Nanny never reads
the page, so it cannot be fooled by what the page says.
The rule names labels, not tools, which is why it works in your application
without being written for it. See Tool labels.
The nanny ecosystem
Nanny is designed to meet you where you are and grow with you. Nanny CLI: the enforcement entry point. Governs any agent process in any language as its parent process supervisor. Install it once as a system tool and usenanny run --serve from any project that has a nanny.toml with a [start] command configured.
#[nanny::tool], #[nanny::rule], and #[nanny::agent] for per-call enforcement and custom rules. See the Rust SDK guide.
Python SDK, the same model as decorators: @tool, @rule, @agent. Works with LangChain, CrewAI, or any Python agent framework. See Python SDK.
Rule packs, curated sets of rules installed with one command and pinned to a version. See Rule packs.
Nanny Cloud, durable signed audit trails, cost attribution across your fleet, and team access control. The runtime stays unchanged and works without it. See Connect to Nanny Cloud.
Open source
The Nanny runtime is fully open source under the Apache 2.0 licence. Source code, issues, and contributions live at github.com/nanny-run/nanny. Cloud is the managed layer above the OSS primitive, not a replacement for it.Next steps
Quickstart
Install nanny and run your first governed agent in under five minutes.
Installation
Install, upgrade, and uninstall on macOS, Linux, and Windows.
How it works
Understand the enforcement model and passthrough mode.
Limits
Learn how tool permission and rules are enforced.
nanny.toml reference
Full schema for the configuration file.
Rust SDK guide
Per-function governance with
#[nanny::tool], #[nanny::rule],
#[nanny::agent].Python SDK guide
Per-function governance with
@tool, @rule, @agent decorators. Works
with LangChain, CrewAI, and any Python agent framework.Governance server
Cross-process and cross-machine enforcement with one shared rule set and mTLS.