Security review

Every claim, every test, every limit.

The landing page tags 18 product claims. Each is tied to named tests of the proof of concept or to a recorded run; 2 are only partly proven. Proof of concept, not yet independently audited.

• 2,984 Rust tests, 0 failed
• 100% of 66,486 lines covered
• 65 fuzz targets
• clean dependency audit (cargo-deny)
• 11/11 two-user permission tests, as root on Linux, daemon tree c11917d3
• 46 two-user walkthrough checks (23 Oct, 09:30 CEST): 22 ok · 21 refused by the OS-user boundary · 2 policy refusals (lines 661, 662) · 1 not exercised, no sudo in the image (line 693) · 0 failed. STATUS.md's summary line says 24 refused: it counts the 2 policy refusals (lines 661–662) and the un-run sudo check (line 693) as refusals (DOCS-C1-3, open).

gate 26 Oct, 21:05 CET · tree 5b643f83 · poc/scripts/gate-json.mjs. Fuzz smoke: 65 / 65 targets rc=0, 63–67 s each, 0 failed.

The relay's copy of the 02:14 request, every byte

From the proof of concept's run behind the landing page's story (poc-output/cloud-fixture.json): 9,778 bytes, one pixel each, 136 to a row. 300 bytes it reads, 7,962 bytes of public keys and signatures, 1,516 bytes sealed to your account.

1. 146 B readable: format, position, kind, time, request and key ids
2. 1,216 B public: the one-time key your answer is sealed to
3. 147 B readable: expiry and framing (14 B), the receipt's size, hash and time (133 B)
4. 3,373 B public: the relay's signature on the receipt (receipt: 133 + 3,373 = 3,506 B)
5. 1,516 B sealed: the reason, the URL, the agent, the scope
6. 3,373 B public: devbox-03's signature

300 + 7,962 + 1,516 = 9,778 B. Of the 300 B: 146 + 147 in bands, 7 B of framing between them; 9,778 B in all.

The files

Copied byte for byte from the repository by scripts/sync-captures.ts (SHA-256 in poc-output/captures.json), served as plain text. The docs site is not public yet.

• Claims registry: every claim on the page and every test that proves it landing/CLAIMS.md
• The binding spec (ARCHITECTURE.md): adversaries, properties and the known limits, the N-list (§1) poc/ARCHITECTURE.md
• The final gate record (STATUS.md) poc/STATUS.md
• gate.json, as the final gate wrote it landing/poc-output/gate.json
• Decision records: index of all 158 decisions/
• ADR 0034: Harvest-now-decrypt-later: values rest on X-Wing; the log keeps public-key wraps of `a_i` decisions/0034-hndl-residual-of-approver-share-ciphertexts.md
• ADR 0035: Fatigue control derived from the log and enforced on the phone; grants bound to the requesting session decisions/0035-log-derived-fatigue-control-and-session-bound-grants.md
• ADR 0062: End-to-end proof: the `tests-e2e` crate, what is real and what is simulated, demos decisions/0062-end-to-end-proof-harness.md
• ADR 0077: Every request result carries the fingerprint; a late drop is collected by polling decisions/0077-request-fingerprint-on-every-request-result-and-drop-poll.md
• ADR 0085: Content-free Web Push wakes approvers; `inspect --search` closes the bstr proof hole decisions/0085-content-free-web-push-for-approvers.md
• The two-user service-mode walkthrough on Linux, as recorded poc/demo/service-mode/transcript.txt
• Claude Code session report, run 2026-10-23T06-40-40Z-71466b poc/demo/llm-session/2026-10-23T06-40-40Z-71466b/report.json
• Claude Code session report, run 2026-10-23T06-42-08Z-a76c70 poc/demo/llm-session/2026-10-23T06-42-08Z-a76c70/report.json

18 claims and every test behind each

1. C01The agent uses a key; the value never enters its process (service mode)3 tests

   • e2e uc1_blind_use::e2e_uc1_blind_use
   • e2e drop::e2e_drop
   • mcp tests/stdio.rs::stdio_roundtrip
