Tenant identity and access management
Identify who acts in a Tenant, bind access policies to identities and groups, manage Agent Identity credentials, and interpret audit records.
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: invite a person into an existing custom group or change that group’s membership.
- Tenant access policies: bind a policy to a group or identity and scope its permissions.
- Default policies: review supplied access and platform policy changes.
- Credential lifecycle: create an Agent Identity, rotate its tokens, and retire it safely.
- Identity limits: check what an IAM decision or audit record does not prove.
- Library access: manage allows and refusals on one Library.
Distinguish the two tenant identities
| Tenant identity | What it names | How a request reaches it |
|---|---|---|
user:<user_id> | 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:<agent_id> | 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. |
- Tenant identity
user:<user_id>- What it names
- A person in the Tenant, identified by their Profile user ID
- How a request reaches it
- The person signs in, and their identity-provider subject is resolved to that user ID and recorded on a platform token.
- Tenant identity
agent:<agent_id>- What it names
- An Agent Identity: a tenant-scoped non-human principal
- How a request reaches it
- 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 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 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
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. 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).
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 states what those records and proofs establish.