Skip to content
Looms
Documentation
On this page

Authentication and tenancy

Looms hosts expose execution APIs. Your application supplies authentication, authorization, and tenant ownership. A runId is an identifier, not a secret or permission token.

Authorize requests before forwarding them#

  1. Authenticate a session or service identity.
  2. Resolve the run's owner from your authoritative database.
  3. Authorize the requested operation: viewing history, sending a message, making a decision, or cancelling work.
  4. Validate and construct an allowed event on the server.
  5. Forward only the authorized request to Looms.

Enforce this for reads and SSE subscriptions as well as writes. Every /runs/:id path exposes run data. For new runs, generate/assign ownership on the server; do not trust a tenant ID or arbitrary run ID from a browser.

Do not expose unrestricted event ingestion#

A valid schema proves a payload's shape, not its authority. An untrusted client must not forge internal lifecycle events, payment outcomes, or another person's approval. Prefer purpose-specific application endpoints that accept a user intent and construct a narrow set of events.

Keep secrets and private events server-side#

Model keys, credentials, and service modules stay on the host. Share only browser-safe catalogs and projections. A UI projection does not redact its input stream: if you send the full log to a browser, that browser can read every event in it. Filter or serve an authorized read model when events contain private information.

Browser and webhook protections#

With cookie sessions, implement your framework's CSRF and origin protections for mutations. Configure CORS deliberately. Use TLS. Validate webhook signatures before parsing them as commands, cap request sizes, rate-limit starts and signals, and verify provider event IDs against a durable deduplication record.

Approval authorization#

Authorize the actual approver and operation, not merely the existence of an approval ID. Handle concurrent decisions and late replies in the same server-side approval handler. Record who decided and which inputs they reviewed without placing secrets in events.

Restrict access to the execution host#

The deployment guide disables the public workers.dev endpoint by default. Call the Worker through a private service binding or configure an authenticated gateway before enabling a public route. A service binding restricts access to the host but does not replace per-user authorization in your gateway.