Skip to content
bashd
Execution control for production agents
GitHub Open console

NEW Exact-command approvals in v0.1

Let agents use
real tools.
Keep the keys.

The server-side execution and approval layer for AI agents. Inspect every action, enforce allow / ask / deny, and keep provider credentials outside the agent process.

Open source · self-hosted · fail closed by default

AGENT / CONTROL PLANELIVE SIGNAL 01
INSPECTDECIDEAPPROVEREPLAY + EXECUTE
Human decision receivedAPPROVED · NOT EXECUTED
99audited service tools
0provider keys in agents
3policy outcomes
use per approval

01The complete execution path

One tool call. Every boundary visible.

Follow a real command from agent intent to a redacted audit result. Switch the policy outcome to see where execution changes.

Server facts win.The agent cannot claim that a write is read-only.

bashd / governed command
$bashd slack -- chat post --channel C123 --text "shipped"

01INSPECT slack.chat.post

02FACT side_effect=true

03POLICY production-write → ask

04BIND version + tool + account selector + argv

05APPROVE apr_91QD · authorized, not executed

06OBSERVE bashd approval apr_91QD --wait

07REPLAY bashd slack --approval-id apr_91QD -- …

08RESULT original stdout / stderr / exit code

01

InspectSide effect found

02

DecidePolicy says ask

03

ApproveGrant only

04

ReplayAI executes explicitly

OUTCOMEExplicit replay · original output returned

02Why a control plane

Agent autonomy without invisible risk.

The failure modes are predictable. The boundary should be, too.

01

Credentials leak into prompts

Provider tokens inside the agent process can be logged, exfiltrated, or reused outside policy.

KEY_EXPOSURE
02

Writes happen without review

A plausible plan is not authorization to send, refund, publish, delete, or deploy.

UNREVIEWED_WRITE
03

Retries repeat side effects

Network ambiguity turns a harmless retry into a duplicate message, charge, or mutation.

DUPLICATE_EFFECT
04

Audit starts after the incident

Client-side logs cannot prove what was inspected, approved, changed, or actually executed.

MISSING_FACTS

03How it works

A narrow waist for every agent action.

One execution protocol between autonomous code and the systems your company depends on.

01

Inspect

bashd recomputes the tool action and side-effect facts on the server. Unknown paths fail closed.

action=slack.chat.post\nside_effect=true
02

Decide

Rules match action, tool, agent, environment, and account. First match resolves to allow, ask, or deny.

production-write\nmode=ask · priority=10
03

Approve

Ask binds a one-time grant to the exact command hash. Approving authorizes only; it never executes the tool.

approval=apr_91QD\nexecution=none
04

Replay & audit

The agent observes the decision and explicitly replays the same command with --approval-id. A matching replay consumes the grant and returns the tool output unchanged.

replay=explicit\noutput=passthrough

04Capabilities

Control that lives where execution happens.

Not another prompt wrapper. A server-enforced boundary with a human path for consequential work.

POLICY ENGINE

Rules agents cannot talk around.

Match action, tool, account, environment, and agent identity. Keep reads moving while writes follow the boundary you set.

01*.listALLOW

02slack.chat.postASK

03stripe.refunds.*DENY

EXACT COMMAND REVIEW

Approve the command, not the intention.

The digest binds version, tool, literal account selector, and ordered argv. Shell quoting and the approval id are excluded.

COMMAND HASH7H2K:9F01:AC44
WRITE-ONLY SECRETS

Keys stay behind the boundary.

Connections reveal field names and health—not credential values. Secrets resolve only for an allowed execution.

SLACK_TOKEN ••••••••••••STATUS CONFIGURED
SINGLE-USE GRANT

Approval does not mean execution.

Decision queries only observe. One matching explicit replay consumes the grant; repeated or edited commands fail closed.

approveobservereplay1 EXECUTION
COMPLETE AUDIT TRAIL

Policy, decision, replay, and result—in one timeline.

Investigate with server facts instead of reconstructing intent from scattered client logs.

12:42:08.114submittedagent/deployer

12:42:08.128policy · askrule/prod-write

12:43:17.904approvedreviewer/local

12:43:18.588replayed · succeeded684 ms

05Integrations

One policy surface across every tool.

Agents keep a single CLI contract. Providers stay behind a credential-safe, source-audited catalog.

AGENT RUNTIMES

01Codex
02Claude Code
03Custom agent
04CI / worker
CONTROL LAYER

bashd

inspect
decide
execute

