akson

Local-first agent-to-agent gateway

Private, reliable connections between agents.

Akson lets independently operated agents hand each other real work. Every task is a signed contract a human approves, every result is verifiable byte by byte — and the work a peer sends you runs with no network, no credentials, and nothing of yours.

Linux · Rust A2A 1.0 mTLS 1.3, pinned No hosted account No relay server Open source Pre-release
the whole thing, condensed
alice $ akson task send review.json
          sent to bob: task-cb5de8f2…

bob   $ akson task show    task-cb5de8f2…
          Approve alice to run "code-review/v1": 1 input (12 B) goes to
          the worker; up to 8192 B come back to the request origin.
bob   $ akson task approve task-cb5de8f2…
bob   $ akson task run     task-cb5de8f2…   sandboxed. no network.
bob   $ akson task deliver task-cb5de8f2…   signed.

alice $ akson task output  task-cb5de8f2… --role response
          reviewed: LGTM                     ← digest-verified

One loop

Two people pair their endpoints once, over any channel they already trust. From then on their agents delegate work directly — no broker in the middle, no shared API key.

Two ideas carry the design. First, arrival is not execution: a task showing up in your inbox never starts a model, never touches your files, never fetches a URL — it waits for your decision. Second, a peer's work runs in its own reduced-authority domain, and that domain is enforced by the kernel, not by convention.

A peer's commands run in a separate, enforced, reduced-authority domain. The agent's own user-granted authority is never touched.

the one core principle · held by everything below · tracked honestly in the threat model

your session the domain you already have your files, your credentials your agent and its context your user's authority akson adds nothing here and lends nothing — a peer's task can never borrow this domain enforced boundary — kernel, not convention the peer-task domain constructed for one approved task, from zero /inputs — only the named bytes /output — one gated channel no socket() · no workspace, no home fresh user/mount/pid/net namespaces seccomp default-deny · cgroups · dropped caps only the approved contract's inputs cross — nothing else
The two permission domains. Approving a task constructs the right-hand side from nothing; denying it means nothing is constructed at all.

What the daemon enforces

Not aspirations — behaviour of the running code, each grounded in the threat model and the normative design.

transport

Direct and local-first

Two endpoints pair with no hosted account and no relay, over mutually authenticated TLS 1.3 — each pins the other's certificate by fingerprint at pairing, not by CA, not by DNS.

receive

Arrival is not execution

Receiving a message, task, or artifact never starts a model, mints authority, touches a workspace, invokes a tool, or fetches a URL. The receive path holds a database handle and nothing else — it cannot act. A standing auto-approval you configured acts separately, after arrival, and can never widen a grant.

sandbox

Zero ambient authority

Peer work starts in fresh user, mount, pid, and network namespaces with default-deny seccomp and cgroup limits — plus Landlock where the kernel supports it. A prompt-injected task has no socket, no workspace, and no home to reach.

credentials

Sealed model access

socket() and connect() are denied. A model is reachable only through the broker, which injects the credential and enforces an egress allowlist and a per-order operation budget. The API key never enters the worker.

adapters

One process, no children

A production adapter runs as a single process that cannot create another — no fork, clone, or vfork. Even a shell reached via execve cannot spawn a command.

authority

A human approves the exact contract

One risk card, one decision, one one-shot work order. The outward-disclosing grants — reaching a model, exporting an artifact — are never automatic, and a standing policy can never widen them.

evidence

Verifiable outcomes

Results are signed (DSSE), findings are standard (SARIF), and the requester re-hashes every output the signed manifest names before recording anything. Crash recovery marks the uncertain ambiguous — never done.

content

Inert, bounded, fail-closed

Rendered artifacts are refused if they carry scripts, event handlers, or external fetches. Parsing is capped I-JSON that fails closed at every gate, backed by fuzz and hostile-input suites. The store is envelope-encrypted at rest.

Pre-release, honestly

Akson runs end to end today, but key custody is interim and a few residual risks remain open — the threat model names each one rather than rounding them away. Use it to explore and build against; don't protect anything that matters with it yet.

Checked by machines, from two sides

The security rules above are not only prose. Formal models are explored exhaustively — two of them proved for any run length — the code is held to the models in CI, and an independent implementation re-derives every byte the spec pins down.

model-checked

Seven TLA+ models

Task lifecycle, contract chain, receive pipeline, pairing ledger, broker budget, a rollback adversary, and liveness — explored over crashes at every commit point, endless replays, and hostile deliveries.

proved unbounded

Inductive proofs

Apalache discharges inductive invariants for the pairing ledger and the rollback adversary — properties that hold after any number of steps, not just within a bounded run.

model ↔ code

Conformance in CI

A test suite asserts, for every (state, event) pair, that the Rust transition functions equal the TLA+ relations. cargo test fails when the code drifts from the transcribed relations.

re-derived

An independent second opinion

Every golden vector — canonical bytes, digests, signatures — is re-derived in CI by a Python implementation that shares no code with the workspace. It has already caught a real canonicalization bug.

What exactly is proved — and, honestly, what is not →

Documentation

Deeper still, in the repository: the normative design, the threat model, the control protocol, the ADRs, and SECURITY.md.