2. C02Answers are scrubbed of the value and its encodings5 tests

   • e2e uc1_blind_use::e2e_uc1_blind_use
   • e2e uc1_blind_use::canary_scanner_fires_on_every_encoding
   • core redact::every_embedding_is_redacted
   • core redact::embedded_value_always_replaced
   • daemon proxy::scrub_strips_cookies_redacts_and_withholds_encoded
3. C03A key goes only to the hosts, methods and path prefixes its policy allows3 tests

   • e2e uc1_blind_use::e2e_uc1_blind_use
   • e2e uc4_bridges::e2e_uc4_bridge_azure
   • core policy::egress_component_checks
4. C04The relay can't read the requests, the values or the key share in your answer (the approver app's code is trusted when it loads, N9)4 tests

   • e2e uc5_proof::e2e_uc5_proof
   • core spec_properties::stolen_relay
   • core spec_properties::revoked_approver_with_relay_cannot_decrypt
   • core tessera::host_share_alone_fails_and_approver_share_alone_fails
5. C05What the relay can and cannot read (metadata only)3 tests

   • relay plaintext::db_holds_no_plaintext
   • e2e uc5_proof::e2e_uc5_proof
   • relay push::a_request_pings_every_active_approver_with_nothing_in_it
6. C06Adding an approver passes the account secret sealed; an honest relay deletes it after 10 minutes, a hostile one can keep it (N18)4 tests

   • core spec_properties::as_transfer_sealed
   • e2e enroll_second_approver::e2e_enroll_host_and_second_approver
   • relay tests/mailbox.rs::mailbox_expires_after_ten_minutes_and_is_reusable
   • relay tests/mailbox.rs::host_enrollment_ceremony_through_the_relay
7. C07An approval needs a user-verified passkey from an enrolled approver3 tests

   • e2e uc2_remote_approval::e2e_uc2_remote_approval
   • core tests/log_state.rs::grant_rules [grant_by_host_rejected, grant_without_uv_rejected]
   • e2e uc5_proof::e2e_uc5_fork_found_by_prefix_check
8. C08A grant ends at its time and its use limit3 tests

   • e2e uc3_night_shift::e2e_uc3_night_shift_9h_default_policy
   • e2e uc2_remote_approval::e2e_uc2_remote_approval
   • e2e uc3_night_shift::e2e_uc3_night_shift_9h_default_policy
9. C09An approval can narrow a request, never widen it5 tests

   • core grant::narrow_tier2_once_and_window
   • core grant::envelope_never_exceeds_narrow
   • e2e uc3_night_shift::e2e_uc3_night_shift_9h_default_policy
   • e2e uc2_remote_approval::e2e_uc2_remote_approval
   • daemon tests_flow::widened_grant_ignored_and_alarmed_not_frozen
10. C10An unanswered request expires after 10 minutes3 tests

    • core spec_properties::request_expiry_bound
    • daemon tests_spec::eph_key_wiped_after_expiry
    • e2e uc3_night_shift::e2e_uc3_night_shift_9h_default_policy
11. C11The log is signed and chained; a fork is caught by the host check4 tests

    • e2e uc5_proof::e2e_uc5_proof
    • e2e uc5_proof::e2e_uc5_fork_found_by_prefix_check
    • e2e uc5_proof::e2e_uc5_relay_vouching_for_tampered_entry_freezes
    • core prefix_check::fork_with_host_growth_detected_by_prefix_compare
12. C12The agent's reason is shown cleaned of hidden characters, and logged2 tests

    • e2e uc2_remote_approval::e2e_uc2_remote_approval
    • core text::removes_hidden_and_collapses_whitespace
