Keeping an accurate inventory of information assets is the first control in most frameworks (ISO 27001 A.5.9, SOC 2 CC, the foundation of a GDPR Art. 30 RoPA): you cannot protect, retain, or erase what you have not enumerated. This page is the shipped inventory. It pairs with Data Protection (how content flows between these assets), Compliance (roles, retention, data-subject requests), Security (the control mechanics each row cites), and Risk Assessment (the risks rated against this inventory).
The privacy invariant applies here too: every asset below is described by its class, owner, and location — never by any prompt or response content it holds.
01Two perimeters
Anyray is self-hosted, so the inventory spans two perimeters with different owners. Almost every asset lives in your environment; the only vendor-operated asset is the Portal account plane, and it holds content-free metadata only.
| Perimeter | Who operates it | Who owns the inventory |
|---|---|---|
| Self-hosted deployment — gateway, optimizer, console, your Postgres, the data volume | You | You. Anyray ships this inventory as the starting register; you keep your deployment's copy current. |
| Anyray Portal account plane — sign-in, tenant membership, billing (via Stripe), content-free usage rollups, pseudonymous seat hashes | Anyray (vendor) | Anyray. Inventoried here as the vendor-operated surface; no prompt/response content ever reaches it. |
02How assets are classified
Each asset carries a sensitivity class. The scheme follows the content boundary: the most sensitive assets are the keys that unlock everything, then attributable content, then content-free operational metadata, then the pseudonymized data that is safe to egress.
| Class | What it covers | Disclosure impact |
|---|---|---|
| Secret | Access tokens & cryptographic key material | Full compromise — unlocks data or access |
| Confidential | Prompt/response content & directly attributable personal data | Privacy breach (mitigated at rest by the content mode) |
| Internal | Content-free operational metadata & config | Operational exposure, no content |
| Pseudonymous | Content-free, pseudonymized data cleared to egress | Low — re-identification needs a salt that never leaves your box |
03Data & store assets
Stores that hold data. Every one except the last row lives on your volumes and datastores; the protective controls are detailed under Data Protection.
| Asset | Class | Owner | Location | Protective controls |
|---|---|---|---|---|
| Spend store | Internal | You | Postgres anyray_spend | Metadata-only by design; admin-gated; configurable retention window |
| Observability trace store | Confidential | You | Postgres anyray_traces / anyray_observations | Content gated by mode — ciphertext in encrypted, none in off |
| Durable context stash | Confidential | You | Postgres anyray_context_stash | AES-256-GCM blobs only; per-developer scope; off by default |
| Optimizer ephemeral stores | Confidential | You | Optimizer process memory (TTL-bounded) | Lost on restart; keyed by content-free hashes; purgeable |
| Client keys & enrollment links | Internal | You | Gateway data volume | Token hashes only (SHA-256); usernames bound, never raw tokens |
| Audit logs | Internal | You | Gateway / optimizer data volume | Per-domain append-only JSONL, actor + action only; SIEM-routable |
| Anyray Portal account plane | Pseudonymous | Anyray | Vendor control plane (AWS) | Operator sign-in + memberships; content-free rollups + HMAC seat hashes; billing data via Stripe |
04Secrets & cryptographic material
The key material and access tokens that protect everything above. Treat each as a production secret — store it in your secret manager, never in the repo. The crypto mechanics live under Data Protection and Security.
| Asset | Class | Owner | Location | Role |
|---|---|---|---|---|
ANYRAY_ADMIN_TOKEN | Secret | You | Your secret manager → gateway env | Gates the console + every /admin/* route (constant-time compare) |
ANYRAY_CONTENT_KEY | Secret | You | Your secret manager → gateway env | AES-256-GCM key for content at rest — no rotation path, guard it |
ANYRAY_PSEUDONYM_SALT | Secret | You | Gateway env (never leaves your box) | HMAC salt that makes Portal seat hashes pseudonymous, not reversible |
| Provider API keys | Secret | You | Gateway, server-side | Never returned to a caller; audit-logged by slug only |
Client keys (ark_…) | Secret | Developer (you mint) | On the developer's machine; hash in the gateway store | Per-developer /v1/* credential; raw value shown once at mint |
ANYRAY_TENANT_SECRET_KEK | Secret | You | KMS / gateway env (managed multi-tenant only) | Envelope-wraps per-tenant provider creds; mismatch fails closed |
ANYRAY_CP_SERVICE_TOKEN | Secret | You | Gateway + control plane (multi-tenant only) | Shared bearer the gateway presents for tenant-context resolution |
| Updater token | Secret | You | Server-side (Docker installs) | Gates the update trigger; derives from the admin token unless overridden |
| DevCert keypair & pinned vendor verify key | Secret | Anyray issues, you hold | Developer machine + pinned in the gateway image | Offline enrollment verification + Ed25519 entitlement / kill-switch anchor |
Two secrets have no recovery. ANYRAY_CONTENT_KEY has no keyring and no rotation path — set a new value and content written under the old one becomes permanently undecryptable. And if ANYRAY_PSEUDONYM_SALT is unset, the gateway falls back to an empty-key HMAC, making Portal seat hashes dictionary-checkable. Both are tracked in the risk assessment.
05Service & system assets
The software components that process and store the assets above. The optimizer is deliberately credential- and content-persistence-free.
| Asset | Owner | Location | Holds / handles |
|---|---|---|---|
| Gateway | You | Your environment | Provider keys, content crypto, spend attribution — the only component holding secrets + content |
| Optimizer | You | Your environment (in-network) | Transforms requests only; credential-free, content held in memory + TTL-bounded |
| Console | You | Your environment | Admin surface; reads metadata + (per mode) trace content via admin-gated endpoints |
| Postgres | You | Your environment | Backs the spend store, trace store, and durable context stash |
| Updater + socket proxy | You | Your environment (Docker installs only) | Least-privilege image updates; read-only Docker socket |
| TLS edge (Caddy) | You | Your environment (public profile) | Terminates TLS |
| Anyray Portal control plane | Anyray | Vendor | Sign-in, tenant membership, billing, content-free metering rollups |
06Keeping the inventory current
An asset inventory is only a control if it stays accurate — a store, secret, or service that exists but isn't listed is an un-assessed risk. Review on the same cadence as the risk assessment: quarterly, and on any material change.
- Trigger a review on material change — a new provider, data flow or store, secret/env var, schema migration, or deployment surface adds an asset; fold it in rather than waiting for the quarter.
- Reconcile against your deployment — confirm each row's location and owner against your configuration and datastores; drop assets a feature you don't run never creates.
- Re-classify and re-own — set the sensitivity class and a named owner for any asset added since the last review.
- Feed the downstream artifacts — carry changes into your RoPA (Art. 30) and re-rate the affected rows in the risk register.
Roadmap — live asset inventory in the console. Surfacing this inventory in the Anyray console — enumerated from live config and datastore state rather than this static page, so a newly configured provider or store appears automatically — is planned, not yet built. Until then this page is the source of record.
07Contact
Email: hi@anyray.ai