Scoped runtime reads
Agents and clients read only records tied to trusted identity, task token, work order, callback token, or result contract reference.
Supabase RLS + Service Role Policy Pack v1
Runtime records need table-level boundaries.
The policy pack defines how Wever Labs runtime tables separate public discovery from controlled writes. Runtime functions use server-side service-role access. Agent and client reads stay scoped by access policy, task token, credential envelope, and allowed tool route.
What this protects
Each runtime table gets a clear access posture.
The policy pack keeps intake, Work Orders, execution bindings, provider events, credit funding, result contracts, receipts, callbacks, ledgers, and attestations inside controlled OS records.
Service-role-only writes
runtime functions perform table writes with server-side service-role access. Public clients do not write directly into runtime tables.
Webhook confirmation boundary
Provider events land through verified function paths before creating credit funding events, settlement receipts, and run eligibility records.
Policy-visible operating trail
Access decisions, failed checks, provider events, callback attempts, retries, and operator overrides can be preserved as audit events.
RLS posture
The OS runs through controlled functions, not open tables.
Wever Labs uses public pages and machine-readable schemas for discovery. Runtime records use RLS, table policies, service-role functions, scoped access keys, callback validation, and audit events.
Separate
Public discovery files stay readable. Runtime tables stay policy-bound.
Scope
Agent, client, credential envelope, task token, and allowed tool route define access.
Write
Server-side functions create runtime records with service-role access and validation.
Return
Results, receipts, callbacks, ledger references, and attestations are exposed through scoped return paths.
Audit
Security events preserve the proof trail for sensitive runtime actions.
Deployment assets
Policies that bind into the activation path.
Apply the policy SQL after the base runtime tables exist. Use the policy manifest to confirm which tables are read-scoped, write-scoped, service-role-only, or public-discovery only.