--- title: "Default policies: permissions, tier review, and audit" description: "Compares the five supplied access policies' Task and Library permissions, and covers tier review and policy-change audit records." lang: en status: public-preview lastUpdated: 2026-10-13 url: https://dev.duale.ai/en/docs/identity/default-policies --- ## AI-generated summary This reference covers the five supplied access policies, their Task and Library operations, tier-change review steps, and platform policy-change audit records. - The five supplied policies and their group assignments. - Task operations permissions across supplied policy groups. - Library operations permissions across supplied policy groups. - Access review steps before a tier change. - Platform policy-change audit record interpretation. 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](https://dev.duale.ai/en/docs/identity.md) defines who can act and how groups contribute access. ## Review the five supplied policies | Supplied policy | Group display name | Access to review first | | --------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Administrator | `tenant-admins` | Broad Tenant operations, including every Task operation, policy and tier management, Agent Identity token issuance, Library access, and Audit export. | | Editor | `tenant-editors` | Reads Profile, billing, and analytics; changes configuration; creates, continues, reads, and stops any Task and runs 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. | | Viewer | `tenant-viewers` | Reads across the Tenant: members, groups, and policies; configuration; billing; analytics; Tasks; Libraries; the Tool catalog; Agent Identities and their token metadata, never a token value; and Audit records and their proofs. It cannot create, continue, or stop Tasks, or export Audit records by default. | | Agent default | `all-agents` | Obtains the platform token its process presents, creates Tasks and runs its Tool Host only on itself, reads, continues, and stops its own Tasks, starts Library uploads, and creates, reads, and writes Libraries under its own `agent//` path. Every Agent Identity inherits it; it does not administer the Tenant. | | Tenant-member identity read | `tenant-members` | 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 checked on the Tenant, so supplied policies grant it on `tenant:*`; a [Library Grant](https://dev.duale.ai/en/docs/libraries/access.md) cannot carry it. The Administrator's broad policy also does not override a Library-specific refusal. [Tenant access policies](https://dev.duale.ai/en/docs/identity/policies.md) explains how supplied, direct, and custom-group permissions accumulate. ### Task operations in the supplied policies | Action | `tenant-admins` | `tenant-editors` | `tenant-viewers` | `all-agents` | | --------------------------------------------------------------------- | --------------- | ---------------- | ---------------- | --------------- | | `agent:create_task` | `*` | `*` | — | `agent:{self}` | | `agent:continue_task` | `*` | `*` | — | `task:{self}/*` | | `agent:read_task` | `*` | `*` | `*` | `task:{self}/*` | | `agent:stop_task` | `*` | `*` | — | `task:{self}/*` | | `agent:register_tools`, `agent:heartbeat`, `agent:deregister_process` | `*` | `*` | — | `agent:{self}` | By default, an Agent Identity creates Tasks and runs its Tool Host only on itself, and reads, continues, and stops its own Tasks. A policy author with authority to confer the permission can grant more, such as `agent:stop_task` on `task:/*`. The grantee can then stop Tasks of that Agent Identity. A grant to create or continue its Tasks permits work with that Agent Identity’s Tools, Library access, attribution, and Tenant billing. The Tenant is responsible for that grant. [Task actions](https://dev.duale.ai/en/docs/sdk/reference.md#task-actions) lists the operations, and [Tenant access policies](https://dev.duale.ai/en/docs/identity/policies.md#read-one-permission-as-action-plus-resource-pattern) explains `{self}` and access through the HTTP API. ### Library operations in the supplied policies | Action | `tenant-admins` | `tenant-editors` | `tenant-viewers` | `all-agents` | | --------------------------------- | --------------- | ---------------- | ---------------- | ------------------------ | | `library:upload` | `tenant:*` | `tenant:*` | — | `tenant:*` | | `library:read` | `library:*` | `library:*` | `library:*` | `library:agent/{self}/*` | | `library:write` | `library:*` | `library:*` | — | `library:agent/{self}/*` | | `library:delete`, `library:admin` | `library:*` | — | — | — | `library:*` covers every Library path in the Tenant. By default, an Agent Identity creates, reads, and writes Libraries only under its own `agent//` path, which includes the Task attachment Libraries the SDK creates for it. Reaching another Agent Identity's folder, deleting a Library, or managing its Grants needs another policy or Grant. [Library access and isolation](https://dev.duale.ai/en/docs/libraries/access.md#who-can-grant-what) explains creation and Grants. ## 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](https://dev.duale.ai/en/docs/libraries/access.md#a-separate-tenant-is-the-boundary-against-a-person) owns that decision. Make a tier change through a Profile API integration using the acting person's or Agent Identity's platform token. The Dashboard has no supplied-tier membership editor, so contact your Tenant's technical owner if your organization has no such integration. 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`. The caller must also meet the operation's [assurance requirement](https://dev.duale.ai/en/docs/identity/credentials-and-lifecycle.md#reach-the-assurance-level-an-operation-requires). Three further rules apply: - `profile:manage_group` authorizes group work, never a tier change. - A Tenant-authored policy can carry `profile:manage_tier` when its author already holds it. - Adding a member 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](https://dev.duale.ai/en/docs/identity.md#apply-zero-trust-to-each-authorization-question) 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](https://dev.duale.ai/en/docs/identity/policies.md#author-a-narrow-tenant-policy), then separately authorize its binding to a suitable person, Agent Identity, or custom group. 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](https://dev.duale.ai/en/docs/security/evidence-and-audit.md) explains query, export, proof, and missing-evidence limits. [Identity limits](https://dev.duale.ai/en/docs/identity/limits.md) explains why the record and an authorization allow do not establish every control. ## Related content - [Library access: Grants, policies, and path-based rules](https://dev.duale.ai/en/docs/libraries/access.md) - [Tenant policies: binding, permissions, and authoring](https://dev.duale.ai/en/docs/identity/policies.md) - [Identity limits: allow results, policies, and audit events](https://dev.duale.ai/en/docs/identity/limits.md) - [Release stages: labels, access, and change policy](https://dev.duale.ai/en/docs/release-stages.md) - [Libraries: document retrieval, access, and corpus design](https://dev.duale.ai/en/docs/libraries.md) - [Tenant identity and access management](https://dev.duale.ai/en/docs/identity.md) --- ## Sitemap See the full [Markdown sitemap](https://dev.duale.ai/sitemap.md) for all pages.