Privacy policy

Scope of this draft

Inlay provides infrastructure for builders running agent products. The information processed depends on the features in use, the agent's configuration, and the external services it calls. This inventory covers the marketing site and the platform; a builder's own product also needs its own privacy disclosures.

Data the service handles

• Access requests. The request-access form collects a name, email address, and optional message about the product being built. The configured submission flow uses Resend to deliver the request for manual review and response. Do not include credentials or private customer data in the message.
• Accounts and access. Account details, organization membership, tenant configuration, API-key metadata, and session records. Builders supply end-user identifiers and group claims through their server-side integration; those claims affect access and usage attribution.
• Agents and runtime records. Graph definitions and published versions; conversation messages, prompts, model responses, outputs, tool calls and results, run state, traces, and usage measurements such as token counts and timing. Their content can contain personal data supplied by the builder, an end user, or a connected service.
• Retrieval data. Documents, source links, headings, metadata, derived chunks and embeddings, index configuration, queries, retrieved passages, citations, and evaluation inputs and results.
• State and memory. Declared fields, values, and table rows used by an agent, including user-scoped and agent-scoped memory. Scope and public visibility are separate configuration choices; agent-scoped values can be shared across that agent's users.
• Credentials and connectors. Vaulted API keys or tokens, OAuth credentials, connector URLs, tool schemas, permissions, and connection status. Credentials are used to authenticate configured external calls. Vault APIs expose metadata and display hints rather than returning full secret material; persistent-vault storage is described in the secrets guide.
• Schedules. Task instructions, cadence and time zone, the agent and version, the end-user identity a run acts as, enabled state, and execution status. A scheduled task becomes input to a conversation and can generate the same runtime and usage data as an interactive run.
• Billing data. Plans, allowances, subscriptions, credit grants and balances, attributed usage, invoice records, payment status, and Stripe account or transaction references where billing is configured. Hosted checkout and invoice flows collect payment details through Stripe.

How configuration moves data

Running an agent can send conversation content, retrieved text, memory, and tool results to a configured model provider. Retrieval can send documents or queries to configured embedding and reranking services. Server tools and connectors send the arguments and authentication required by the external service they call.

The platform also processes records to execute and inspect runs, manage access, store configured state, and meter usage. Email delivery, hosting, and payment services process data for their respective functions. Operational request and error logging must also be covered by the final notice.

Pending review: the complete provider and subprocessor list, locations and transfers, contractual safeguards, operational log fields, and site cookie or analytics disclosures. Model-provider retention and training terms vary by provider, account, and configuration. No blanket no-training or data-sharing commitment is established by this draft.

Public output is different from a private credential

Public agent fields are available through the client-facing interfaces; conversation content is also delivered to the app. Here, public describes a field's visibility to the client, not publication to the internet. A builder decides what its own product renders or further shares.

Server-tool arguments and results are redacted from the client-facing timeline by default, with configurable exceptions. Operator traces may contain fuller data. A model can still include information from a tool or retrieved document in its answer. Credential storage and trace redaction are not a guarantee that connected-service data stays out of outputs. See security boundaries.

Builder and service responsibilities

Builders control their product's sign-in, authorization, supplied user identifiers, agent configuration, data sources, and interface. They need the appropriate rights and permissions for the data and services their agents use, and must consider what their own users are told about that processing.

Pending review: the legal entity responsible for Inlay, controller and processor roles, applicable legal bases, and any data-processing agreement. This draft does not settle those legal allocations.

Retention and deletion

Pending review: retention periods and deletion procedures have not been approved for publication. No fixed retention period or deletion deadline is promised here.

The final policy needs to address access-request email, accounts, conversations and traces, retrieval documents and derived indexes, memory, credentials, schedules, operational logs, backups, and billing or legally required records. Removing one product resource should not be assumed to remove every related record from all systems or external providers.

Privacy questions and data requests

If you use a product built on Inlay, start with that product's provider, which controls your account and how it uses the platform. If you are an Inlay builder, use your existing onboarding conversation. Site visitors can use Request access to ask for a privacy contact; do not include sensitive data in the initial message.

Pending review:an approved privacy contact, the request and identity-verification workflow, jurisdiction-specific rights and complaint information, and the policy's effective date and change-notice process. Applicable legal rights are not limited by the unfinished status of this document.