> For the complete documentation index, see [llms.txt](https://entermirari.gitbook.io/entermirari-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://entermirari.gitbook.io/entermirari-docs/architecture/security.md).

# Security Model

A condensed version of how MIRARI keeps your data — and your agent — safe.

## Identity

* Auth is email/password + Google OAuth.
* Email signups are confirmation-required by default. You must click the link before you can sign in.
* Sessions are managed in the browser; server functions verify them via the `requireSupabaseAuth` middleware before executing.

## Authorization (RLS)

Every user-scoped table is RLS-enabled with these two policies:

```sql
create policy "<t>_select_own" on public.<t>
  for select using (auth.uid() = user_id);

create policy "<t>_modify_own" on public.<t>
  for all using (auth.uid() = user_id) with check (auth.uid() = user_id);
```

Even if a query slipped past application code, the database itself refuses to return rows that don't belong to the calling user.

## Server-function safety

* All server functions are **POST-only**.
* All inputs are validated with **Zod** (length caps, format regexes, enum guards).
* Inputs that look like ids are validated as UUIDs before being interpolated into queries.
* Server functions use a **request-scoped, user-authenticated** Supabase client — never the admin/service-role client — except for narrow operations (e.g. wallet nonce flows) where the admin client is required.

## Service-role isolation

* The service-role key is never imported in client code.
* Only two tables (`wallet_nonces`, `wallets`) are written exclusively by service-role server functions. Their RLS policies deny client writes by design; this is intentional and documented in our security memo.

## Keys to external services

* **Hermes Agent API keys** live in the browser only. See [Local Key Vault](/entermirari-docs/architecture/key-vault.md).
* Other third-party secrets (if any are added) are server-side env vars, read inside `.handler()` so they never leak to the client bundle.

## Roles & privilege escalation

MIRARI does **not** put roles on the profile table. If multi-tenant or admin roles are ever added, they go in a separate `user_roles` table behind a `security definer` `has_role()` function — the standard pattern that avoids RLS recursion and privilege-escalation footguns.

## What we explicitly do not do

* We do not store your Hermes Agent API key.
* We do not log Hermes Agent request/response bodies.
* We do not send your conversations, memory, or skills to any third party other than the Hermes Agent endpoint *you* bound.
* We do not run cron jobs against your account or your model behind the scenes.

If you can read your Memory Atlas, you can read your agent's entire long-term context. There is no hidden state.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://entermirari.gitbook.io/entermirari-docs/architecture/security.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.