Security

This page describes what Alvia does to protect your memories, and what your integration is responsible for.

Isolation

Accounts and projects. Every request is limited to the project of the API key that sent it. A key cannot read or change memories in another project, in your account or any other.
No confirmation of other data. A request for a memory or project in another account gets the same 404 response as a request for one that does not exist.
Scope inside a project. Scope keeps the memories of each user, agent or team apart: formation relates a new fact only to memories in the same scope, and a scoped read returns only memories that match it. Scope is not access control: every key of a project can read every memory in it. See Projects and scope.
Dashboard members. Every member of your organization can see every project’s memories, create keys and delete projects. Only admins manage members, revoke keys and delete the organization.

API keys

Keys are stored as hashes. Alvia never stores a key itself. The full key is shown once, when you create it.
Keys can be revoked at any time. Only account admins can revoke keys. A revoked key stops working at once.
Keys have limited reach. An API key cannot create or revoke keys, or change account settings.
Keys can expire. Choose their expiration in the dashboard or create a key without one. Replace a key before it expires and rotate non-expiring keys on your own schedule. See Rotate a key in Authentication.

Transport

The API is served at https://api.alvia.ai. Send every request over HTTPS, and never send a key over plain HTTP.

The API serves server-side calls and sends no CORS headers, so keys stay on your servers.

Error responses

Error responses give a stable code and a short message. They include no stack traces, internal names or names of the services Alvia runs on.

Data retention and deletion

Action	What happens
Forget a memory	The memory leaves every read, as Forget a memory describes. If its search entry cannot be deleted at once, Alvia retries, and search and recall can return it until the retry succeeds. Its submitted text, versions, relationships and feedback are kept until the project is deleted.
Delete a project	Alvia deletes the project’s memories, versions, relationships, feedback and API keys, and erases the text sent to it. It removes query text and scope from the project’s activity records. It keeps counts of reads and writes for usage reporting.
Delete the account	Alvia deletes every project, then all usage records and the record of every submission, then the account itself.

Alvia keeps the text of every submission until you delete the project, including text a policy kept out of memory and the text behind forgotten memories. A forgotten memory stays out of reads and future context.

The dashboard’s activity log keeps a record of each call made with an API key, over REST or MCP: its operation, status, scope and memory ID, the query text of context, recall and search, and the IDs and ranked scores of the memories returned. Each record is kept for 90 days. Deleting the project removes its records’ query text and scope; deleting the account removes the records. Playground calls use a temporary API key, so the log records them too.

You delete projects and the account in the dashboard, where the account’s control is Delete organization. Deleting the account needs the admin role.

Prevent sensitive memories

Project memory policies control which information becomes new memory. Keyword exclusions cover known restricted terms; meaning exclusions cover categories such as personally identifiable information (PII), health disclosures, credentials or confidential customer data. This reduces what later prompts, operators and agents can retrieve from the shared collection.

Use a policy that matches the project’s purpose. A support operator needs a customer’s preferred instruction style without the medical reason volunteered during the call. A development team needs a design decision without the credential pasted into its supporting log. See Memory policies for policy design and Filter memories for configuration and verification.

A policy is a safety net for what slips through. It does not make it allowed to send data the Acceptable Use Policy prohibits, and the submitted text is kept until you delete the project.

Configure the policy before real writes, agent tool calls or historical imports
Test both allowed facts and excluded facts, including paraphrases and mixed conversations
Use separate projects when different services need different policies or access boundaries
Handle existing memories separately when a policy changes; new exclusions do not erase them

Your responsibilities

Protect your keys. See Keep keys safe in Authentication.
Use separate projects for data that must stay apart. Projects are the isolation boundary; scope is not.
Take scope from the signed-in session. A user who can choose the scope can read other users’ memories.
Keep secrets out of memories. Do not send passwords, keys or payment data to Alvia: memories are returned in reads, and submitted text is kept until the project is deleted.
Use opaque scope IDs. Scope values and query text stay in the activity log for 90 days. Use your own database IDs rather than names or email addresses.
Erase data by deleting the project. Forget removes a memory from reads, as the table above describes; deleting the project erases the text sent to it. See Manage memories.

Design a secure integration

Run a server-side Alvia client behind your application’s authentication and authorization. Select the project credential and scope from trusted application state. A browser may request its own memory action, but it must not supply an arbitrary project key, customer scope or memory ID for the server to forward without an ownership check.

Treat retrieved text as application data. Delimit it in prompts and keep it separate from system instructions, tool permissions and executable commands. A remembered instruction does not grant a user the authority to change a payment limit, access another customer or execute a tool. Enforce those decisions in your application even when the context sounds authoritative.

Use different projects for environments or customers that require distinct access boundaries. Use distinct credentials so you can revoke one integration without disrupting others. Scopes select relevant data inside a project; they do not constrain a stolen project key.

Verify the deployment fits your requirements

Use Production checklist to test cross-project access, user-scope handling, policy exclusions, forgetting and failure paths with synthetic data. Record the result and the deployment tested. A passing build or a successful 202 does not establish those properties.

For a security review, map the data you send, why you need it, who can retrieve it and how you will erase it. Include retained submissions and your own transcripts, prompts, traces and exports. Contact Alvia about data location, retention schedules and deployment-specific requirements.

Report a vulnerability

Email security@alvia.ai, and do not disclose the issue publicly until we have fixed it.