Let your agent work until 07:00.* Not a minute longer.

Its own, yes, and there is no key in it. The Custos daemon runs as its own OS user and adds the key to the outgoing HTTPS request; the value never enters the agent's process or output. As a safety net it scrubs every answer: the exact value, its base64, hex, URL and JSON forms, and any run of 12 or more of its characters. That scrub is accident prevention, not a boundary (N5).

On a laptop in dev mode, where the daemon runs as your own user, this guards against accidents, not against a prompt-injected agent. Use service mode for that; in the proof of concept you set it up by hand (see the limits).

One door stays open in both modes: a value you type into the custos CLI on the agent's machine passes through a process the agent's user can trace. Type high-value secrets on your phone instead (N19).

Then your phone shows that request: the host and the full path the key would go to, unshortened, and the reason in the agent's words, cleaned of hidden characters (with a badge when any were removed). You decide, and an approval can narrow a request, never widen it. In the recorded Claude Code run, an instruction planted in a URL was on the phone word for word.

And whatever you approve, a key goes only to the hosts, methods and path prefixes its policy allows, which you set per key. At 22:42 above, that rule is what caught the bug. An allowed API that can mint keys is the gap: keep write rules narrow (N6).

One thing to know: anyone you read an approver's enrollment code to becomes an approver, an AI agent included. The proof of concept can't yet tell a phone's passkey from a software one (attestation checks are planned), so type that code only into the Custos app on your other phone.

Close cousins, and good ones. Keeping a key out of the context is now common: Infisical, OneCLI, 1Password's Environments and others do it in some form. Approving from a phone is not new either: OneCLI (a Slack card) and Clawvisor (Telegram, push) ship it. The comparison shows who does what, with sources, including where they are ahead: they ship, and some are audited.

What's different is narrower. In Custos, 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 goes through a relay that can't read the request, the value or the key share, as long as the approver app's code is honest when it loads. The approval is signed into a chained log with the agent's reason. OneCLI and Clawvisor approve actions through a vendor cloud that holds or decrypts the secrets; 1Password's Credential Broker keeps one of its two keys in an enclave it runs.⁸ And 1Password's own users have asked for remote approval since February; the request was still open on 2026-10-22.⁶

Custos is built to sit in front of 1Password (tested with a stub of its CLI so far). Keep using it.

Our relay stores ciphertext it can't open, and it can't sign a grant. The picture above is its real copy of your 02:14 request. It does see that you answered, when, each grant's window and use limit, and how often each key id is used (the full list is above).

The honest limits: whoever serves the approver app could change its code, so self-host it or run it apart from the relay (N9). A compromised machine can stay quiet about its own uses. And a relay that shows your devices different histories is caught only when you run the check on that host (type the phone's 4 check words into custosd verify); until then it can keep that host on an older history (N17).

The three request words the agent reads you guard against one attack: a relay that shows your phone a different, validly signed request from the same host. It can pick among the host's other pending requests (at most 2) and re-sign each up to 5 times, so it has about a dozen candidates against 16.8 million word triples (three bytes of the request's hash, spec §3; ADR 0050): roughly 1 in 1.4 million per request. And only if you compare them with the words in the agent's session; on your phone alone they check nothing. Where the terminal shows a 6-digit number to type, that number binds the approval to the request (P4); the 02:14 request in the story comes over MCP, with no number, so there the words are the only check. The words come through the agent, so they don't tell you whether the agent is honest (ADR 0035); the host, path and reason do.

Adding an approver passes your account secret through our relay, sealed to the new device with X-Wing (ML-KEM-768 + X25519); an honest relay deletes it after 10 minutes. A hostile relay can keep it, along with the sealed key halves in the log: if both halves of X-Wing are ever broken, the kept log opens every policy and reason, and both key halves of each secret that was granted or proposed by a host, which means the values themselves (harvest now, decrypt later; N18, ADR 0034).

The 07:00 cut-off is kept by an honest host's daemon, not by cryptography, and it uses devbox-03's clock. Someone who controls both our relay and the host's time server could stretch a grant by as much as they skew that clock (N2).