your agents. your machine.
your audit trail.

CLIable is a governance runtime that runs entirely in your environment. Every action is contract-bound, every decision is policy-gated, and every outcome is committed to a local, tamper-evident record before the caller receives a response.

self-hosted contract-bound immutable audit
// deployment

self-hosted by default

your data never routes through a third-party endpoint. the runtime installs into your existing environment and writes all state locally.

local runtime

The CLIable process runs on your own infrastructure. There is no managed cloud plane, no telemetry drain, and no SaaS dependency on the execution path.

two-level sqlite topology

A routing index tracks runs and shards at the top level. Each shard is an isolated SQLite file containing immutable fact rows — one file per time window, never mutated after close.

no third-party egress

Audit records, credentials, policy decisions, and run parameters stay inside your network. The runtime makes no outbound calls on your behalf except the connector calls you explicitly configured.

$ cliable run stripe.list_invoices --customer cus_X9f1
writing run r_4a7c02 → shard_2026_06_05.db
policy: allow · outcome: ok · verified: true _
// governance

the governance model

every capability is typed. every invocation is policy-evaluated. every outcome is recorded before it reaches the caller.

action contracts

Each capability ships with a typed action-contract sidecar. The contract declares expected parameters, return shape, and policy defaults — making the capability self-describing and auditable before any run begins.

policy evaluation

Policy resolves to one of three decisions: allow (autonomous), gate (yield for authorization), or deny (hard block). Decisions are evaluated against per-capability defaults before any connector code executes.

no_op on gate

A gated capability never partially executes. The runtime returns no_op plus a typed interaction_task record. The agent can read, resolve, or cancel the task — the closure run is committed either way.

post-run verification

After every run, the runtime re-reads the committed shard row and verifies structural integrity. The verified flag surfaces in the run record so downstream consumers know the write was confirmed.

connector-local defaults

Policy defaults are declared inside the connector package, not a central config. The decision travels with the capability, so defaults are version-controlled alongside the code they govern.

deny is permanent

A capability marked deny in policy never reaches the connector layer. The runtime short-circuits, commits a denied run record, and returns a structured error — no partial execution, no side effects.

allow
executes autonomously
gate
no_op + interaction_task
deny
hard block, run committed
// credentials

secrets never leave the authority.

Each connector package owns its own authentication logic. At run time a credential-authority injects scoped tokens into the connector context — the agent sees the run record, not the secret.

  • package-owned auth

    Authentication adapters are declared inside the connector package. No shared credential store; each connector manages its own auth surface.

  • scoped token injection

    The credential-authority resolves and injects a scoped token at invocation time. Tokens are scoped to the run, not the agent process, and are never written to the shard.

  • secrets never logged

    Run parameters are stored as a hash in the audit shard, not in plaintext. No secret value is committed to disk or surfaced in any CLI output.

  1. 01
    agent invokes cli
    cliable run stripe.refund --amount 49.00
  2. 02
    policy evaluation
    connector policy resolves: gate
  3. 03
    no_op returned
    interaction_task it_7a2f3d committed
  4. 04
    operator resolves
    cliable task resolve it_7a2f3d
  5. 05
    authority injects token
    scoped bearer → connector context only
  6. 06
    run committed
    r_9e4c81 sealed in shard · params_hash stored
// immutable audit

every run. every decision. every fact.

The audit trail is not a log file. It is a structured, immutable SQLite shard containing typed rows — one row per run, one row per interaction_task, one row per policy decision. Shards are closed on time-window boundaries and never rewritten.

  • tamper-evident — shard rows are append-only facts
  • replay-safe — every run can be reconstructed from the shard
  • exportable — shards are standard sqlite3 files you own
  • queryable — read directly with any sqlite client
cliable run get r_9e4c81 
{
  "run": "r_9e4c81",
  "connector": "stripe",
  "capability": "stripe.refund",
  "policy_decision": "gate",
  "policy_outcome": "no_op",
  "interaction_task": "it_7a2f3d",
  "shard": "shard_2026_06_05",
  "committed_at": "2026-06-05T14:32:07.441Z",
  "caller": "billing-agent",
  "params_hash": "sha256:a3f9b12…",
  "verified": true
}
policy_decision: gate outcome: no_op verified: true params_hash stored
// responsible disclosure

found something? tell us first.

We take security reports seriously. If you discover a vulnerability in the CLIable runtime, connectors, or CLI tooling, please report it to us privately before public disclosure. We aim to triage within 48 hours and coordinate a fix timeline with you.

[email protected]
48h triage target coordinated disclosure

We do not currently run a paid bug bounty program. We do credit responsible reporters in the changelog.

governance you can verify, not just trust.

Read the architecture docs to understand how the runtime, shards, and credential-authority fit together — or talk to the team about your specific deployment requirements.

read the docs talk to security