Authentication & API keys
The one credential your agents need
Agents authenticate to SPM with a single API key. They never receive your Supabase session or provider keys:
Authorization: Bearer spm_live_...
Anthropic-dialect clients may send the same key in x-api-key; both are accepted.
What a key resolves to
Before processing memory, the gateway resolves each request key into a fenced identity:
- tenant — every memory object carries a tenant id; recall cannot cross tenants
- namespace — the memory partition inside the tenant
- policy and scopes — what the key may do
- provider — which vaulted credential to forward with
Keys are stored as peppered hashes. The gateway does not log them, and request receipts contain no key material.
Scopes
Keys and console-issued tokens carry least-privilege scopes:
| Scope | Allows |
|---|---|
memory:write |
Store memory (MCP remember, ingest) |
memory:read |
Recall and read memory |
memory:delete |
Delete memory and purge sources |
receipt:read |
Query request receipts |
After a Supabase sign-in, the web backend issues short-lived capability tokens for console operations. This credential domain is separate from agent keys, so a leaked agent key cannot open the console.
Hygiene
- Create one key per agent or environment; revoke it by deleting it in the console.
- Rotate keys on suspicion; frequent rotation has no usage penalty.
- Never commit keys. SPM rejects malformed keys promptly, but a committed
spm_livekey remains live until revoked.