--- title: "Tenant identity and access management" description: "Identify who acts in a Tenant, bind access policies to identities and groups, manage Agent Identity credentials, and interpret audit records." lang: en status: public-preview lastUpdated: 2026-10-07 url: https://dev.duale.ai/en/docs/identity --- ## AI-generated summary This page covers tenant identity types, policy subject separation, and Zero Trust authorization for Tenant access decisions. - Two tenant identity types: user and agent principals. - Policy subjects and audit provenance separation. - Zero Trust applied to each authorization question. - Control navigation for members, policies, credentials, and limits. Summaries were generated by AI. --- Use this section to identify who acts in a Tenant, manage that identity's access, and understand what an access decision or audit record proves. Tenant actions have two possible actors: a person or an Agent Identity. ## Find the control you need - [Members and groups](https://dev.duale.ai/en/docs/identity/members-and-groups.md): invite a person into an existing custom group or change that group's membership. - [Tenant access policies](https://dev.duale.ai/en/docs/identity/policies.md): bind a policy to a group or identity and scope its permissions. - [Default policies](https://dev.duale.ai/en/docs/identity/default-policies.md): review supplied access and platform policy changes. - [Credential lifecycle](https://dev.duale.ai/en/docs/identity/credentials-and-lifecycle.md): create an Agent Identity, rotate its tokens, and retire it safely. - [Identity limits](https://dev.duale.ai/en/docs/identity/limits.md): check what an IAM decision or audit record does not prove. - [Library access](https://dev.duale.ai/en/docs/libraries/access.md): manage allows and refusals on one Library. ## Distinguish the two tenant identities | Tenant identity | What it names | How a request reaches it | | ------------------ | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | `user:` | A person in the Tenant, identified by their Profile user ID | The person signs in, and their identity-provider subject is resolved to that user ID and recorded on a platform token. | | `agent:` | An Agent Identity: a tenant-scoped non-human principal | An Agent Identity API token is exchanged for a platform token that resolves to that Tenant and identity. | The `user_id` is never the identity provider's external subject. A Task request cannot replace the Tenant or Agent Identity resolved from its token by putting another identifier in its body. An Agent Identity names the principal responsible for a Task and its access; it does not name a fixed prompt, algorithm, Tool set, or behavior revision. [Agent harness](https://dev.duale.ai/en/docs/agent-harness.md) owns the distinction between Agent behavior and Agent Identity. An internal service credential authenticates a Platform component's calling channel. It does not create a third tenant identity, receive a tenant policy, or explain who requested a tenant action. There is no `service:` or `operator:` tenant principal. When a component acts on a tenant request, authorization and attribution use the resolved `user:` or `agent:` identity. ## Keep policy subjects and audit provenance separate A policy can bind directly to a `user:` or `agent:` identity or to a `group:` subject. A group contributes its policy permissions to its members, including people and Agent Identities, but a group never authenticates or performs an action. A token is a credential that resolves to an identity; it cannot receive a policy as a separate principal. [Tenant access policies](https://dev.duale.ai/en/docs/identity/policies.md) explains how direct and group bindings combine. The Tenant identity directory lists people by Profile user ID and Agent Identities alongside Tenant-created groups so they can be selected for policy bindings. It does not list platform-supplied capability tiers. Its group entries are policy subjects, not a third kind of Tenant identity. `system` is reserved for the audit record of a platform-supplied policy-version change. It is not a tenant identity, a policy subject, a sign-in method, or an interservice credential. The record identifies platform provenance without inventing a person who approved or performed the change. [Default policies](https://dev.duale.ai/en/docs/identity/default-policies.md) explains what that record means to a Tenant. ## Apply Zero Trust to each authorization question For Tenant access, Zero Trust means a network origin or internal service channel gives no tenant authority by itself. The Platform does not trust a caller-supplied tenant or actor merely because a request arrived from another component. Profile owns policy definitions, bindings, membership, and evaluation. A service sends the request's credential or identity, Tenant, action, and resource to Profile. Profile resolves the actor and context, then returns a contextual allow or refuse decision, not policy definitions for the service to evaluate locally. Authentication requirements can still apply independently of an allowed permission. For every actor-caused IAM change, Profile evaluates the resolved tenant identity, a specific action, and the canonical resource. A person or Agent Identity can administer access when it holds the required permissions and meets the operation's [assurance requirement](https://dev.duale.ai/en/docs/identity/credentials-and-lifecycle.md#reach-the-assurance-level-an-operation-requires). Group membership contributes policy permissions; membership in a group named `tenant-admins` is not a separate authorization gate. Profile can still refuse a permitted change that would confer permissions the actor does not hold or remove the last live recovery holder. Those write constraints never grant an actor authority. Reads are decided by permission for every identity kind. A person and an Agent Identity holding the same permission receive the same permission decision; separate authentication requirements still apply. For example, Analytics Task history and execution traces show a Task only to a caller holding `agent:read_task` on it ([Task actions](https://dev.duale.ai/en/docs/sdk/reference.md#task-actions)). Audit accepts tenant audit events and serves tenant history, exports, and proofs. It does not resolve policies, fetch policy versions, or decide which Tenants receive a platform policy-change record. Like another protected reader, it can ask Profile whether the requester can consume audit history. [Evidence and audit](https://dev.duale.ai/en/docs/security/evidence-and-audit.md) states what those records and proofs establish. ## Related content - [Identity limits: allow results, policies, and audit events](https://dev.duale.ai/en/docs/identity/limits.md) - [Tenant policies: binding, permissions, and authoring](https://dev.duale.ai/en/docs/identity/policies.md) - [Identity and access for AI agents on Zero Trust](https://dev.duale.ai/en/product/identity-and-access.md) - [Library access: Grants, policies, and path-based rules](https://dev.duale.ai/en/docs/libraries/access.md) - [Library design: layout, paths, and Agent Identity reach](https://dev.duale.ai/en/docs/libraries/design.md) - [Agent Identity credentials and lifecycle](https://dev.duale.ai/en/docs/identity/credentials-and-lifecycle.md) --- ## Sitemap See the full [Markdown sitemap](https://dev.duale.ai/sitemap.md) for all pages.