AI Agent Assembly Documentation

Quick links to each component, its current version, and its license. Every version badge reads the latest published version live — core and Go from GitHub, Python from PyPI, Node from npm’s rc dist-tag — so they stay current with no manual updates. The project is in release candidate (v0.0.1-rc).

AI Agent Assembly is a governance layer for AI agents. It sits between your agents and the outside world and does three things:

• Enforces policy — decides, before each governed action runs, whether an agent is allowed to call a tool, reach a domain, or spend more budget.
• Tracks cost — meters token and dollar spend per team and blocks agents that exceed their budget.
• Intercepts unsafe actions — the sidecar proxy denies a routed call before it leaves the machine, the SDK advises in-process, and the Linux eBPF sensor detects activity without returning a verdict. Each is deployed on its own and covers only what it is on the path of.

Governance applies per agent, on the paths you wire up — you do not have to rewrite your agent’s logic, but each agent has to be launched through a governed path (an SDK your code initializes, or the sidecar proxy). An agent started outside those paths is not governed. See Known limitations for what is measured, unmeasured, and unsupported today.

Who this documentation is for

This site is for teams, security engineers, and operators evaluating or running AI Agent Assembly for production adoption.

If you are a developer who wants to contribute or integrate at the code level, see the open-source documentation instead.

Find what you need

Pick the page that matches what you are trying to do.

SDKs & components

This hub is the central entry point for AI Agent Assembly documentation. To instrument your agents, you install the SDK for your language — each one ships its own documentation site. Use the table below to go to the SDK that matches your codebase (Python, Node/TypeScript, or Go), or to Arena, the cross-framework governance trial ground.

Every module’s docs are aggregated into this hub under a stable subpath (/core/, /python-sdk/, /node-sdk/, /go-sdk/, /arena/), so you can read and search all of them from one place. The standalone, per-version sites remain available for release-specific (mike / Docusaurus / Hugo channel) browsing.

Runnable examples

Prefer learning by running code? The examples repo collects small, framework-specific Agent Assembly examples for Python, Node.js/TypeScript, Go, policy enforcement, approvals, audit, trace, and runtime workflows. Clone it and run an example end to end to see governance in action before instrumenting your own agents.

The interception mechanisms

Governance is assembled from independently-deployable interception mechanisms, and a deployment runs whichever subset it installs. They are not a fallback chain and not a ranking: each reaches a different claim level, and a mechanism you do not deploy is reported as absent rather than picked up by another. The numbering below is presentational and implies no order of precedence:

1. SDK layer (in-process) — the language SDK wraps your agent’s framework tool calls and raises on a deny before the wrapped call runs. Fastest path, but advisory: it requires you to adopt the SDK and call its initializer, a non-cooperating process simply never calls it, and it does not intercept raw HTTP, subprocess spawns, or file access. Treat it as defense-in-depth, not the gate.
2. Sidecar proxy (aa-proxy) — intercepts outbound HTTP/1.1 that is routed to it, using per-host certificates minted from a local root CA, so it can govern agents that do not use the SDK. No agent code changes, but the process must honour HTTP_PROXY/HTTPS_PROXY and trust the CA (on macOS the install is attempted at proxy start via security add-trusted-cert, which requires admin authorization — macOS prompts, and a refusal fails proxy startup; on Linux run sudo aasm proxy install-ca; Windows is unsupported). On MitM’d hosts, HTTP/2, gRPC, and WebSocket cannot be inspected — on other hosts they are tunnelled uninspected.
3. eBPF sensor (aa-ebpf) — kernel hooks that watch OpenSSL and process syscalls. Observe-only: it reports what it sees and is consulted in no allow/deny decision, so its claim level is Observed and Detected — never prevention. It does not block, and it is not a mechanism the others fall back to. Linux only (the file-I/O kprobes are x86_64-only), and it degrades rather than failing closed if it cannot attach.

Each mechanism reports to the gateway, which evaluates policy and tracks per-team budgets. Coverage is the union of the layers you deploy, bounded by each layer’s own precondition — see Known limitations.

These interception points describe where a decision is applied; they sit inside the Boundary layer of the broader five-layer defense model, which describes what is protected. Same system, two views.

Last reviewed: 2026-06-27 — AI Agent Assembly Team

Last updated: 2026-09-07 by AI Agent Assembly Team