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 (see the org endpoints).

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. The fifth column is the token injected into a run, which is ceilinged at member.

A run never executes above member: 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 the descriptor's 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 (the rule above). The member and invitation endpoints list, re-role, and remove members.

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 (see the audit endpoint).

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 the one permanent exception in the callout above: they can never mint another credential. Revoke a key the moment it leaks; the full value is shown only once, at creation.