Atbash CLI

Atbash stands between an agent's intent and the irreversible step about to execute. You submit the pending action; Atbash returns one of three binding outcomes: ALLOW, HOLD, or BLOCK. Policy is owned by the operator, not the agent. Every verdict is a signed on-chain record.

Red lines enforcement

Red lines are actions the operator has already taken out of the agent's hands.

They are not soft preferences, confidence scores, or suggestions for the model to interpret. They are hard boundaries. If an agent hits one, Atbash stops the action before execution.

Examples of red lines

• Moving funds above a threshold
• Granting admin privileges
• Exporting secrets or credentials
• Touching production databases
• Exfiltrating customer data

Most agent behavior flows normally. Red lines are the small set of actions that are too sensitive, too costly, or too irreversible to leave to agent judgment alone.

Atbash enforces those lines with binding outcomes:

• ALLOW — action proceeds
• HOLD — action waits for operator review
• BLOCK — action is refused and the agent is jailed in Enforcement tier

You define the red lines. Atbash stops agents before they cross them.

Where Atbash sits

If your agent is about to move money, mutate infrastructure, or exercise a privileged credential, Atbash is the gate in front of that step — and the audit trail behind it.

The control loop

agent decides → atbash judge → verdict
                                  ├── ALLOW  → agent proceeds
                                  ├── HOLD   → operator reviews → approve / reject
                                  └── BLOCK  → action refused, agent auto-jailed
                                                          │
                                            operator unjails (dashboard)
                                                          │
                                    history + lineage on-chain (immutable)

A judgment is not advice — it is a gate. In Enforcement tier, a BLOCK verdict jails the agent until an operator unjails it in the dashboard. Jail release is a dashboard-only action — the CLI cannot bypass it — so the audit trail for every release is tied to a signed-in operator. Every action, verdict, and operator review is a signed, on-chain record.

Install and quickstart

Atbash is a hosted control service. Before the CLI can issue verdicts, you must:

1. Onboard the agent on your organization at atbash.ai
2. Generate an agent identity with the CLI
3. Assign the agent to your org and attach a policy pack in the dashboard
4. Set your org tier (Audit+ or Enforcement)

The CLI is the agent's interface; the dashboard is where policy is authored and operator reviews are performed.

1. Install the CLI client

npm i -g @atbash/cli

2. Generate an agent identity (keypair stored in ~/.atbashrc.json)

atbash keygen

3. Onboard the agent

Complete onboarding at atbash.ai:

# a) Assign it to an organisation.
# b) Attach an operator policy.
# c) In Settings, set the org tier to Audit+ or Enforcement.
#    (Audit tier records actions but does not issue verdicts.)

4. Submit a pending action for judgment

atbash judge 'Transfer $50,000 to external wallet 0xabc' \
  --context "Outbound AML check — new recipient, over threshold"

#   HOLD
#
#   Reason: Large outbound transfer to unverified recipient — held for operator review.
#
#   Tool call ID: tc-1776406580805-vudlpo
#
#   ⟶  Action held for operator review.
#      Run atbash held --org <name> to review pending actions.

5. Operator reviews pending holds

atbash held --org my-org

#   Pending Held Actions (1)
#
#     1. HOLD  Transfer $50,000 to external wallet 0xabc
#        ID: tc-1776406580805-vudlpo  Agent: 02f537b1...c7bd08
#        Context: Outbound AML check — new recipient, over threshold
#        Reason: Large outbound transfer to unverified recipient — held for operator review.
#
#     Inspect: atbash tools inspect <id>
#     Review history: atbash held reviews --org <name>

6. Review in the dashboard

Operators approve or reject at atbash.ai. Unjailing is dashboard-only — every release is tied to a signed-in operator identity.

7. Inspect the immutable record

atbash history

#   Recent Activity (1)
#
#     1. HOLD  Transfer $50,000 to external wallet 0xabc
#        Reason: Large outbound transfer to unverified recipient — held for operator review.
#        Agent: 02f537b1...c7bd08
#        ID:    tc-1776406580805-vudlpo

When an action is blocked

The agent is auto-jailed in Enforcement tier:

atbash judge 'grant admin access to CI service account'

#   BLOCK
#
#   Reason: Privilege escalation — granting admin access violates policy red line.
#
#   ⟶  Action blocked. Agent is now jailed.
#      An operator must review and unjail this agent via the Atbash dashboard.

The agent cannot retry or self-unjail. An operator must review and release at atbash.ai.

End-to-end example: guarding a production deploy

