Supplied access policies and tier permissions
Supplied access policies define tier permissions and the access to review before a tier change.
Compares the five supplied access policies in Duale AI, explains how to review access before a tier change, and shows how to read platform policy-change audit records.
- Lists Administrator, Editor, Viewer, Agent default, and Tenant-member identity read as the five supplied policies.
- Tiers are additive and a narrower custom policy cannot subtract a supplied grant.
- Tier changes require profile:manage_tier on the tier's canonical group resource, not profile:manage_group.
- Platform policy-change audit records show version diffs, group binding changes, and resulting group-level grant changes.
- Agent default and Tenant-member identity read are automatic baselines, not editable human tiers.
Summaries were generated by AI.
Use this reference to compare supplied access before a tier change. Only Administrator, Editor, and Viewer are human tiers; Agent default and Tenant-member identity read are automatic baselines. In the Dashboard, open Access Policies and inspect each supplied policy’s Permissions list; the table below is a summary. Supplied definitions and group assignments are platform-owned. Identity defines who can act and how groups contribute access.
Review the five supplied policies
- Supplied policy
- Administrator
- Group display name
tenant-admins- Access to review first
- Broad Tenant operations, including policy and tier management, Agent Identity token issuance, Library access, and Audit export.
- Supplied policy
- Editor
- Group display name
tenant-editors- Access to review first
- Reads Profile, billing, and analytics; changes configuration; runs Tasks and Tool Hosts; reads, writes, and uploads to Libraries; creates Agent Identities and lists or revokes their tokens. It cannot issue a token, author a policy, or read Audit by default.
- Supplied policy
- Viewer
- Group display name
tenant-viewers- Access to review first
- Reads Profile, configuration, billing, analytics, Agent Identities, Tasks, Libraries, and Audit proofs. It cannot export Audit records by default.
- Supplied policy
- Agent default
- Group display name
all-agents- Access to review first
- Runs Tasks and Tool Hosts and starts Library uploads. Every Agent Identity inherits it; upload alone does not permit Library creation or tenant administration.
- Supplied policy
- Tenant-member identity read
- Group display name
tenant-members- Access to review first
- Reads members, groups, and Agent Identities. Every person receives it with Tenant membership; it is not an editable tier.
These display names appear in policy bindings, not the Access Groups directory. Permission checks use canonical
group IDs: for example, tenant-admins maps to group:system-tenant-admins. library:upload is a Tenant policy action
checked against library:*; it is not a Library Grant on one selected Library. The
Administrator’s broad policy also does not override a Library-specific refusal. Tenant access
policies explains how supplied, direct, and custom-group permissions accumulate.
Review access before a tier change
Before assigning a tier, inspect its current pairs and the person’s direct policies and other groups. The tiers are additive, not mutually exclusive, and a narrower custom policy cannot subtract a supplied grant. In particular, a Viewer can read every Library in the Tenant by default, while an Editor can change configuration across the Tenant. Use a separate Tenant when a person must not be able to reach those resources; a later Library-specific refusal is not a substitute for a Tenant boundary. Library access and isolation owns that decision.
The Dashboard does not expose supplied-tier membership changes or a standalone Profile API sign-in flow. A
user-authenticated Profile API integration must make the member change. If your organization has none, contact your
Tenant’s technical owner; an Agent Identity token cannot substitute for a signed-in person. Profile authorizes the
change with profile:manage_tier on the tier’s canonical
resource: group:system-tenant-admins,
group:system-tenant-editors, or group:system-tenant-viewers. A platform-supplied policy must provide this action;
profile:manage_group does not authorize a tier change. An addition also requires authority to confer every original
action–resource pattern pair in the tier’s bound policies. Profile can refuse removal of the last live recovery holder
as a separate integrity rule, never as a way to authorize the caller. Identity
owns the common decision model.
Do not treat all-agents or tenant-members as an editable human tier. For narrower additional access, author a
Tenant policy, then separately authorize its binding to a suitable
person, Agent Identity, or custom group. An Agent Identity cannot receive privilege-changing access through that
binding or through group membership. Review one intended operation and one adjacent operation that must remain
refused before relying on the new boundary.
Read a platform policy-change record correctly
When Duale AI changes a supplied definition or which supplied group holds it, Profile records that committed
transition in the audit history of each Tenant eligible for the change. The event has audit-only system provenance.
It identifies the supplied-policy version and distinguishes changed policy-definition pairs, changed supplied-group
assignments, and the resulting grant changes at the group level. A Tenant created under the new version does not
receive earlier transitions.
In Tenant Audit, select Supplied Policy as the resource type and Supplied policy · update as the action, then
open the event. Compare changes_before.version_id with changes_after.version_id. In the diff, added and
removed pair policy actions with resource patterns; group_bindings_added and group_bindings_removed name
group-to-policy assignments; group_grants_added and group_grants_removed show the resulting group-level reach.
This record can show a definition change, a group-assignment change, or both. It does not calculate whether every member gained or lost a permission. For an access review, compare the changed policy and group assignment with the current state in the Dashboard, then inspect the affected people’s or Agent Identities’ other direct and group bindings and any Library Grants. Retain any customer approval in your existing change record; the platform event does not contain that decision. Evidence and audit explains query, export, proof, and missing-evidence limits. Identity limits explains why the record and an authorization allow do not establish every control.