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

# Security

> How Alterscope issues and scopes API keys, encrypts the credentials you entrust to it, and protects data in transit — described as practices, not promises.

This page states what Alterscope actually does to protect access, credentials, and data. It describes practices you can verify in the product's behavior, not a list of badges. Where a safeguard isn't in place, we don't imply that it is.

## API access and keys

Programmatic access uses API keys, issued and managed per organization.

* **Keys are high-entropy.** Each key is generated from 256 bits of cryptographic randomness and carries an `sk_live_` prefix so it is recognizable in logs and config review.
* **Keys are never stored in recoverable form.** Only a SHA-256 hash of the key is persisted; the full secret is shown exactly once, at creation. Alterscope cannot retrieve a lost key — you rotate by issuing a new one.
* **Only a short prefix is displayed afterward.** After creation, the dashboard shows just the first few characters so you can identify a key without exposing it.
* **Keys are scoped.** A key carries an explicit set of scopes, so access can be limited to what an integration actually needs. See [Scopes & permissions](/develop/get-started/scopes).
* **Keys are revocable, and rotation is revoke-then-issue.** A compromised or retired key is revoked immediately; you create a replacement with its own scopes. There is no shared or master key to leak.

## Credentials you connect

When you connect an external account to Alterscope, the credentials are never stored in plaintext. They are protected with **envelope encryption**:

* A unique **data key** (AES-256-GCM) encrypts each stored credential.
* That data key is itself wrapped by a **key-encryption key held in a managed cloud key service** (Google Cloud KMS), so the encryption keys never live beside the data they protect.
* **In production, the managed key service is mandatory.** The platform refuses to start the connection path with a plaintext fallback key in production — there is no "encrypt later" or "encrypt sometimes" mode for live credentials.

## Data in transit

* All API traffic is served over **TLS**.
* In production, responses carry **HTTP Strict Transport Security** with a one-year max-age and `includeSubDomains`, so compliant clients refuse to downgrade to plaintext.
* Responses that carry sensitive data are marked `no-store`, so they are not cached by intermediaries.

## Browser and request protections

For browser-based access, the API applies a defense-in-depth set of controls on every response:

| Control                                            | What it does                                                                                                                                                                                           |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Content-Security-Policy (`default-src 'none'`)     | Blocks injection of unexpected scripts or resources.                                                                                                                                                   |
| `X-Frame-Options: DENY` + `frame-ancestors 'none'` | Prevents clickjacking by refusing to be framed.                                                                                                                                                        |
| `X-Content-Type-Options: nosniff`                  | Stops MIME-type confusion attacks.                                                                                                                                                                     |
| `Referrer-Policy` + `Permissions-Policy`           | Limits referrer leakage and disables unused browser features (camera, microphone, geolocation, payment).                                                                                               |
| CSRF protection (double-submit token)              | State-changing browser requests carry a rotating, `SameSite=Strict`, host-scoped token, compared in constant time. API-key and bearer-token calls — which are not cookie-based — are exempt by design. |
| Strict CORS allowlist                              | Cross-origin browser access is limited to an explicit origin allowlist; there is no wildcard origin.                                                                                                   |
| Request-size limits                                | Oversized request bodies are rejected before processing.                                                                                                                                               |

## How to think about this page

Security is a practice, not a certificate. This page describes the controls that are in the product today, in plain terms, so a risk or procurement reviewer can evaluate them directly. The data side of the same trust story — where data comes from, how fresh it is, and how complete the coverage is — lives under [Data provenance](/trust/data/provenance), [Freshness & quality](/trust/data/freshness-and-quality), and [Coverage & gaps](/trust/data/coverage-and-gaps).