--- title: "Author and bind Tenant access policies" description: "Tenant access policies pair exact actions with resource patterns and bind to groups, users, or Agent Identities to control what each identity can do." lang: en status: public-preview lastUpdated: 2026-09-26 url: https://duale.ai/en/docs/identity/policies --- ## AI-generated summary Bind policies to users, Agent Identities, or groups to control which actions and resources each identity can access through Profile. - Policies bind to user, agent, or group subjects; group policies accumulate with direct bindings. - Each permission pairs one exact action with a resource pattern; action wildcards are not allowed. - Authoring requires profile:manage_policy on the policy; binding requires profile:manage_binding on the target subject. - Tenant policies contain no deny entry and cannot grant profile:manage_policy or add privilege-changing actions. - A Library Grant can refuse access even when a Tenant policy allows the same request. 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, Profile allows a request only when a permission matches its action and resource for the resolved [identity](https://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. Profile 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://duale.ai/en/docs/identity/default-policies.md). A [Library Grant](https://duale.ai/en/docs/libraries/access.md) is a separate, named-Library rule that can refuse access even when a Tenant policy allows it. A policy also cannot replace an operation's stronger sign-in requirement or authorize an external action performed by a customer 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. 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://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, a person 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://duale.ai/en/docs/identity.md#apply-zero-trust-to-each-authorization-question). A Tenant-authored policy cannot grant `profile:manage_policy`. 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: Profile 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**. Direct person and Agent Identity bindings use Profile's subject-policy API, not this Dashboard group flow. That API requires an authorized, signed-in person's request; the Dashboard does not provide a standalone Profile API sign-in flow. If you do not have a user-authenticated API client, use the custom-group Dashboard flow or contact your Tenant's technical owner. [Members and groups](https://duale.ai/en/docs/identity/members-and-groups.md) covers that membership path. Neither a Tenant policy nor a direct binding can add a privilege-changing action to an Agent Identity. A group with Agent Identity members is subject to the same ceiling. 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: - [Agent Identity and token lifecycle](https://duale.ai/en/docs/identity/credentials-and-lifecycle.md#check-the-permission-for-each-lifecycle-operation). - [Library operations and Grants](https://duale.ai/en/docs/libraries/access.md#what-each-action-allows). - [Model-route configuration](https://duale.ai/en/docs/model-routing/ownership-and-approvals.md#map-product-access-to-the-actions) and [MCP Connections](https://duale.ai/en/docs/tools/mcp-connections.md). - [Audit reads, exports, and proofs](https://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 - [Identity policy limits and access boundaries](https://duale.ai/en/docs/identity/limits.md) - [Library access: grants, actions, and refusal precedence](https://duale.ai/en/docs/libraries/access.md) - [Tenant identity and access management](https://duale.ai/en/docs/identity.md) - [Supplied access policies and tier permissions](https://duale.ai/en/docs/identity/default-policies.md) - [Design Library layouts by reader group](https://duale.ai/en/docs/libraries/design.md) - [Document Libraries for agent Tasks](https://duale.ai/en/docs/libraries.md) --- ## Sitemap See the full [Markdown sitemap](https://duale.ai/sitemap.md) for all pages.