This page covers where OMS keeps your provider keys and account token, how those files are protected, and what stays out of the model’s reach.

Where they live

Provider keys and subscription tokens are in auth.json under the agent folder of the OMS state root. The OMS account token is in oms-account.json in the same folder. The folder and files must be private: owned by you, with no group or other permissions, not a symlink, and a single hard link for files. When OMS saves, it writes the new JSON to a temporary file created with O_EXCL and O_NOFOLLOW and mode 0600, flushes it, then renames it. A file that is group or world readable is refused, not repaired. Tests: yes for the account file and preferences. No dedicated test for auth.json permissions.

What the model never sees

Credentials are read only by host code. Saved keys never enter chat or task files, and setup errors are generic, so a stored key is never echoed. The sandbox and the host child environment never get provider keys, and the token for the Solana reference service never enters the sandbox, the prompt or a tool result. Tests: yes, including that a 401 from the reference service names no secret and echoes no body, and that no credential variable reaches a host child.

Key syntax

OMS refuses API keys with whitespace, control characters, $ or a leading !. See Connect a model.

OMS account

The browser device flow refuses redirects and any verification URL other than the fixed origin. If a stored token’s origin differs from the configured one, OMS does not send it. The token is used as a bearer only to an https or loopback origin.

Untrusted results

Web and reference results are untrusted. They are framed, capped at 16,000 bytes, and cannot close their own frame from inside. web_fetch and source_fetch refuse private, loopback and link-local targets, by literal address and after DNS. Tests: yes for each.