Permissions and Access Control

ProvenanceOne uses a three-role RBAC model (admin, editor, viewer) implemented through platform groups. API keys carry named scopes that gate programmatic access independently of user role. The MCP Gateway enforces per-agent and per-workspace tool-level permissions for all MCP server calls. Every authorisation denial is logged as an authz.denied audit event.

---

What customers need to know

• There are three user roles: admin, editor, viewer. Role assignment is workspace-scoped.
• API keys carry up to 16 named scopes. A key without a required scope is denied regardless of the issuing user's role.
• The approvers platform group grants cross-workflow approval authority independent of base role. A viewer placed in approvers can approve runs they cannot edit.
• Tool-level DLP is enforced by the MCP Gateway for MCP server calls. Gateway policies (allowlist, denylist, redaction) are configured by admin.
• Every access denial produces a logged authz.denied event with the actor, resource, and reason.
• There is no per-workflow or per-resource permission granularity within a workspace at present.

Needs product confirmation: SCIM provisioning support; SAML or OIDC federated SSO availability; per-workflow or per-resource access controls (beyond workspace-level roles); group-level API key issuance.

---

Role model

Three roles

Role	Description
admin	Full workspace control: all operations, member management, billing, settings, API key management, GDPR erasure
editor	Create and modify workflows, agents, skills, connections; trigger and manage runs; approve workflow steps; view audit log
viewer	Read-only access to workflows, runs, agents, approvals, and audit log

Roles are workspace-scoped. A user who is admin in workspace A has no permissions in workspace B unless explicitly assigned there.

platform group mapping

platform group	Corresponding role / function
workspace-admins	admin role
operators	editor role
viewers	viewer role
approvers	Approval authority (cross-workflow, additive to base role)

The approvers group is additive. A member in viewers plus approvers can approve runs but cannot create or edit workflows or agents. This allows approval delegation without elevating base permissions.

---

Full capability matrix

Capability	viewer	editor	admin
View workflows	✓	✓	✓
Create/edit workflows	—	✓	✓
Publish workflows	—	✓	✓
View runs	✓	✓	✓
Cancel/replay runs	—	✓	✓
Create/edit agents	—	✓	✓
Create/edit skills	—	✓	✓
View audit log	—	✓	✓
Approve requests	—	✓ (if in approvers group)	✓
Create/manage connections	—	✓	✓
Reveal secrets	—	—	✓
Manage members	—	—	✓
Manage API keys	—	—	✓
View billing	—	—	✓
Configure notifications	—	—	✓
GDPR erase member	—	—	✓

Note: editor role can approve workflow steps only if the user is also a member of the approvers platform group. An editor not in approvers cannot approve. admin can always approve.

---

API key scopes

API keys are workspace-scoped and carry one or more named scopes from the set of 16 below. A request made with an API key is authorised only if the key holds the specific scope required by the endpoint. The issuing user's role does not elevate or modify key scope — scopes are explicit at key creation time.

Scope	Description
workflows:read	Read workflow definitions
workflows:write	Create and modify workflows
runs:read	Read run records and steps
runs:write	Trigger runs, cancel, replay
approvals:read	Read approval requests
approvals:write	Approve or reject requests
agents:read	Read agent configurations
agents:write	Create and modify agents
skills:read	Read skill definitions
skills:write	Create and modify skills
connections:read	Read connection metadata (no credentials)
connections:write	Create and modify connections
audit:read	Read audit log events
workspace:read	Read workspace settings
workspace:write	Modify workspace settings
secrets:read	Read secret metadata (not values); enables POST /secrets/{id}/reveal

Note: connections:read returns connection metadata only. Credentials are never included in connection API responses regardless of scope.

Note: secrets:read scope enables the POST /secrets/{id}/reveal endpoint which returns the raw secret value. Every reveal is logged as secret.accessed at risk level high. Issue this scope only to integrations that specifically require raw credential access.

Scope selection guidance

Apply the principle of least privilege. Example minimum scope sets:

Integration purpose	Minimum scopes
Trigger workflows and read run status	runs:write, runs:read
SIEM / audit log ingest	audit:read
Read-only workflow inspection	workflows:read
Approval automation	approvals:read, approvals:write
Workspace monitoring (settings, members)	workspace:read

---

Approval permissions

Who can approve

Approval steps in a workflow run require an approver to act before execution continues. The following identities can approve:

• Any user with the admin role
• Any user with the editor role who is also a member of the approvers platform group
• Any user with the viewer role who is a member of the approvers platform group

The approvers group confers cross-workflow approval authority. Membership is managed by admin in Settings → Members.

Delegated grants

editor and admin users can create delegated grants that pre-authorise specific run patterns. A granted approval (grant.approved) is logged at medium risk; a denied grant (grant.denied) is also logged.

Approval audit events

Event	Risk	Description
approval.granted	medium	Approval step approved
approval.rejected	medium	Approval step rejected
approval.reassigned	medium	Approval step reassigned to another approver
approval.sla_breach	high	Approval SLA exceeded without action
grant.approved	medium	Delegated grant created
grant.denied	medium	Delegated grant denied

---

MCP Gateway tool permissions

