A tool whose keys the model never sees

An agent that had to protect a value or sign a request was handed the key in its prompt, where it landed in the transcript, provider logs and snapshots, or shelled out through Bash with the key in its environment. v1.116.0 ships the Crypto tool: the agent names a key, the runtime does encrypt or decrypt or rewrap or mac or verify_mac or sign or verify or public_key or totp or hash or random, and only the result comes back. Keys live in loomcycle sealed under LOOMCYCLE_SECRET_KEY, or in Vault Transit, AWS KMS or Google Cloud KMS, where the key material never leaves the KMS. Algorithms fixed by the key's type: AES-256-GCM, XChaCha20-Poly1305, HMAC-SHA256/512, Ed25519, ECDSA P-256, JWE, JWS, RSA-OAEP/PSS, Argon2id, RFC 6238 TOTP. The envelope lcx1 source name version body binds tenant, source, name, version and the caller's context to the AAD, so a value moved to another key, scope or context does not open. The same operations ship on the operator API (POST /v1/_crypto, gRPC, MCP's crypto meta-tool, TS crypto(), Python crypto()). Default-deny grants (crypto_scopes on AgentDef); 1 MiB per argument and 100 ops per run; every op audited with no data or key material in the record. Also folded in: untrusted text never reaches memory, and another user who continues a session never gets the session user's credentials.