> ## Documentation Index
> Fetch the complete documentation index at: https://livingcontext.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> How LivingContext protects your credentials, data, and Salesforce org.

LivingContext is built for teams that hand an AI agent the keys to their documentation — so the security model is deliberately conservative: encrypt everything sensitive, minimize what agents can see, and put a human in front of anything that changes an external system.

## Account security

<CardGroup cols={2}>
  <Card title="Two-factor authentication" icon="shield-check">
    Every member can enable TOTP two-factor authentication (any authenticator app) with one-time backup codes, from **Settings → Security**. Sign-in for enrolled accounts requires the second factor.
  </Card>

  <Card title="Session control" icon="laptop">
    Review every active session — device, network, age — and revoke any one of them (or all others at once) from **Settings → Security**. Sessions expire after 7 days.
  </Card>
</CardGroup>

Passwords follow a modern (NIST-aligned) policy — a 12-character minimum with a breached-password deny-list, enforced server-side — and the sign-in endpoints are rate-limited against brute force.

## Credentials and keys

<CardGroup cols={2}>
  <Card title="Encrypted at rest" icon="lock">
    OAuth tokens and secrets are encrypted at rest with AES-256-GCM, with support for master-key rotation. LivingContext never stores your git or Salesforce credentials in plaintext.
  </Card>

  <Card title="Hashed API keys" icon="key">
    API keys — extension keys and MCP keys — are stored as hashes and shown **once** at creation. Keys can be minted with an expiry (30/90/365 days), and creation and revocation are recorded in the audit log.
  </Card>
</CardGroup>

<Warning>
  Keys stop working **the moment a member leaves the organization**. Offboarding a teammate automatically revokes every key they created.
</Warning>

## Organization security policy

Administrators set org-wide access policy in **Settings → Security**:

| Policy                      | What it does                                                                                                                                                                                                                |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Invite domain allowlist** | Restrict member invitations to your company's email domains — invitations to any other domain are blocked at the source.                                                                                                    |
| **IP allowlist**            | Restrict organization access to specific networks (IPv4/IPv6 addresses or CIDR blocks). Enforced on every path in — web sessions, the capture extension, and MCP keys. Saving a list that would lock *you* out is rejected. |
| **AI processing opt-out**   | One switch that stops all document content from being sent to AI providers — doc generation, suggestions, and agents pause for the organization until re-enabled.                                                           |
| **Retention windows**       | How long the security audit log (default 365 days) and resolved inbox events are kept.                                                                                                                                      |

## Audit log

Beyond the agent action trail, every security-relevant event in the organization is recorded append-only — sign-ins across all providers, member and role changes, invitations, API keys, connections, and settings edits, each with actor, IP address, and timestamp. Administrators review and filter it in **Settings → Audit log**; retention follows your policy.

## Tenant isolation

Each organization lives on its own subdomain (`<slug>.livingcontext.ai`) with per-organization data isolation. Members of one organization can never see another organization's docs, connections, or activity.

## Your data

* **Export** — any member can download a JSON export of everything stored about their account (profile, linked sign-in providers, memberships, sessions, key metadata — never secrets) from **Settings → Security**.
* **Deletion** — self-service account deletion, with a safeguard: the last administrator of an organization with other members must hand over administration first.

## What agents can and cannot do

### Reads are minimized

When agents ground documentation against your live Salesforce org, they work from **metadata, not record contents**. For example, field utilization analysis is count-only — the agent learns *how many* records populate a field, never *what's in* them.

### Writes are gated

Every side-effecting agent action — a Salesforce write, a deployment, an outbound call — requires **explicit human approval** before it runs, on every plan. There is no configuration that removes the approval gate.

### Everything is auditable

Every side-effecting agent action is written to an **immutable audit log**, so you can always answer who approved what, and when.

<Note>
  Documentation changes follow the same principle: agent-drafted docs ship only through human review in the [Inbox](/guides/inbox), a change request, or a PR. See [Core concepts](/getting-started/concepts).
</Note>

## Browser capture safety

The capture extension is designed so sensitive data never leaves the browser in the first place:

* **Redaction happens at capture time**, not after upload. Configurable smart-blur categories (see the [settings reference](/admin/settings-reference)) are applied as the capture is recorded.
* **Passwords are always masked**, regardless of your blur settings. This floor cannot be turned off.
* **Screen recording is constrained to the browser tab only** — the extension cannot record your full screen or other application windows.

Learn more in [Capture](/capture/overview).

## Sign-in options

You control how your team authenticates:

* Email and password (with optional two-factor), Google, or GitHub
* **Enterprise SSO** through your identity provider — Okta, Microsoft Entra, Auth0, and other standards-based IdPs

Combine SSO with [roles and permissions](/admin/roles-and-permissions) to keep access aligned with your directory.

## Security checklist for administrators

<Steps>
  <Step title="Turn on two-factor authentication">
    Enable 2FA on your own account first (Settings → Security), then ask administrators and creators to do the same.
  </Step>

  <Step title="Set the organization policy">
    Restrict invitations to your email domains, and add an IP allowlist if your team works from known networks.
  </Step>

  <Step title="Right-size roles">
    Default invitations to Editor, and reserve Administrator for the few people who manage members and billing.
  </Step>

  <Step title="Review keys periodically">
    Extension and MCP keys are listed in Settings — prefer expiring keys, and delete any that are no longer needed. Offboarding revokes a departing member's keys automatically.
  </Step>

  <Step title="Tune capture blur">
    Review the smart-blur categories in Settings so captures redact the data classes your organization cares about.
  </Step>

  <Step title="Make the audit log part of your cadence">
    Check Settings → Audit log for sign-ins, role changes, and key activity as part of your regular review.
  </Step>
</Steps>

## On the roadmap

Being transparent about what's *not* built yet:

| Capability                         | Status                                                                                                                                        |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| SCIM provisioning / directory sync | Planned — membership is currently managed through invitations and removal (which revoke access and keys immediately).                         |
| SAML                               | OIDC SSO covers Okta, Entra, Google Workspace, Auth0 and other modern IdPs today; SAML is available on request for SAML-only IdPs.            |
| Support access controls            | LivingContext staff have no impersonation mechanism today — a consent-based, audited support-access flow is planned before one is ever added. |

If one of these gates your security review, [contact us](https://livingcontext.ai) — they're prioritized by enterprise demand.