> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.

# Access & policies

> Who can do what across the workspace — from roles to per-Flow access rules.

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](/reliable/versions/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:

| Type                      | Scope                                             | Where issued                           | Typical use       |
| ------------------------- | ------------------------------------------------- | -------------------------------------- | ----------------- |
| **Personal access token** | Every workspace you belong to. Follows your role. | Settings → Security → API tokens       | Interactive dev.  |
| **Workspace token**       | One workspace. Custom scopes.                     | Settings → Security → Workspace tokens | CI, integrations. |

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.