> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Inbox AI privacy catalog — the whole lane family in one entry

> The composed catalog row for the Inbox AI privacy lane: which of the two certified keys ship content to the third-party LLM, which lane-type family tags (categorize, summarize, spam routing) run on your settings blob, and how to read the posture overview before you opt out.

# Inbox AI privacy catalog

The [Inbox AI privacy](/compliance/inbox-ai-privacy) page documents the two
default-ON optional LLM hops individually. This catalog entry is the
composed row for the lane family — one entry in your compliance posture
that covers every lane-type the lane can run against inbound message
bodies and close-time summaries.

<Note>
  This page documents a tenant-owned control, per Orbit's
  [compliance model](/compliance/posture-overview). Whether content leaves
  your organization on a third-party LLM lane is your call; Orbit documents
  the control and enforces what you set.
</Note>

## Catalog scope vs tenant-owned self-registration

The `/compliance` catalog is where the platform's named posture rows live
— the public surface documents every toggle you can declare in one
inventory. Tenant-owned scope, by contrast, is the growing list of
individual gates and posture documents your organization maintains
(terms, privacy, and the trust-center posture binder). The inbox AI
privacy lane reads from the catalog because the platform certifies its
keys once, here — your posture document can then reference this row
without bundling per-lane optionality.

## Pillar columns — declared optionality with honest defaults

Two independent toggles + one routing option are what the lane family
certifies. Defaults are marked next to behavior so the catalog row is
self-contained (the same honesty the [Inbox AI
privacy](/compliance/inbox-ai-privacy) page carries per gate).

| Lane-type key | Certified key on `organizations.settings` | Default | Behaviour when ON | Behaviour when OFF |
| - | - | - | - | - |
| Auto-categorize | `inbox_auto_categorize.enabled` | ON (true) | Each inbound body ships to the LLM classify hop (sales / support / spam). | Classify hop is a no-op; conversations render uncategorized. |
| Auto-summarize | `inbox_auto_summarize.enabled` | ON (true) | Closing a conversation ships its recent messages to the LLM summary hop. | Summary hop is a no-op; history, notes, and tags are unaffected. |
| Spam terminal action | `inbox_spam_policy.action` | `none` (tag-only) | `archive`, `close`, or tag-only `none` fires when the classifier is confident. Tied to auto-categorize — a disabled classify hop never runs this. | `none` keeps the tag only; `archive`/`close` move the conversation out of the inbox. |

The catalog row names the certified keys once; your organization
posture file then references this row instead of re-declaring each
gate.

<Warning>
  Opting out of auto-categorize disables the classifier the spam lane
  depends on — the saved `inbox_spam_policy.action` stays set, but no
  classifier output ever triggers it. Universal legal redaction
  (opt-out phrasing, consent markers) and the outbound
  [DLP scanner](/compliance/dlp-scanner) stay active on any opt-out
  lane combination.
</Warning>

## Visual layer — the endpoint shape mirrored

```yaml theme={null}
# GET /api/v1/settings/compliance/inbox-ai-privacy
# PATCH /api/v1/settings/compliance/inbox-ai-privacy (owner-only)
auto_categorize: true        # settings.inbox_auto_categorize.enabled
auto_summarize:  true        # settings.inbox_auto_summarize.enabled
spam_action:     "none"      # settings.inbox_spam_policy.action
                             # enum: none | archive | close
```

The endpoint shape above mirrors the
`GET/PATCH /settings/compliance/inbox-ai-privacy` surface exactly —
each PATCH writes only the keys you send, so partial updates leave
sibling keys untouched. Write access is restricted to organization
owners (matching the [AI turn audit](/compliance/ai-turn-audit) and
[policy scanner](/compliance/policy-scanner) posture gates). The
`spam_action` value is validated against the `none` / `archive` /
`close` enum on write; anything else is rejected with a `422`. The
inbound classify path re-reads your organization's settings on the
next event after up to a 60-second cache window, and the PATCH
response echoes the merged persisted state so the read-back is
immediate.

## Posture overview read

Before opting out, open the [posture overview](/compliance/posture-overview)
— it names which lanes are fail-open vs fail-closed and whether this
lane's default-ON behaviour is the correct day-0 posture for your
jurisdiction mix. HIPAA and EU data-governance postures read
processors as a regulated lane, so the conservative read is `false`
on both gates until your BAA or DPA scope covers the LLM hop.

## Related lane families

* [Inbox AI privacy](/compliance/inbox-ai-privacy) — the per-gate
  deep page this catalog entry summarizes.
* [Emergency stop](/compliance/emergency-stop) — org-wide outbound
  halt; lift it before you re-enable LLM hops for an audit snapshot.
* [Agent identity governance](/compliance/agent-identity-governance) —
  the NHI inventory that governs which AI agent can reach inbox
  content; opt-out here does not re-enable an agent that has been
  suspended.
* [DLP scanner](/compliance/dlp-scanner) — outbound scanning of the
  body the lane decided not to ship; stays active independent of
  these opt-outs.
* [HIPAA](/compliance/hipaa) / [GDPR posture
  guide](/compliance/gdpr-posture-guide) — the two postures that
  drive the opt-out decision most often.