--- title: "Tenant policies: binding, permissions, and authoring" description: "Explains how Duale AI binds Tenant policies to identities and groups, how permissions pair actions with resource patterns, and how to author narrow policies." lang: en status: public-preview lastUpdated: 2026-10-18 url: https://dev.duale.ai/en/docs/identity/policies --- ## AI-generated summary This page covers policy binding and permission accumulation, action and resource pattern syntax, policy authoring and binding, access review, and the action catalogue. - Policy binding and permission accumulation across groups and direct identities. - Action and resource pattern syntax, including wildcards and placeholders. - Authoring and binding a narrow Tenant policy. - Reviewing access across all permission sources before changes. - Finding exact actions in the scoped action catalogue. Summaries were generated by AI. --- Bind a policy to a custom group to make access follow membership. Bind it directly to one person or Agent Identity when that relationship must stay individual. In either case, Duale AI allows a request only when a permission matches its action and resource for the resolved [identity](https://dev.duale.ai/en/docs/identity.md). ## Follow identity, binding, policy, permission A policy can bind directly to `user:`, `agent:`, or `group:`. A group holds policies for its members; it never acts. Duale AI combines the direct policies on the identity with policies on every group it belongs to. Permissions from those bindings accumulate. The list of policies bound directly to a subject is not a list of all policies the identity inherits through groups. For example, `payments-readers` holds a policy with `action = agent:read` and `resource_pattern = agent:payments-*`. An Agent Identity in that group can read `agent:payments-invoice-review`. The same policy does not allow reading `agent:support-triage`. A policy bound directly to that Agent Identity can add other access without changing the group's policy. Tenant policies contain no `deny` entry. A narrower policy cannot subtract access supplied by another binding or a [supplied policy](https://dev.duale.ai/en/docs/identity/default-policies.md). A [Library Grant](https://dev.duale.ai/en/docs/libraries/access.md) is a separate rule on one Library path that can refuse access even when a Tenant policy allows it. A policy also cannot replace an operation's stronger [sign-in requirement](https://dev.duale.ai/en/docs/identity/credentials-and-lifecycle.md#reach-the-assurance-level-an-operation-requires) or authorize an external action performed by an SDK or MCP Tool. ## Read one permission as action plus resource pattern | Field | Meaning | | ------------------ | ---------------------------------------------------------------------------------- | | `action` | One exact operation from the scoped action catalogue, such as `agent:read`. | | `resource_pattern` | The resource names on which that operation is allowed, such as `agent:payments-*`. | A Tenant-authored policy must name exact, recognized actions. It cannot use an action wildcard such as `agent:*` or `agent:read*`; an action wildcard can silently include a future operation. The selected action must apply to the resource type it names. A resource pattern can name one resource exactly or use a final `*` to match a prefix. Thus `agent:payments-*` includes later Agent Identities with that prefix. A bare `*` reaches every resource type for the matching action; prefer the narrowest typed pattern that covers the intended resources. The authoring screen starts from one chosen resource scope rather than copying every scope of its source policy. A Task resource is `task:/`. Use `task:*` for every Task in the Tenant or `task:/*` for every Task of one Agent Identity. A Library resource is `library:`, named by the Library's current path; [Library access](https://dev.duale.ai/en/docs/libraries/access.md#access-follows-the-library-path) explains what that means for a rename or a shared path. A resource pattern can use two placeholders. `{self}` stands for the verified caller's identity ID, and `{tenant_id}` for the verified Tenant. Duale AI replaces every occurrence, in any position, before it matches the pattern. For the Agent Identity `agent:payments-invoice-review`, `task:{self}/*` matches its own Tasks, and `library:agent/{self}/*` matches Library paths under `agent/payments-invoice-review/`. For a person, `{self}` is that person's ID, so the policy binding decides whose resources a pattern names. Duale AI refuses a pattern that contains any other brace. Conferring a pattern that contains `{self}` requires the whole resource type, such as `task:*` or `library:*`, because each recipient binds its own ID; permission on only your own resources cannot confer it. The SDK acts on the calling Agent Identity’s own Tasks. A grant on another Agent Identity’s Tasks lets a caller act on the Tasks it names. Duale AI decides each request for the verified caller only, on the resources the request names. Accepted work runs under the named Agent Identity, with its Tools, Library access, and Task attribution. Policy permissions inspect the requested action and resource, not Task input, Tool arguments, Task Context, request time, network address, device state, or authentication method. [Identity limits](https://dev.duale.ai/en/docs/identity/limits.md) explains what a permission decision does and does not establish. ## Author a narrow Tenant policy To author or change a Tenant policy, the acting person or Agent Identity needs `profile:manage_policy` on `policy:`; a rename also checks the new name. The supplied Administrator policy carries that action, but group membership never replaces the contextual [identity, action, and resource decision](https://dev.duale.ai/en/docs/identity.md#apply-zero-trust-to-each-authorization-question). A Tenant-authored policy can name any action the catalogue lists, `profile:manage_policy` included. Your own permissions are the bound: you write what you hold. In the Dashboard, open **Access Policies**, choose **New policy**, and start from a supplied or Tenant policy. Choose one resource scope. Review the exact actions retained from the source, remove those the new policy does not need, name the policy, and confirm its action–resource pairs. The copy is detached: later edits to its source do not update it. The Platform refuses an unrecognized action, a pair outside its resource scope, or a grant the author cannot confer. A newly saved policy is unbound and grants nothing. Binding it is a separate authorized change: Duale AI checks `profile:manage_binding` on the target `group:`, `user:`, or `agent:` subject and whether the actor can confer its original action–resource pattern pairs. To bind it in the Dashboard, open **Access Groups**, choose a custom group, then use **Policies** > **Assign Policy**. The Dashboard binds policies to custom groups only, so use the custom-group flow, or contact your Tenant's technical owner for a direct person or Agent Identity binding. [Members and groups](https://dev.duale.ai/en/docs/identity/members-and-groups.md) covers that membership path. An Agent Identity holds whatever an administrator confers on it, through a direct binding or through a group, up to what that administrator holds. Review its direct policies and group memberships together, using the same method as for a person. Duale AI recommends keeping platform permission management with people. An automated identity that can change who holds what makes one compromised process enough to rewrite your access model, and the change still carries that identity as its actor rather than a person you can ask. Weigh that against the automation you gain: an operator that provisions Agent Identities and binds their policies is exactly what this supports. The choice stays yours, because this is advice and not a rule—an administrator holding `profile:manage_policy` or `profile:manage_binding` can confer either one on an Agent Identity. Decide it once, deliberately, and record why. ## Review access across every source of permission Before changing access, combine these sources for the person or Agent Identity: 1. Check the [automatic baseline and supplied human tiers](https://dev.duale.ai/en/docs/identity/default-policies.md). Ask your Tenant's technical owner to verify the person's tier memberships when needed; the Dashboard has no tier-membership editor. 2. In **Access Groups**, check the **Members** list of each relevant custom group, then review the group's **Policies** and each policy's **Permissions**. 3. Ask your technical owner to read the identity's direct policy bindings and inspect those policies; the Dashboard shows bindings for custom groups only. This read excludes inherited policies and omits policies the reader cannot access. 4. For a named Library, also review its [Library Grants](https://dev.duale.ai/en/docs/libraries/access.md), which can refuse an operation that a Tenant policy allows. If you cannot read all relevant memberships and policies, ask an authorized owner to complete the review. A filtered list is not a complete access report, and seeing no policy in it does not prove that the identity has no access. After a change, test one intended operation and one neighboring operation that must remain refused. A refusal proves this policy's narrowness only when no other direct policy, group, supplied policy, or Library Grant allows the same request. Review the subject's complete access before attributing a result to the policy just changed. ## Find exact actions at their feature owner The scoped catalogue lists actions available for policy authoring. The feature pages state what each public operation does and which action it checks: - [Task operations](https://dev.duale.ai/en/docs/sdk/reference.md#task-actions). - [Agent Identity and token lifecycle](https://dev.duale.ai/en/docs/identity/credentials-and-lifecycle.md#check-the-permission-for-each-lifecycle-operation). - [Library operations and Grants](https://dev.duale.ai/en/docs/libraries/access.md#what-each-action-allows). - [Model-route configuration](https://dev.duale.ai/en/docs/model-routing/provider-capabilities.md#access-needed-to-change-a-route) and [MCP Connections](https://dev.duale.ai/en/docs/tools/mcp-connections.md). - [Audit reads, exports, and proofs](https://dev.duale.ai/en/docs/security/evidence-and-audit.md#what-you-can-query-and-what-you-cannot). Directory, group, and policy administration also requires its own authorized operation. The catalogue names which actions can be granted; seeing an action there does not give the reader that permission. ## Related content - [Tenant identity and access management](https://dev.duale.ai/en/docs/identity.md) - [Library access: Grants, policies, and path-based rules](https://dev.duale.ai/en/docs/libraries/access.md) - [Identity limits: allow results, policies, and audit events](https://dev.duale.ai/en/docs/identity/limits.md) - [Privacy policy: data collection, use, and retention](https://dev.duale.ai/en/legal/privacy.md) - [Agent Identity credentials and lifecycle](https://dev.duale.ai/en/docs/identity/credentials-and-lifecycle.md) - [Security controls for your agent platform](https://dev.duale.ai/en/product/security.md) --- ## Sitemap See the full [Markdown sitemap](https://dev.duale.ai/sitemap.md) for all pages.