Sign-in
The browser hashes the password before sending it. Saturn hashes that value again with PBKDF2 and never stores the password.
Trust
Tool arguments, the upstream response, and the result returned to the agent share one AES-256-GCM envelope. ML-KEM-1024 wraps the data key to public keys Saturn does not hold.
A password, a member private key, and a tool payload never share one secret.
The browser hashes the password before sending it. Saturn hashes that value again with PBKDF2 and never stores the password.
A different key, derived only in the browser, wraps the ML-KEM private key. The sign-in hash cannot open it.
One random AES-256-GCM data key encrypts the request and the response. ML-KEM-1024 wraps that key for the organization and each member. Saturn then discards it.
Access tokens and client secrets are sealed with the gateway’s own ML-KEM-1024 key, so an authorized call can be completed. Agents never receive the secret.
These fields are sealed together. The algorithm is ML-KEM-1024-HKDF-SHA384-AES-256-GCM.
The parameters the agent sent with the tool call.
The request Saturn forwarded to the tool.
The raw body that came back from the tool.
The result Saturn returned to the agent.
Whitepaper
16 October 2026
This paper describes the cryptography Saturn MCP uses for sign-in, member keys, tool payloads, and upstream credentials.
Saturn sits between an AI agent and the MCP servers that agent is allowed to call. The gateway authenticates the caller, evaluates policy, forwards an approved call, and writes an audit record. This paper covers the four cryptographic paths that support that work: the sign-in verifier, the member private key, the tool-payload envelope, and the upstream credential vault.
The descriptions match the mechanisms in the product. This paper does not describe a certification, a third-party audit, or a control that the software does not implement.
The browser hashes the password before the request leaves the page. It computes SHA-256 over the label saturn-login-v1, a newline, and the password, then sends the prefix v1. followed by 64 lowercase hex characters. Registration, password reset, password change, re-authentication, invite acceptance, and the OAuth sign-in form use the same verifier.
The gateway stores PBKDF2-HMAC-SHA256 of that hex string: 210,000 iterations, a random 16-byte salt, in the form pbkdf2_sha256$210000$salt$digest. A caller that still posts a raw password, such as an operator seed, is normalized with the same labeled SHA-256 before PBKDF2, so the stored verifier matches the browser.
The verifier and the member-key wrapping key are domain-separated. The string stored for sign-in is the input to the second hash. It is a different value from the material that wraps a member private key.
Payload keys are ML-KEM-1024 (FIPS 203). The encapsulation key is 1,568 bytes. The private key Saturn records for backup is the 64-byte seed. The browser expands that seed into the decapsulation key. The gateway stores encapsulation keys and encrypted backups. It does not store the seed in the clear.
A member backup is built in the browser from the password. The wrapping material is SHA-256 of the label saturn-member-wrap-v1, a newline, and the password. PBKDF2-HMAC-SHA256 then runs for 600,000 iterations over that digest and a random salt, and AES-256-GCM encrypts the seed. The additional data is password, a newline, and the user id. The sign-in verifier fails this decryption.
An organization recovery backup uses a recovery key shown when the organization key is created. HKDF-SHA256, with info saturn-recovery-v1, derives an AES-256-GCM key. The additional data is recovery, the organization id, and the key version. The recovery key is not stored on the gateway.
When the organization has a payload key, one audit event produces one envelope. The fields sealed together are the tool arguments, the upstream request, the upstream response, the gateway result, and the result returned to the agent. Arguments waiting for approval use the same wrap, marked org-mlkem1024-v1.
The gateway draws a random 32-byte data key and encrypts the canonical JSON with AES-256-GCM. The additional data is the organization id, the record id, the payload type, and the format version, separated by newlines. The format version is 1. The ciphertext includes the 16-byte authentication tag. A SHA-256 of the same canonical JSON is stored beside the ciphertext.
That data key is then wrapped to the organization encapsulation key and to each member encapsulation key. ML-KEM-1024 encapsulation produces a 32-byte shared secret and a 1,568-byte ciphertext. HKDF-SHA384 turns the shared secret into a 32-byte AES key. The salt is empty, which is the 48 zero bytes required by HKDF-SHA384, and the info string is saturn-payload-mlkem1024-v1. The algorithm name on the envelope is ML-KEM-1024-HKDF-SHA384-AES-256-GCM.
Each wrap is a version byte 0x02, the KEM ciphertext, a 12-byte nonce, and the AES-256-GCM ciphertext of the data key. After every wrap is written, the gateway deletes the data key. A member opens the wrap in the browser with the decapsulation key, checks the content hash, and reads the payload there.
A public key that is not 1,568 bytes is skipped. If no usable ML-KEM key is available, the gateway does not write the tool content. The audit row records that encryption is unavailable.
Access tokens and client secrets use a separate ML-KEM-1024 key that belongs to the gateway. The seed is a fixed 64-byte key. Each secret is sealed as the prefix pq1., then ML-KEM-1024 encapsulation, HKDF-SHA384 with info saturn-credential-aes-256-gcm-v1, and AES-256-GCM.
The gateway opens that secret for the duration of an authorized call, then uses it upstream. Console APIs report whether a secret exists. Agents receive the call result. This vault key and the organization payload key are different keys: the gateway can complete a call, and a member opens the sealed audit payload.
The row that stays readable names the caller, the tool, the policy version, and the decision, together with the encryption status and the content hash. The sealed body is the envelope above. An authorized member decrypts it locally after the browser has unwrapped the member key.
Connect one MCP server and open an encrypted audit record from the browser.