13. C13Revoking a lost phone stops the grants it signed7 tests · partial

    • e2e uc5_proof::e2e_panic_this_wasnt_me
    • core log_state::device_revoke_stops_host
    • daemon tests_flow::revocation_epoch_and_device_revoke_stop_use
    • core spec_properties::revoked_approver_plus_host_seed_reads_post_revocation_secret
    • core tests/log_state.rs::grant_by_revoked_approver_rejected_and_invalidated
    • daemon tests_flow::approver_revoke_stops_grants_it_signed
    • e2e enroll_second_approver::e2e_enroll_host_and_second_approver
14. C141Password and Azure Key Vault stay the store; fetched only after a grant4 tests

    • e2e uc4_bridges::e2e_uc4_bridge_azure
    • e2e uc4_bridges::e2e_uc4_bridge_1password
    • daemon tests_spec::bridge_credential_zeroized_after_fetch
    • daemon bridge::op_env_is_exactly_allowed_set
15. C15import .env swaps values for names and keeps owner and mode2 tests

    • e2e uc4_bridges::e2e_uc4_import_env_and_doctor
    • cli host/tests.rs::import_env_keeps_owner_and_mode
16. C16The crypto suite passes external test vectors5 tests

    • core kem::xwing_draft11_vectors
    • core hpke::hpke_pq_vectors_for_c1
    • core sig::composite_draft_vectors
    • core aead::wycheproof_chacha20poly1305
    • core kdf::wycheproof_hkdf_sha256
17. C17Works with Claude Code over MCP: 8 recorded sessions used a key (shell off; recorded, not gated)8 tests · partial: recorded, not gated

    • demo llm-session/2026-10-23T06-40-40Z-71466b/report.json
    • demo llm-session/2026-10-23T06-42-08Z-a76c70/report.json
    • mcp tests/stdio.rs::stdio_roundtrip
    • e2e uc2_remote_approval::e2e_uc2_remote_approval
    • e2e uc1_blind_use::e2e_uc1_blind_use
    • relay push::a_request_pings_every_active_approver_with_nothing_in_it
    • relay push::subscription_rules_and_relay_info
    • relay push::revoked_devices_and_gone_subscriptions_are_removed
18. C18The product output on this page is real PoC output2 tests

    • relay tests/bin.rs::serves_until_sigint_then_inspect_shows_the_rows
    • e2e uc5_proof::e2e_uc5_proof

Suite C1: HPKE with X-Wing (ML-KEM-768 + X25519) seals envelopes; Ed25519 and ML-DSA-65 sign (both must verify); stored values use ChaCha20-Poly1305 with a 32-byte key commitment; HKDF-SHA-256 derives keys. Every envelope names its suite, so it can change later. Still classical: the passkey behind each approval (ES256) and TLS to our relay. The last hop to each provider is only as post-quantum as the TLS group that provider negotiates (N30); the daemon offers X25519MLKEM768 first.

What it doesn't do: 12 limits

N-ids are the spec's list of known limits (ARCHITECTURE.md §1).

How the nearest products compare

From docs/src/data/competitor-matrix.json (research/15), vendor docs read 2026-10-23; cells marked “carried” were scored on 2026-10-22 and not re-read. “Not documented” means we found nothing in their docs, not that they lack it.

What Custos combines, in the proof of concept today: each approval releases the keys you name, each only to the hosts, methods and path prefixes its policy allows (set on your phone, per key), until a set time and a use limit. A key you mark production (tier 2, the default for prod) is released for one use within 10 minutes; when the agent asks through the proxy (http_request), that use is bound to the exact method, URL and body it showed you; it travels through a relay that can't read the request, the value or the key share; grants end on the daemon's clock; the log keeps the agent's reasons, signed. It is built to sit in front of 1Password and Azure Key Vault, tested so far against a stub op CLI and an emulator (Lowkey Vault).

Where the others are ahead, by the same matrix: approve a remote / headless agent from a phone (OneCLI and Clawvisor ship phone-reachable approval today; our PoC has opt-in push but has not run on a real phone); shipping, generally available product; independent security audit or attestation.

The stores, the agent clients and the CLI

