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

# Security & Trust

> How credentials are handled, what defends the ingestion surface, where your data goes during LLM analysis, and what we rate-limit.

Seyn ingests some of the most sensitive data an organisation has. This page is the honest inventory of how that data is protected, including the parts that are delegated to specialist providers rather than hand-rolled.

## Credentials

| Credential                                    | How it's handled                                                                                                                                                                          |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **OAuth tokens** (SharePoint, Teams, Outlook) | Brokered by a dedicated OAuth credential custodian; Seyn's database never stores Microsoft refresh tokens. Access tokens are cached in memory with a safety window before expiry refresh. |
| **API keys you create** (`sk_live_*`)         | Only a SHA-256 hash plus the first 8 characters are stored. The full token is shown exactly once at creation and is unrecoverable after that.                                             |
| **Connector secrets** (API-key connectors)    | Encrypted at the application level before storage, not just at-rest disk encryption.                                                                                                      |
| **Platform secrets**                          | Environment-level secret stores; never in source control.                                                                                                                                 |

OAuth scopes are minimal and read-only. **No connector requests write access, and the platform has no code path that writes to a client system.**

## Where your data goes during analysis

* **LLM analysis** uses the Anthropic API. Per Anthropic's API terms, API data is not used for model training.
* **Reranking** sends candidate text snippets to a reranking provider. If no reranker is configured, querying falls back to a passthrough: the feature degrades rather than the data being required to flow.
* **LLM tracing** (prompts, responses, token counts) goes to a **self-hosted tracing instance** on Seyn infrastructure. Observability data never leaves the platform for a third-party SaaS.
* **Documents and uploads** live in S3-compatible object storage, accessed through short-lived presigned URLs.

## The ingestion attack surface

Self-serve upload means hostile files are a design assumption, not an edge case. The ZIP unpacker streams archives with layered defenses:

| Defense            | Limit / behaviour                                                                                              |
| ------------------ | -------------------------------------------------------------------------------------------------------------- |
| Path traversal     | Entries with `..`, absolute paths, backslashes, NUL bytes, drive letters, or UNC paths are rejected.           |
| ZIP bombs          | 50 MB per file, 10 GB total uncompressed, 50,000 entries, and a 10:1 compression-ratio cap per entry.          |
| Encrypted archives | Rejected outright with an explicit error reason.                                                               |
| Symlinks           | Rejected via archive metadata and file-mode inspection.                                                        |
| Format whitelist   | Only `.docx`, `.pdf`, `.xlsx`, `.xlsm`, `.msg`, `.mpp` are parsed; everything else is skipped, not guessed at. |
| Hung unpacks       | A watchdog fails any unpack with no progress for 30+ minutes. No zombie jobs holding resources.                |

## Rate limits

| Surface         | Limit              | Scope       |
| --------------- | ------------------ | ----------- |
| Public API      | 60 requests/minute | per API key |
| Chat            | 50 requests/hour   | per user    |
| Document upload | 100 requests/hour  | per user    |
| MCP tools       | sliding window     | per API key |

All limits return `429` with a `Retry-After` header. Higher limits for legitimate workloads (backfills, BI) are granted per key: email [support@seynlabs.com](mailto:support@seynlabs.com).

## Auth, isolation, and audit

* Every request is authenticated and organisation-scoped; see [Multi-tenancy](/platform/multi-tenancy) for the isolation model and the superadmin invariant.
* Every LLM call is logged with model, prompt version, and inputs. The audit trail is the same mechanism as the [provenance chain](/platform/provenance).
* Every MCP tool invocation is audit-logged with operation, latency, and outcome.
* Inbound webhooks are signature-verified before any processing.

<Info>
  **Alpha honesty:** Seyn does not yet hold formal certifications (SOC 2, ISO 27001). The architecture above (provenance by construction, application-level encryption, read-only connectors, self-hosted tracing) is designed to make that path short. If certification status is a blocker for your evaluation, talk to us about timelines.
</Info>

## Related

<CardGroup cols={2}>
  <Card title="Multi-tenancy & Roles" icon="building" href="/platform/multi-tenancy">
    The isolation model underneath everything on this page.
  </Card>

  <Card title="Observability" icon="chart-line" href="/platform/observability">
    The audit trail on every LLM call.
  </Card>
</CardGroup>