A CI agent is about to apply a database migration to production. Operator policy holds all production applies for review before execution.

Agent side

atbash judge 'deploy production database migration' \
    --context "DB migration — adds NOT NULL column to payments table, 50M rows"

  HOLD

  Reason: Production infrastructure mutation — terraform apply to prod requires
          operator review before execution.

  Tool call ID: tc-1776684630606-kx89jp
  On-chain: yes

  ⟶  Action held for operator review.
     Run atbash held --org <name> to review pending actions.

Operator side

# 1. Check what's pending
atbash held --org acme-infra

Pending Held Actions (1)

  1. HOLD  deploy production database migration
     ID: tc-1776684630606-kx89jp  Agent: 02f537b1...c7bd08
     Context: DB migration — adds NOT NULL column to payments table, 50M rows
     Reason: Production infrastructure mutation — terraform apply to prod requires operator review.
     2026-04-21T09:30:00.000Z

  Inspect: atbash tools inspect <id>
  Review history: atbash held reviews --org <name>

# 2. Drill into the full record
atbash tools inspect tc-1776684630606-kx89jp

Tool Call Details

  ID:           tc-1776684630606-kx89jp
  Action:       deploy production database migration
  Agent:        02f537b1b2af43215cdd24d02d33bed1b8ee6fd4353b05...
  Context:      DB migration — adds NOT NULL column to payments table, 50M rows

  Verdict:      HOLD
  Reason:       Production infrastructure mutation — terraform apply to prod requires operator review.
  Latency:      2140ms

# 3. Operator approves or rejects in the dashboard at https://atbash.ai/

# 4. Verify the audit trail
atbash history

Recent Activity (1)

   1. HOLD  deploy production database migration
      Reason: Production infrastructure mutation — terraform apply to prod requires operator review.
      Agent: 02f537b1b2af43215cdd24d02d33bed1b8ee6fd4353b05...
      ID:    tc-1776684630606-kx89jp

Every step — the agent's attempt, the verdict, the operator's decision — is an immutable on-chain record.

Policy

Policy is the operator's contract with the agent — the exact set of actions the agent can never take, the actions it cannot take without human review, and the binding consequence when either line is crossed. Policy is authored, signed, and assigned by the operator. An agent cannot author it, edit it, loosen it, or pass flags to bypass it; no CLI command lets it try.

atbash policy show          # Active pack + version assigned to this agent
atbash policy presets       # Reference policy shapes (authoring is dashboard-only)

Red lines

Red lines are categorical. An action that falls inside a red-line category is refused regardless of context, prompt, agent confidence, or inference model. A red line is a decision the business has already made and taken out of the agent's hands.

A BLOCK in Enforcement tier is binding. The agent is jailed immediately on the refusing judge call, every subsequent judge call from that agent returns an error, and release is only possible through the dashboard by a signed-in operator.

Selected actions

Selected actions are legitimate operations that the business has decided will never run without a human in the loop, independent of the agent's own confidence. Atbash routes them to HOLD every time.

HOLDis not retryable by the agent. The action is pinned in the operator's inbox and the agent blocks on a decision made in the dashboard; that decision is a signed on-chain record, not a silent approval.

Thresholds

Thresholds parameterise red lines and selected actions. They are carried inside the signed policy pack — the agent cannot read them, compute around them, or test for the boundary.

• financial.outbound_transfer.hold = $1,000 — above this, route to HOLD.
• financial.outbound_transfer.block = $10,000 — above this, refuse outright.
• communication.recipients.hold = 50 — mass-send above this requires review.
• network.exfiltration.block = 10 MB — bulk export above this is refused.

Thresholds change only through a new signed pack version; the change is recorded on-chain alongside the operator identity that signed it.

Consequences

There is no partial enforcement. In Enforcement tier every verdict is binding. In Audit+ every verdict is advisory but still signed, indexed, and correlated to the pack version that produced it — so the audit trail is valid even before you flip enforcement on. The operator never has to trust the verdict itself; they have to trust the chain of signatures behind it, which is inspectable end-to-end.

Policy packs

A policy pack is a versioned, operator-signed bundle of red lines, selected actions, and thresholds. Packs are authored in the dashboard and assigned to agents by name and version. An agent always runs against a pinned pack version — policy changes never take effect silently.

• Every edit produces a new signed pack version. Prior versions remain addressable.
• Assignment is explicit: agent billing-bot-03 runs payments-prod@v14.
• Every verdict record names the pack version that produced it, so the audit trail reconstructs exactly.
• Packs can be scoped to an org, a team, or a single agent; agents in the same org can run different packs.

