Author and bind Tenant access policies

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.

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. 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. A Library Grant 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

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 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:<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 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:<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. 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 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.
• 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.