Skip to main content
Roles set a floor for what members can do. Per-Flow access rules can loosen or tighten it further. Workspace policies apply on top.

​
Layers of access

Access is checked in this order for every action:
  1. Workspace role (Owner / Manager / Member / Viewer).
  2. Per-Flow overrides — a Flow can restrict editors, publishers, or runners beyond the role default.
  3. Workspace policies — org-wide rules (see below).
Deny anywhere in the chain blocks the action.

​
Per-Flow access

Every Flow has three permission fields (Flow settings → Access):
  • Editors — who can change the Draft. Owners + Managers by default.
  • Publishers — who can Publish. Owners + Managers by default.
  • Runners — who can trigger runs (interactively or via API). All members by default.
Tighten:
  • Restrict Publishers to a specific group (only the compliance team can publish the customer-facing Flow).
  • Restrict Runners to a group (only the on-call team can trigger the emergency Flow).
Loosen:
  • Grant Members Publisher rights on the Draft-only prototype Flow.
Access changes are logged (see Audit).

​
Workspace policies

Policies apply to all Flows in the workspace. Settings → Access policies.

​
Publish policies

  • Require simulation on every publish — Publishes are gated on a passing simulation against a nominated dataset. Prevents “hope-based” publishes.
  • Require release notes — no empty release notes accepted.
  • Multi-sign publish — a Manager alone can’t publish; needs a second sign-off. Optional for high-stakes Flows.

​
Approval policies

  • Require approval webhook URL — Flows without a webhook fail configuration checks. Ensures approvals never surface in-app-only.
  • Reviewer role restriction — only members in a specific group can be approvers.

​
Data policies

  • Prohibit trace payload retention beyond N days — override any Flow that tries to keep longer.
  • Require redaction on all foundry pipelines — all pipelines must include a PII redaction step.

​
CLI / API policies

  • Restrict CLI publish to CI-only — human personal tokens can’t publish; only workspace tokens can. Adds an audit-trail requirement.
  • Restrict destructive commands to Owners — flows delete, documents delete, etc. only usable by Owners.
Policies are enforced at the platform layer — the CLI and app both respect them.

​
Personal vs. workspace tokens

Two token types for API/CLI access: Workspace tokens are the right pick for automation — narrower scope, per-service revocation, and no personal identity implication.

​
SSO and access

For SSO-managed workspaces:
  • Roles come from SCIM attributes or group mappings.
  • Local role changes are disabled (the app shows a “SSO-managed” indicator).
  • Group memberships (for per-Flow access) also come from SSO groups.
Local users can be added as Guests (short-lived, out-of-band) if needed — Settings → Members → Add guest.

​
Access recipes

​
Only Compliance publishes the customer-facing Flow

  1. Create a “Compliance” group in Members.
  2. Add compliance team members to the group.
  3. On the Flow: Access → Publishers → Only compliance group.

​
External auditor gets read-only access

  1. Invite the auditor as a Viewer.
  2. If needed, restrict them to specific Flows: Flow → Access → Runners → Exclude viewer group.
  3. Or don’t invite — instead, share a report export.

​
CI-only publishing

  1. Settings → Access policies → Restrict CLI publish to workspace tokens.
  2. Issue a CI workspace token, use it in CI.
  3. Human personal tokens can no longer publish — must go via CI.

​
Access checks in Traces

The Trace view respects access. Members without payload-read permission see:
  • Metadata (timestamps, cost, verdict).
  • Redacted prompts and tool arguments.
  • The final answer only if their access allows it.
Configure payload access under Flow settings → Access → Payload visibility.

​
Debugging “why can’t I do X?”

  1. Check your role: Settings → Members → your entry.
  2. Check the Flow’s per-Flow access: Flow → Settings → Access.
  3. Check workspace policies: Settings → Access policies.
  4. Ask an Owner if you think you should have access.
Every access denial is logged with the specific rule that blocked it — an Owner can pull the audit entry to see exactly why.