--- title: "Identity policy limits and access boundaries" description: "Tenant policy allow results answer one contextual question about identity, action, resource, and Tenant, and do not guarantee stronger authentication or external outcomes." lang: en status: public-preview lastUpdated: 2026-09-26 url: https://duale.ai/en/docs/identity/limits --- ## AI-generated summary Use these limits to decide whether a Tenant policy is enough for a control, covering what an allow result does and does not prove. - An allow result answers one contextual question about a resolved identity, action, resource, and Tenant. - Tenant policies contain no deny rule; a Library Grant refusal wins over a Tenant-policy allow. - An Agent Identity does not split a Tenant's model pool, provider credentials, or cost view. - A policy change record does not state that every member's effective access changed. - A policy allow does not waive a separate sign-in or step-up requirement on an operation. Summaries were generated by AI. --- Use these limits when deciding whether a Tenant policy is enough for a control. An allow result answers one contextual question about a resolved identity, action, resource, and Tenant. It is not proof of stronger authentication, a customer's approval, a fixed Agent behavior, or an external action's outcome. ## An allow result is not authentication assurance Profile resolves the request's Tenant and [person or Agent Identity](https://duale.ai/en/docs/identity.md) from verified authority before it evaluates access. A service credential authenticates an internal calling channel only; it does not become a Tenant actor or carry Tenant permissions. A policy allow does not waive a separate sign-in or step-up requirement on an operation. A group and an audit-only `system` origin cannot authenticate at all. Membership in a named tier does not bypass the [action–resource decision](https://duale.ai/en/docs/identity.md#apply-zero-trust-to-each-authorization-question), and a last-holder recovery rule can refuse a permitted change but cannot authorize one. The same action can be refused for another resource or Tenant. Cached authorization and credential consumers can also have different propagation windows after an access or token change. Follow the operation's [credential and revocation guidance](https://duale.ai/en/docs/identity/credentials-and-lifecycle.md#allow-for-authorization-propagation-separately) and verify the intended operation after its stated window; do not infer immediate revocation from a policy edit. ## A policy is not every access boundary Tenant policies add permissions from direct identity bindings and group membership. They contain no deny rule; a narrower policy does not subtract access supplied by another policy or a supplied human tier. An Agent Identity cannot hold privilege-changing permissions, including through a group. [Tenant access policies](https://duale.ai/en/docs/identity/policies.md) owns those combination and authoring rules. A [Library Grant](https://duale.ai/en/docs/libraries/access.md) can allow or refuse one concrete person or Agent Identity on one Library; a refusal wins over a Tenant-policy allow. A Library Grant does not isolate individual documents, limit one Task to its attachments, or determine which Library Tools an Executor exposes. Library access explains each boundary. An Agent Identity bounds its credential, available Tool assignments, Task attribution, Task events, and its root-Task history view. It does not split a Tenant's model pool, provider credentials, configuration, or cost view, and it does not pin an Agent's prompt or algorithm. Choose another Tenant when that broader separation is required; [plan the deployment](https://duale.ai/en/docs/model-routing/plan-deployment.md) owns the exact Tenant boundary. An IAM allow never authorizes a customer Tool's external Effect. [Secure integration](https://duale.ai/en/docs/security/secure-integration.md) owns the separate customer-side decision and repeat-safety controls. ## An audit event is not an effective-permission calculation When a platform-supplied policy version changes, Profile publishes a change record into each eligible Tenant's audit history. A Tenant created at the new version does not receive earlier transitions. The record covers policy definition, supplied-group assignment, and resulting group-level grant changes; it does not say that every member's effective access changed. Its `system` origin names platform provenance, not an acting user, Agent Identity, or service principal. [Default policies](https://duale.ai/en/docs/identity/default-policies.md) explains how to review the change. The audit log does not record every cached authorization decision, and a proof of an event's stored canonical text does not verify its separately held actor context or independent append-only anchoring. [Evidence and audit](https://duale.ai/en/docs/security/evidence-and-audit.md) owns the complete record inventory, query and export limits, and proof procedure. For limits outside IAM, read [scope and limits](https://duale.ai/en/docs/scope-and-limits.md). ## Related content - [Author and bind Tenant access policies](https://duale.ai/en/docs/identity/policies.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) - [Model routing contract and runtime limits](https://duale.ai/en/docs/model-routing/contract-and-limits.md) - [Design Library layouts by reader group](https://duale.ai/en/docs/libraries/design.md) --- ## Sitemap See the full [Markdown sitemap](https://duale.ai/sitemap.md) for all pages.