Steps
Connect
Review
Boundary
Deploy
After Deploy the wizard shows a Last Step panel with your agent keys and a one-command setup. The agent stays registered either way — you can come back to the setup later.
Step 1: Connect
Connect tells the wizard where your agent runs so it can scan its tools and capabilities. Choose the method that matches your setup:
Native integration
The wizard connects directly to your running local runtime (OpenClaw, Hermes, or an MCP config file) and scans its tool list automatically. No URL needed — click the button and it discovers everything.
API / MCP / SDK
Provide an endpoint or list the actions your agent takes. The wizard scans the declared surface and seeds the boundary from it. SDK mode shows a snippet to copy into your agent.
After scanning, the wizard shows the detected tool count, capability categories, and confidence level. If other agents are found on the same machine, you can queue them for onboarding too.
New agent vs. existing agent
- New agent — the wizard generates a keypair at Deploy. The private key is shown once and must be saved.
- Existing agent — you record the intent here; the private key is entered at Deploy (not carried through the flow). The dashboard derives the public key from it at signing time.
Step 2: Review
Review shows the scan findings and asks you to pick the workflow this agent owns — the scope of what it is responsible for and which tools it may use.
Pick a preset workflow
Presets like Repo & PR maintenance or Web research & paper synthesis come with a pre-filled name, mandate, purpose, and a focused tool selection. Each card shows how many of your scanned tools are in scope.
Create your own workflow
Describe the workflow in your own words. Atbash drafts the mandate (what it is responsible for — the judge reads this at enforcement time) and a one-line purpose (recorded on-chain), switches on the scanned tools the job needs, and lists any it needs that your agent does not have yet, with the steps to connect and scan them. Everything else starts blocked. The same description field is how you set up without scanning.
Use Fill it in with AI to generate the mandate, purpose and tool suggestions, or Focus on tools relevant to this mandate to auto-narrow the tool list.
Step 3: Boundary
The Boundary step turns the scan into an enforcement policy. It shows modeled exposure and lets you review and adjust every rule before approving.
Exposure model
- Modeled residual exposure — risk score before and after applying the boundary (e.g. 100 → 13).
- Automatic decisions — share of tool calls resolved without human review.
- Human-intervention share — held actions that reach a human approver.
Rules & policy sources
- Workflow authority rules — in-scope rules for the chosen workflow, each with BLOCK / HOLD / ALLOW and a severity level.
- Outside-workflow coverage — detected capabilities outside the workflow scope, all blocked by default.
- Org policy / custom rules / PDF import — optional additional sources that layer on top.
Review the rule list and adjust any BLOCK / HOLD / ALLOW decisions before clicking Approve boundary →. You can preview the agent certificate at this stage.
Step 4: Deploy
Deploy registers the agent on-chain with the approved boundary. This is where the private key is entered for existing agents.
What happens at Deploy
- Accountability — confirm the agent owner / workspace (your org name) and an optional escalation email for held actions.
- Existing agent key — if you chose existing agent, enter your private key here. The dashboard derives the public key and signs the registration transaction; the key is not stored.
- Deployment integrity — the system checks plan limits and certificate evidence, then signs everything in one atomic transaction. All or nothing.
- New agent key — generated and shown once after deploy. Download the key file before closing.
After Deploy: one command does the rest
After registration the dashboard shows a Last Step panel with your agent keys and a setup command. Run it on the machine your agent runs on — it handles everything in one step.
npx --yes @atbash/cli@latest setup \
--runtime <your-runtime> \
--org-name "<your-org-name>" \
--key <your-private-key> \
--host https://atbash.aiThe dashboard pre-fills this command with your detected runtime and keys — copy it directly from the Auto tab in the Last step panel. <your-runtime> is openclaw, hermes, or mcp for file-based runtimes; one of the SDK values for code-based ones.
What the command does
- Always places your key file at
~/.config/atbash/guard-client-key(0600). New agent: uses the dashboard-generated key. Existing agent: takes your private key, derives the public key, writes both. - For file-based runtimes (OpenClaw, Hermes, MCP): also installs the plugin and merges its config automatically — existing settings and other plugins are left untouched.
- For code-based runtimes (LangChain, LangGraph, AutoGen, Eliza): places the key only — plugin setup requires a code change in your app, which the command cannot make for you.
- Previews all changes and waits for your confirmation before writing anything. Every file it touches is backed up first.
Shell history: passing --key inline puts the private key in your shell history. Clear it afterwards: history -c (bash) or Clear-History (PowerShell). The CLI also reminds you of this on every run.
Private key safety: treat the agent private key like a production credential. Store it in a secret manager, never commit it to git, and rotate/revoke immediately if exposure is suspected.
Skipped setup or want to configure manually?
If you clicked I'll do this later in the dashboard, or if your plugin wasn't detected in the scan, you can follow the plugin docs to place the key, install, and configure everything by hand.
Full plugin setup guide →