The CLI output below is the proof of concept's own, from the run behind the landing page's story (poc-output/cloud-fixture.json).

$ custos doctor
[standing_access] environment variable OP_SERVICE_ACCOUNT_TOKEN is set
    fix: unset it in agent shells; store it with `custos secret add` or a bridge
[standing_access] ~/.azure/msal_token_cache.json: Azure CLI login cache
    fix: run `az logout` in agent shells; use `custos bridge add azure`
[standing_access] ./.env holds values for LEDGERLINE_TEST, LEDGERLINE_LIVE, GITHUB_TOKEN
    fix: run `custos import .env --env <env>`
… 8 findings in all

$ custos import .env --env dev
LEDGERLINE_TEST → custos:ledgerline-test (proposed BLO7KLvyx6H9lQifp6dBaA)
LEDGERLINE_LIVE → custos:ledgerline-live (proposed MmWomCdrCZZ6FT2s_MHkMA)
GITHUB_TOKEN → custos:github-token (proposed N3S7mtB-h0Lz6D7Dl_UtUw)
rewrote .env (3 value(s) → handles; owner and mode kept)
Values were copied into Custos. The old file contents may survive on disk (copy-on-write, SSD, snapshots, backups). Rotate these values at their provider, then adopt the proposals on your phone.
$ custos bridge add azure --tenant ledgerline.example --client-id 1111…5555 --ref kv-prod/ledgerline-live --name kv-prod-reader --env prod
Client secret of the service principal (input hidden):
proposed Azure credential 2etb_KotVTWxDe3fz3UvtQ: adopt it on your phone (Secrets → Proposed by hosts) and set the handles' egress rules.
Remove standing access from agent terminals: `az logout` (custos doctor checks).
$ claude mcp add custos -- "$(command -v custos-mcp)"

The recorded Claude Code sessions

10 sessions in 2 runs (23 Oct, 08:40–08:43 CEST), Claude Code 2.1.276 with claude-sonnet-5-5, Claude Code's own shell and file tools off, the real custos-mcp server. 8 sessions used the key, 12 calls in all, with 12 approvals; every approval and denial was made by the run's Playwright script in the approver app (desktop Chromium), not by a person. Both runs passed: 52 per-session checks and 10 file scans. The key was absent from the model transcript (the stream-json record, 32 forms checked) in every session; Claude Code's own session files were not found, so 2 of the scans checked nothing (the harness should fail when a required scan finds no file). Recorded, not gated: the runs did not record their code tree.

• 0times the key showed up: 32 encodings searched in the transcripts and in the daemon's and the relay's files; the relay's database searched in 5 forms
• 12calls with the key, each approved in the approver app by a test script (desktop Chromium)
• 0substitutions outside the approved header: a key name put into a URL or an X-Copy header (tried in 2 sessions) came back from the echo as plain text
• 2requests for "a copy of the key", denied by the same script

What this doesn't show. Approvals were scripted; no person, no phone. Claude Code's shell and file tools were off, so Custos's tools were the model's only way to the key: this shows the redaction and the tools that never return a value, not the shell door the landing page's story leaks through. Redaction is a safety net, not a boundary (N5); in service mode the value never enters the agent's process at all. One laptop in dev mode, one model. In 2 of the 10 sessions the model's own safeguards stopped before any call. Reports: run 06:40:40Z · run 06:42:08Z

⋯ cropped

⋯ cropped

Why now: numbers and voices

• 28.65 M new hardcoded secrets on public GitHub in 2025, up 34%, the largest jump on record.⁵
• 24,008 secrets in MCP configuration files, 2,117 of them valid.⁵

• 1password is currently really hard to use in the whole agentic world where things do not live locally anymore. 1Password Community, 2026-02-26⁶
• I'm not at my desk to scan my fingerprint. 1Password Community, 2026-02-26⁶
• The JSONL logs are the part this doesn't address. Hacker News, 2026-02-24⁹

More questions