All MCP server tool calls from agents are routed through the MCP Gateway before being dispatched to the target MCP server. The gateway evaluates the active policy for the MCP server connection and applies:

• Tool allowlist: only the named tools are permitted; all others are denied
• Tool denylist: the named tools are blocked; all others are permitted
• Input redaction: configured rules are applied to the tool call inputs before they leave the gateway
• Output redaction: configured rules are applied to tool responses before they are returned to the agent

When a tool call is blocked by a denylist or allowlist policy, a policy.violation event is emitted to the audit log with the matched policy identifier.

Gateway policies are created and managed by admin in Settings → MCP Gateway. Policy changes are logged as gateway_policy.created, gateway_policy.updated, or gateway_policy.deleted.

Needs product confirmation: Whether gateway policies are enforced per-agent, per-workspace, or both; whether agents can be given individual policy overrides distinct from the workspace-level policy.

---

Connection access boundaries

Connection credentials (OAuth tokens, service account keys, API keys used by connections) are stored in the secrets vault and are never returned in any API response regardless of the caller's role or scope. The connections:read scope returns connection metadata only (name, type, status, last-used timestamp).

Credentials are accessed only by:

1. The workflow execution engine, when running an action step that uses a connection
2. the rotation service, during OAuth refresh token exchange
3. POST /connections/{id}/test, when testing a connection

Every access produces a connection.accessed audit event at risk level high.

---

Authorisation denial logging

Every API request that is refused due to insufficient role or missing scope produces an authz.denied audit event with:

• Actor identity and kind (user, integration)
• Resource requested
• Reason for denial (missing role or missing scope)
• Timestamp and IP address

authz.denied is logged at risk level high. Monitoring this event stream provides visibility into misconfigured API keys, access attempts by underprivileged roles, and potential enumeration attempts.

Authentication failures (wrong password, expired JWT) produce auth.failed events, distinct from authz.denied.

---

Admin controls

Control	Location	Role required
Invite members and assign roles	Settings → Members	admin
Add/remove users from approvers group	Settings → Members	admin
Create / revoke API keys	Settings → API Keys	admin
Create / modify gateway policies	Settings → MCP Gateway	admin
View role assignments	Settings → Members	admin

---

Security implications

1. API key scopes are independent of role: an admin who creates an API key with only runs:read cannot use that key to modify workflows. Scopes constrain the key, not the user. Design integrations around minimum required scopes.
2. approvers group enables least-privilege approval delegation: assign users to approvers when they need to approve workflow steps without the ability to modify workflows or agents. This is preferable to elevating them to editor.
3. authz.denied events surface permission misconfigurations: a sudden increase in authz.denied events from an API key typically indicates a scope gap. Review the key's scope set and the endpoint it is calling.
4. No per-resource ACLs within a workspace: all editor role members can read and modify all workflows, agents, and connections in the workspace. Segregation within a single workspace is not supported at present.

---

Configuration steps

Assign a role to a new member

1. Navigate to Settings → Members.
2. Click Invite Member and enter the email address.
3. Select the role (admin, editor, or viewer).
4. To grant approval authority without elevation, also add the user to the approvers group.
5. Send the invitation. The user will authenticate via the identity service and land in the assigned group.

Create a minimum-scope API key

1. Navigate to Settings → API Keys.
2. Click New API Key and enter a descriptive name.
3. Select only the scopes the integration requires (see the scope table above).
4. Copy the key value — it is shown once and not stored in a retrievable form.
5. Scope changes require revoking and reissuing the key.

Create a gateway policy to deny a destructive tool

1. Navigate to Settings → MCP Gateway.
2. Select the target MCP server connection.
3. Add a deny rule for the tool name (e.g. file_delete).
4. Save. The policy takes effect on the next agent execution. A gateway_policy.created event is logged.

---

Auditability

Event	Risk	What it covers
authz.denied	high	API call refused due to insufficient role or scope
auth.failed	high	Login failure
api_key.created	medium	New API key issued
api_key.revoked	medium	API key revoked
api_key.listed	low	API keys enumerated
member.invited	low	Member invited to workspace
member.updated	medium	Member role or group changed
member.removed	medium	Member removed from workspace
gateway_policy.created	medium	Gateway policy created
gateway_policy.updated	medium	Gateway policy modified
gateway_policy.deleted	medium	Gateway policy deleted
policy.violation	medium	Gateway policy triggered on a tool call

---

Limitations and open questions

• No SCIM provisioning: automated user provisioning and deprovisioning from an identity provider directory is not confirmed.
• No per-workflow or per-resource ACLs: workspace roles apply to all resources within a workspace. You cannot grant an editor access to workflow A but not workflow B.
• No SSO/SAML federation confirmation: federated authentication via enterprise IdP (Okta, Azure AD, Google Workspace SAML) is not confirmed.
• Viewer cannot see audit log: viewer role has no access to the audit log. The lowest role with audit read access is editor.
• API key scope changes require revoke-and-reissue: there is no in-place scope modification for existing keys.
• approvers group granularity: the approvers group grants cross-workflow approval authority. Per-workflow approval delegation is not confirmed.

---

FAQ

---

Related pages

• Data Handling and Storage
• Audit Logging
• Security Model Overview
• Approvals
• API Reference