> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Security > FailproofAI Observability Security documentation. FailproofAI Observability is built to sit close to your production agents, which means it sees your prompts, tool inputs, and outputs. This page explains how it keeps that data isolated, controlled, and in your hands. If you're evaluating FailproofAI Observability for a security review, start here. *** ## Your data stays in your environment FailproofAI Observability is self-hosted. Events, prompts, model responses, and analytics are stored in your own databases, in your own environment. Nothing is sent to a third-party SaaS for storage, and your data stays in your own cloud account. *** ## Tenant isolation One FailproofAI Observability instance can host many organizations, and each is isolated at the storage layer — enforced by the database, not just the UI: * An organization's operational data (users, keys, dashboards, saved queries) is scoped to that org, and cross-org reads are blocked by the database itself. * Every ingested event is stamped with its owning org, so one organization's events can never be read by another. Every dashboard route is scoped under an org slug (`//…`). *** ## Sign-in FailproofAI Observability uses passwordless, email-based sign-in. There is no password to phish or leak. A user requests a one-time code (or a one-click magic link), which is emailed to them and expires quickly. Sign-in is gated by an **allowlist**: only email addresses (or domains) you permit can authenticate. The FailproofAI Observability sign-in screen, which sends a single-use code to your email *** ## Scoped access with API keys Every client authenticates with an API key that carries granular, least-privilege permissions. A collector needs only `events:add`; a dashboard or assistant key can be read-only; destructive actions (delete, regenerate) are separate grants you choose to include. The API keys page: each key's permission grants, colour-coded by read, write, and destructive scope Keep the admin bootstrap key for setup, and issue narrow keys for everything else. See [API keys](/agenteye/api-keys). *** ## A read-only, approval-gated assistant The in-dashboard [AI assistant](/agenteye/assistant) answers questions over your data, but it is constrained by design: * It is **read-only by default**: its SQL runs through a guard that permits only `SELECT`/`WITH` queries, single-statement, with a row cap. * Anything it creates (a saved query, a dashboard) is **approval-gated**: you review and approve every write before it happens. * It **can never delete**. So a teammate can ask "which agents errored most this week?" and act on the answer, without the assistant being able to change or remove your data on its own. *** ## In transit All traffic runs over HTTPS. You terminate TLS with your own certificates, so collector-to-server and browser-to-server traffic is encrypted in transit. *** ## Next steps * [Overview](/agenteye/overview): how FailproofAI Observability fits together. * [API keys](/agenteye/api-keys): scope access for the collector, dashboard, and assistant. * [Observability](/agenteye/observability): what FailproofAI Observability captures from your agents.