System Manual
Security & Multi-tenancy
How eClips Workforce isolates every organization with Row-Level Security, authenticates the public API with hashed, scoped keys, and rate-limits and plan-gates every path in.
Multi-tenant by construction
eClips Workforce is multi-tenant by construction. Every table that holds customer data is scoped to an organization and protected by Supabase Row-Level Security (RLS), so one org can never read or write another's runs, triage items, trust profiles, credit ledger, or documents. All of an agent's state — circuit breakers, trust profiles, usage periods — is keyed by organization, so isolation holds for both data and behavior.
| agent_runs | Org-scoped — every run belongs to exactly one organization |
| triage items | Org-scoped — exceptions are visible only within their org |
| agent trust profiles | Org-scoped — an agent earns trust separately per org |
| credit_ledger / credit_usage_periods | Org-scoped — usage and budgets never cross tenants |
| agent_circuit_breakers | Org-scoped — a breaker opening for one org never affects another |
| documents (Storage) | Org-scoped — files are isolated per organization |
API authentication
The public /v1 API authenticates with organization-scoped API keys. A key is presented as a bearer token or an X-Api-Key header, and resolves to its organization and a set of scopes that bound what it can do.
curl https://api.eclips.tech/v1/agents/runs \
-H "Authorization: Bearer eck_live_..." \
-H "Content-Type: application/json" \
-d '{ "agent_type": "invoice_processor", "input": { /* ... */ } }'Key prefixes, hashing & scopes
Keys are designed so a leak is contained and a stolen database is useless:
- Prefixes — keys are prefixed
eck_live_oreck_test_to separate live from test traffic at a glance. - SHA-256 hashing — only a SHA-256 hash of the key is stored, never the plaintext. The full key is shown once at creation; after that, the system can verify a presented key against the hash but can never reproduce it.
- Scopes — each key carries a set of scopes that bound what it can do, so a key minted for one purpose cannot be repurposed for another.
eck_live_ keys as production secrets.Rate limits & plan-gated API
The API enforces rate limits per key, so a runaway client or a leaked key cannot exhaust an org's resources or credits in a burst. API access is itself plan-gated — available on Team, Growth, and Enterprise, and disabled on Starter and Pro.
| Starter / Pro | No API access |
| Team / Growth / Enterprise | API access enabled, rate-limited per key |
Defense in depth
The controls compound. Every path into the system is authenticated (org-scoped, hashed keys), isolated (RLS on every table), bounded (scopes and rate limits), governed (the trust gates from the Trust & Governance chapter), metered (per-run credit accounting), and audited (the per-plan audit log).
Example · A leaked test key, contained
Suppose an eck_test_ key leaks. It only resolves to its own organization, so it can never touch another tenant's data — RLS forbids it. Its scopes bound it to the operations it was minted for. Its rate limit caps how fast it can be abused. Every call it makes is metered against that org's credits and written to the audit log, so the abuse is visible and the key can be rotated — and because only a hash was ever stored, rotating it fully invalidates the leaked secret.
◳ Screenshot
A layered security diagram: an inbound request passing through concentric rings — API key auth (eck_ prefix, SHA-256) → scopes → per-key rate limit → plan gate → RLS org isolation → trust gates → credit meter → audit log — reaching the data at the center.