System Manual
Security & Multi-tenancy
How eClips Workforce keeps each organization's data separate with Row-Level Security, and how the public API is protected with hashed keys, scopes, rate limits and a plan check.
One organization, one tenant
Every table that holds customer data is scoped to an organization and protected by Supabase Row-Level Security (RLS). One org cannot read or write another's runs, triage items, trust profiles, credit ledger or documents. Agent state (circuit breakers, trust profiles, usage periods) is keyed by organization too, so one customer's history does not change how agents behave for another.
| agent_runs | Every run belongs to one organization |
| triage items | Exceptions are visible only inside their org |
| agent trust profiles | An agent earns trust separately in each org |
| credit_ledger / credit_usage_periods | Usage and budgets are counted per org |
| agent_circuit_breakers | A breaker that opens for one org does not affect another |
| documents (Storage) | Files are stored 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/run \
-H "Authorization: Bearer eck_live_..." \
-H "Content-Type: application/json" \
-d '{ "agent_type": "invoice_processor", "task": "Process the attached invoice" }'Key prefixes, hashing and scopes
Three things limit the damage if a key or the database leaks:
- Keys start with
eck_live_oreck_test_, so live and test traffic are easy to tell apart. - Only a SHA-256 hash of the key is stored. The full key is shown once, at creation. After that the system can check a presented key against the hash but cannot show the key again.
- Each key carries scopes that limit what it can do, so a key created for one purpose cannot be used for another.
eck_live_ keys as production secrets.Rate limits and the plan check
The API enforces rate limits per key, so a runaway client or a leaked key cannot use up an org's credits in a burst. API access also depends on the plan: it is available on Growth and Enterprise and switched off on Starter, Pro and Team.
| Starter / Pro / Team | No API access |
| Growth | API access, with a daily cap of 50,000 calls and the monthly credit allowance |
| Enterprise | API access with no daily call cap |
How the controls stack up
A request has to get through each of these in turn: a hashed, org-scoped key, the key's scopes, the rate limit, the plan check and RLS. A run that gets through is then held to the confidence bar and the approval gates from the Trust & Governance chapter, and is metered in credits.
Example · A leaked test key, contained
Suppose an eck_test_ key leaks. It belongs to one organization, so it cannot touch another tenant's data. Its scopes limit it to the operations it was created for, and its rate limit caps how fast it can be abused. Every run it starts is metered against that org's credits and shows up in the run history, so the abuse is visible. Revoke the key and create a new one.