SERVER-SIDE

AUDITED SERVICES

SL

Slack

01
ST

Stripe

02
HU

HubSpot

03
IN

Intercom

04
SH

Shopify

05
DI

Discord

06
CA

Calendly

07
CH

Chargebee

08
MI

Mixpanel

09
RE

Resend

10
PL

Plaid

11
ME

Mercury

12
99 services in the current audited allowlist

Unknown or host-unsafe tools remain unavailable until reviewed.

Browse connections

06 Security boundary

Trust the boundary.
Know its limits.

bashd is explicit about what it enforces today—and what v0.1 does not pretend to solve.

Read the source
01

Credentials stay server-side

The agent selects a named account. It never receives the underlying provider token.

02

Unknown means denied

Unrecognized tools, failed inspection, and internal policy errors stop before execution.

03

Outputs are bounded and redacted

Stored stdout and stderr have hard limits; injected credential values are removed before persistence.

04

Executions do not silently retry

A matching replay consumes its approval before the provider call. If the process loses the response, bashd reports an explicit unknown outcome instead of replaying it.

v0.1 boundary noticeNo authentication · local JSON state · loopback by default. Use on a trusted development network while hosted identity, RBAC, Postgres, worker isolation, and egress policy are built.

Four teams, one boundary

Policies that match the work.

Start from the consequence of an action, not a generic permission role.

01

Support agent

READ PATHLook up a ticketALLOW

WRITE PATHRefund a paymentASK

02

Sales agent

READ PATHRead CRM contextALLOW

WRITE PATHSend an outbound emailASK

03

Ops agent

READ PATHQuery monitoringALLOW

WRITE PATHMutate productionDENY

04

Coding agent

READ PATHInspect provider stateALLOW

WRITE PATHPublish or deleteASK

07Run locally

Reach the approval boundary in minutes.

The built-in gate probe exercises the entire flow without credentials or an external network request.

  1. 01
    Build the control plane

    Install Go and Node dependencies, then build the two local binaries.

  2. 02
    Start API + console

    Run both foreground services. The API binds to loopback by default.

  3. 03
    Submit a governed call

    The probe binds the exact command to an approval and returns its URL.

  4. 04
    Approve, observe, replay

    Approve grants permission only. The agent observes it, then explicitly replays the exact command.

~/bashd
# trigger the safe approval probe
BASHD_API_URL=http://127.0.0.1:8080 \
  ./bin/bashd gate-probe -- probe send --note hello

APPROVAL_REQUIRED approval_id=apr_91QD
next: bashd approval apr_91QD --wait

# observe only; this never executes the tool
./bin/bashd approval apr_91QD --wait
APPROVED approval_id=apr_91QD
next: bashd gate-probe --approval-id apr_91QD -- probe send --note hello

# the agent explicitly replays the exact command
./bin/bashd gate-probe --approval-id apr_91QD -- \
  probe send --note hello
TOOL OUTPUT returned unchanged · stdout / stderr / exit code
Open local console

08FAQ

Before you put it in the path.

The short answers to the questions a security-minded engineering team should ask.

01Why not let the agent call providers directly?

Direct calls put long-lived credentials and enforcement inside the least trusted process. bashd keeps provider credentials on the server, recomputes the action and side-effect facts, then applies policy before anything runs.

02What exactly does an approval authorize?

One explicit replay of the exact command digest: version, tool, literal account selector, and ordered argv. Approve records the grant but executes nothing; the agent must observe the decision and replay with --approval-id.

03Can an approval execute the same side effect twice?

No. The first matching explicit replay atomically consumes the approval before execution. A repeated replay is rejected. If only the HTTP response is lost, querying the approval recovers the stored result without running again; a server crash during the provider request is reported as an unknown outcome.

04Which tools are available?

The current hosted catalog exposes 99 source-audited AnyCLI services. Unknown tools and services with unsafe host access fail closed until their boundary has been reviewed.

05Is v0.1 ready for an untrusted public network?

No. v0.1 intentionally has no authentication and uses a local JSON store. It binds to loopback by default and is designed to validate the complete control flow on a trusted development network.

06Can I self-host it?

Yes. The Go control plane and Next.js console run locally, credentials remain in your environment, and the gate-probe tool lets you exercise the full approval path without touching an external service.

THE SAFE PATH TO ACTION

Your agents are ready
to do real work.
Are your boundaries?

Run the full inspect → decide → approve → observe → explicit replay path locally. No provider credentials required.

Start with gate-probe Explore the console