How Effective Access Is Calculated

Effective access is the policy result for one principal, action, and target. SteelEngine recalculates this result from current policy; it does not trust a role label cached in the client.

Evaluation inputs

An access decision includes:

1. The authenticated principal, usually user:<id>.
2. The organization and workspace domain containing the target.
3. The target object, such as a workflow, table, or workspace:<id>:documents collection.
4. The requested action, such as read, create, update, execute, or manage_members.
5. Direct and group role assignments that apply to the domain.
6. Role inheritance.
7. Allow and deny effects.
8. Required plan entitlements and runtime predicates.
9. API-key scope caps, when applicable.

Additive assignments

Applicable allow grants are combined. Suppose Dana has:

• Viewer assigned organization-wide
• Document Editor assigned directly on Workspace A
• Workflow Runner through the Operations group on Workspace A

In Workspace A, Dana receives the union of all three paths. In Workspace B, only the organization-wide Viewer assignment applies.

Role inheritance

If Document Editor inherits Viewer, assigning Document Editor supplies both roles' permissions. Inheritance is transitive and cycle-safe. The access inspector shows the granting chain so an inherited permission is not mistaken for a direct grant.

Explicit deny precedence

The policy result requires at least one applicable allow and no applicable deny. If the same request matches both, deny wins.

allow workspace:read_documents
deny  workspace:read_documents
result: denied

This rule applies regardless of whether the deny came from a direct role, inherited role, group, or organization-wide policy.

Scope matching

Resource permissions can be more specific than the assignment. A role may permit document reads but not folder reads, or workflow execution but not workflow deployment.

Product entitlements and predicates

A catalog permission can carry extra requirements. Examples include an organization plan, an Enterprise entitlement, resource lifecycle state, ownership, or explicit confirmation for a high-impact action.

Holding the role grant is necessary but not always sufficient. The final decision includes these requirements.

API keys use an AND rule

API-key scopes are not roles. Their read, write, and admin labels are a transport-level ceiling retained for key compatibility.

key owner's PBAC permission
AND key scope covers the target and required level
= request allowed

Examples:

• An owner can update documents, but a read-scoped key cannot update them.
• A key has write scope, but an owner with document-read only cannot update them.
• An organization key granted Workspace A cannot be used against Workspace B.

The same rule applies to SteelEngine MCP API keys.

MCP discovery versus execution

tools/list is a least-privilege discovery view. It can omit an entire domain tool or prune individual operations that the authenticated principal cannot use in any reachable workspace.

tools/call always authorizes again against the requested target. Discovery is advisory and never becomes proof of access. An advertised operation can still be denied for a different workspace, a changed role, an explicit deny, a key-scope mismatch, or an entitlement requirement.

Troubleshooting a denial

1. Open Organization Settings → Access → People.
2. Select the person and, when relevant, the workspace.
3. Review direct, group, and organization-wide roles.
4. Expand the permission family for the denied action.
5. Check inherited roles and explicit denies.
6. If using an API key, verify its workspace or workflow grants.
7. Check whether the permission requires a paid or Enterprise entitlement.
8. Review Access → Activity for the change that affected access.