Orgs, roles & audit

Boardwalk is multi-tenant from the first run. Everything you build, every secret, every run, and every dollar of usage belongs to an organization, and people reach it through a role. This page is the operator's view: who can do what, how people get in, and the record of what happened.

Organizations

An org is the tenant boundary. It owns workflows, runs, secrets, inference providers, API keys, billing, and the audit log; nothing crosses between orgs, and a request for a resource in an org you're not in answers 404, not 403, so ids can't be probed. An org has a slug (its identity in URLs and the API) and a display name. Anyone signed in can create one and becomes its owner:

POST /v1/orgs   { "name": "Acme", "slug": "acme" }

Boardwalk owns orgs and memberships directly (identity is the only thing delegated to the sign-in provider), so roles, invitations, and the audit trail are first-class platform data, not a bolt-on.

Roles

Every membership carries one of four roles. They nest: each does everything the one below it can, plus more. The threshold for an action is fixed, so access is easy to reason about.

Role	Can
`viewer`	Read workflows, runs, schedules, and providers; see its own audit entries. Cannot trigger a run or change anything.
`member`	Everything a viewer can, plus author: create and update workflows, trigger and cancel runs, and use managed inference. This is the day-to-day builder role.
`admin`	Everything a member can, plus run the org: manage secrets and inference providers, manage members and invitations, delete workflows and runs, set the security policy, manage billing, and read the full audit log.
`owner`	Everything an admin can, plus delete the org and transfer ownership.

A run never executes above member: its injected token is ceilinged there, so a workflow can read what it's allowed and trigger work, but can never delete the org or manage credentials, no matter what its code asks for. See permissions for narrowing a single run further.

Members & invitations

Admins invite by email and assign a role; the invitee accepts and joins. Inviting mints access to the org, so it is deliberately gated to a logged-in dashboard session: never an API key, never an agent, never MCP. That keeps a prompt-injected workflow from adding an attacker to your org.

POST   /v1/orgs/acme/invitations   { "email": "dev@acme.com", "role": "member" }
GET    /v1/orgs/acme/members
PATCH  /v1/orgs/acme/members/:userId   { "role": "admin" }
DELETE /v1/orgs/acme/members/:userId

Security policy

An admin sets org-wide policy in Settings → Security (or PATCH /v1/orgs/:slug/security):

Require two-factor. Members without 2FA are blocked from the org until they enable it; the same gate applies to the API and MCP, not just the dashboard.
Allowed email domains. Restrict who can be invited or join to a set of domains, so membership tracks your company directory.
Run retention. How long run history and its logs are kept before they age out.

The audit log

Every state-changing action is recorded: who (a user or a workflow), what they did, the resource, and the before and after. Admins see the whole org's log; members and viewers see only their own entries. Filter by actor, resource, or time, and page through it like any list:

GET /v1/orgs/acme/audit?resourceType=workflow&limit=50

Because a run acts as its own principal (a workflow, not a person), its writes show up in the log attributed to the workflow, so an automated change is as traceable as a human one.

Machine access

People use roles; machines use API keys. A key belongs to one org, carries a role, and can be narrowed to a list of scopes and a monthly spend cap. Keys can do anything their role and scopes allow, with one permanent exception: they can never mint another credential (write a secret, mint a key, wire a provider, invite a member). Those stay session-only, so a leaked key can never widen its own blast radius. Revoke a key the moment it leaks; the full value is shown only once, at creation.