Know where the boundaries are.

Keep the Inlay secret key on your server. It can mint end-user sessions and access management operations; it must not be bundled into browser code. Your server must authenticate the user and check authorization before minting a session with that user's identity and groups.

The browser uses the resulting short-lived session. A session cannot mint another session. Inlay does not supply your product's sign-in or decide which of your users should receive access. Follow the server-to-client quickstart.

Sessions expire and can be revoked from your server using a secret key. At mint time, you can restrict allowed agents and set an execution limit. Agent restrictions and execution caps are configuration choices, not automatic least-privilege defaults.

A leaked session can expose data or trigger actions within its permissions. Expiry and revocation help limit exposure; they do not make a credential leak harmless. Protect session tokens as well as server keys, and review the access granted by your session endpoint.

Customer-facing conversation and billing reads use the authenticated tenant and user. User-scoped memory follows the signed user identity; retrieval uses the user and group principals your server asserts. Management routes have broader access and must stay behind your own server or operator interface.

Agent-scoped state is deliberately shared across that agent's users. Choose scopes and retrieval permissions to match your product, rather than assuming every stored value is private to one user. See state and memory and retrieval.

Declared state fields are private by default; public fields can reach the SDK as outputs or tables. Your client also receives conversation content and the client-facing timeline. Treat anything delivered to a browser as visible to that user, even if your interface does not render it.

Server-tool rows redact arguments and results by default while showing the tool name. MCP and subagent tools can opt into full rows; memory tools follow the visibility of the fields they touch. Operator traces can contain fuller arguments and results and need restricted access. See the redaction contract.

Redacting a tool row does not prevent the model from quoting its result in an answer or public output. Review prompts, retrieved content, tool permissions, and output visibility together. The vault protects credentials, not every piece of data obtained with them.

The tenant vault stores connector credentials such as API keys and OAuth tokens. Tool configuration references a secret by name; the credential is resolved server-side for dispatch. Vault read and list operations return metadata, which can include a display hint, not the full credential. Rotation replaces the value behind the reference.

In persistent deployments, secret material is encrypted with AES-256-GCM before storage in Postgres, with tenant, name, and kind bound as authenticated data. The in-memory development vault is plaintext and is not for real credentials. These are vault-specific controls, not a claim that every category of platform data uses the same storage treatment. Read the secrets guide.

MCP tool calls must be present in both the confirmed tool snapshot and the connector allowlist. The first connection allows all discovered tools, so narrow that list deliberately. Later tool-list refreshes are explicit, with newly discovered tools off by default when applying a refresh.

URL fetching and MCP connections use an egress guard that blocks non-public destinations by default, validates redirects, and caps responses. Private-network MCP access requires operator configuration; URL fetch does not have that exception. The embedded Starlark code tool has no filesystem, network, or environment access and uses execution limits.

External services still receive the data sent to them. Choose connectors and permissions carefully, and authorize client-tool actions in your own app. See MCP connectors and server tools for the detailed controls and limits.

Model, embedding, retrieval, and connector services receive the content needed for the calls your agent makes. Their retention and training policies depend on the provider, account, and configuration. This page does not make a no-training guarantee on their behalf.

The privacy policy is a draft pending review, including retention, subprocessors, and the process for data requests. Confirm your data-handling requirements during onboarding before sending sensitive workloads.

If you already have access, use your onboarding conversation. Otherwise, use the request-access form to ask for a private security discussion. Do not include credentials, personal data, or exploit details in the initial message. A dedicated reporting contact and response policy are still pending publication.