Skip to main content

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.

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.
  • 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:
ControlWhat 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: nosniffStops MIME-type confusion attacks.
Referrer-Policy + Permissions-PolicyLimits 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 allowlistCross-origin browser access is limited to an explicit origin allowlist; there is no wildcard origin.
Request-size limitsOversized 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, Freshness & quality, and Coverage & gaps.