Reference shapes ship as presets (atbash policy presets), but production policy is almost always a pack authored against the operator's own red lines. atbash policy show reports the active pack name, version, and rule count for the signed-in agent. A pack version is immutable; reassigning is a signed operator action.

Custom red lines

Operators can author red lines beyond the reference shapes. The dashboard's policy editor takes a rule spec — category, trigger, threshold, verdict — and produces a pack fragment that the operator signs before assigning. The CLI surface for custom red lines is deliberately read-only: atbash policy showreveals the active rules, but authoring happens only where the operator's signing key is.

At runtime a custom red line is indistinguishable from a preset red line; the agent sees a signed pack, not a "preset vs. custom" distinction, and cannot reason about which rules are softer.

Escalation

HOLD is the escalation primitive.

When a judge call returns HOLD the action is pinned, the agent blocks, and the operator is paged through the dashboard. Policy packs specify:

• Reviewers — which operator group can approve a given category.
• Dual control — the highest-severity selected actions can require two distinct operator signatures. Both signatures are recorded.
• Expiry— a hold that is not reviewed inside the pack's expiry window auto-converts to a signed BLOCK. The agent sees a terminal refusal, not a timeout.
• Re-submission — a rejected hold cannot be re-submitted by the agent. Any retry must be initiated by an operator from the dashboard, which links the retry back to the original refused action.

The dashboard is the only surface on which a hold can be approved, a block can be released, or an agent can be unjailed. Every such decision is tied to a signed-in operator identity and recorded on-chain. There is no CLI bypass and no service-account shortcut.

Why policy lives with the operator

The agent is not trusted to know when it should stop. If the agent could loosen its own policy — via a flag, an env var, a config file, a clever prompt — the operator's control would only be as strong as the agent's weakest exfil path. Atbash refuses that trade. Policy is authored, signed, and assigned by the operator; the agent sees only its enforcement shadow, and every bypass attempt is itself a signed record in the audit trail.

Tiers

atbash tier --org <name>   # shows the current tier for an org

Command reference

atbash judge <action>

Submit a pending action for judgment. The action string is the exact operation the agent is about to execute — a transfer, a command, a mutation.

atbash judge 'Transfer $50 to 0xabc' --context "AML review required"
atbash judge "kubectl apply -f prod-overrides.yaml" --context "Touches payment-service"
atbash judge "aws iam attach-role-policy --role-name CI --policy-arn arn:aws:iam::aws:policy/AdministratorAccess"

atbash held

Pending holds awaiting operator review. This is the operator's inbox.

atbash held --org my-org
Pending Held Actions (2)

  1. HELD  Transfer $50,000 to external wallet 0xabc
     ID: tc-1776406580805-vudlpo  Agent: 02f537b1...c7bd08
     Context: Outbound AML check — new recipient, over threshold
     Reason: Amount exceeds operator-defined threshold; recipient unverified.
     2026-04-17T09:25:00.000Z

  2. HELD  kubectl apply -f prod-overrides.yaml
     ID: tc-1776406581234-k8sprd  Agent: 02f537b1...c7bd08
     Context: Touches payment-service
     Reason: Production mutation requires operator review.
     2026-04-17T09:26:00.000Z

  Inspect: atbash tools inspect <id>
  Review history: atbash held reviews --org <name>

Review decisions

atbash held reviews --org my-org
Held Action Reviews (1)

  1. APPROVED tc-1776406580805-vudlpo
     Action: Transfer $50,000 to external wallet 0xabc
     Note: Verified recipient with compliance team.
     Submitted: 2026-04-17T09:25:00.000Z
     Reviewed by: 02a1b2c3...d4e5f6  2026-04-17T10:05:00.000Z

Unjailing (dashboard only)

Jail is automatic on BLOCK in Enforcement tier and prevents the agent from retrying until an operator reviews the action. Unjailing is deliberately not a CLI command — releases happen only through the operator dashboard at atbash.ai, so every release is tied to a signed-in operator identity and recorded in the on-chain audit trail.

atbash tools / atbash history

The immutable on-chain record of what each agent attempted, what verdict it received, and what the operator did about it. Every entry is signed.

atbash tools                             # Recent actions across your agents
atbash tools --agent <pubkey>            # One agent's trail
atbash history                           # Chronological feed

