Tenant policies: binding, permissions, and authoring

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.

Follow identity, binding, policy, permission

A policy can bind directly to user:<user_id>, agent:<agent_id>, or group:<group_id>. 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. A Library Grant 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 or authorize an external action performed by an SDK or MCP Tool.

Read one permission as action plus resource pattern

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:<owner_agent_id>/<task_id>. Use task:* for every Task in the Tenant or task:<agent_id>/* for every Task of one Agent Identity. A Library resource is library:<path>, named by the Library’s current path; Library access 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 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:<name>; 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. 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:<name>, user:<user_id>, or agent:<agent_id> 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 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. 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, 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.
• Agent Identity and token lifecycle.
• Library operations and Grants.
• Model-route configuration and MCP Connections.
• Audit reads, exports, and proofs.

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.