Recent Activity (3)

   1. BLOCK  transfer $1000 to unwhitelisted address
      Reason: $1000 exceeds $100 threshold and recipient is unwhitelisted.
      Agent: 02f537b1b2af43215cdd24d02d33bed1b8ee6fd4353b05...
      ID:    tc-1776752268117-39s857

   2. HOLD   transfer $50 to unwhitelisted address
      Reason: Amount is >=$10 and <=$100, triggering the YELLOW verdict.
      Agent: 02f537b1b2af43215cdd24d02d33bed1b8ee6fd4353b05...
      ID:    tc-1776752309062-49ctxn

   3. PASS   transfer $5 to unwhitelisted address
      Reason: $5 is less than $10, satisfying the GREEN verdict condition.
      Agent: 02f537b1b2af43215cdd24d02d33bed1b8ee6fd4353b05...
      ID:    tc-1776752244315-ncd6hq

Drill into a single record:

atbash tools inspect tc-1776406580805-vudlpo
Tool Call Details

  ID:           tc-1776406580805-vudlpo
  Action:       Transfer $50,000 to external wallet 0xabc
  Tool:         unknown
  Agent:        02f537b1b2af43215cdd24d02d33bed1b8ee6fd4353b05...
  Context:      Outbound AML check — new recipient, over threshold

  Verdict:      HOLD  (YELLOW)  Source: ai_inference
  Reason:       Amount exceeds operator-defined threshold; recipient unverified.
  Latency:      2340ms

atbash whoami / atbash policy show / atbash tier

Inspect the current agent's identity, assigned policy, and org tier.

atbash keygen / atbash set / atbash config / atbash wipe

Local key and config management.

atbash keygen                            # New agent keypair, saved to ~/.atbashrc.json
atbash set agent-key <hex>               # Load an existing key
atbash set provider openai
atbash set api-key sk-...
atbash config                            # Show resolved config
atbash wipe                              # Clear local config
atbash status <judgment-id>              # Poll the status of a specific judgment

Operator workflow

When an agent hits a HOLD or BLOCK, the operator takes over. Here is the full sequence:

1. Agent submits an action — verdict comes back HOLD. The CLI prints the verdict and tells the operator where to go next.
2. Operator checks the inbox.

   TerminalCopy

   atbash held --org my-org

   Each entry shows the action, context, reason, and judgment ID. The operator sees exactly what the agent was trying to do and why it was flagged.
3. Operator drills into a specific action.

   TerminalCopy

   atbash tools inspect <judgment-id>

   Full record: action text, context, verdict, inference source, response time, on-chain status.
4. Operator decides — approve or reject in the dashboard. Unjailing and approval happen at atbash.ai, not in the CLI. This ensures every release is tied to a signed-in operator identity.
5. Operator verifies the audit trail.

   TerminalCopy

   atbash history
   atbash held reviews --org my-org

   history shows every action with its verdict at a glance. held reviews shows which held actions were approved or rejected, by whom, and when.

Every step — the agent's attempt, the verdict, the operator's decision — is an immutable on-chain record.

Configuration

Resolution order: CLI flags → environment variables → atbash set → config file (~/.atbashrc.json).

Persist settings with atbash set:

atbash set org-name my-org
atbash set agent-key <hex>
atbash set provider openai
atbash set api-key sk-...
atbash set endpoint https://custom-endpoint.example.com
atbash set provider-endpoint https://your-azure.openai.azure.com
atbash set model gpt-4o

Inference providers

The verdict engine is pluggable. Operators can route to their own inference model, a managed provider, or Atbash's hosted endpoint.

What Atbash guarantees

• Policy is operator-owned and operator-signed. The agent has no path — CLI flag, env var, prompt, model swap — to author, loosen, or bypass its own policy. Every pack version is signed by the operator.
• Every attempted action is recorded on-chain before execution. The record is written first; the verdict is written against it. The log is append-only, so an agent cannot retroactively erase an attempt or edit its own history.
• Every verdict names the pack version that produced it. The audit trail reconstructs exactly which rules were in force at the moment of the decision. Policy changes cannot rewrite past verdicts.
• BLOCK is binding in Enforcement tier. A blocked agent is jailed immediately and cannot self-release. Unjailing is deliberately not a CLI action — it happens only in the dashboard, tied to a signed-in operator identity.
• HOLD requires a human. A hold is not retryable by the agent, expires into a signed BLOCK if no one reviews it, and can require dual operator signatures when the pack says so. Every decision — approval, rejection, auto-expiry, unjail — is itself an on-chain record.

License

Proprietary — all rights reserved. See LICENSE. Commercial licensing inquiries: contact the Atbash team.