Tenant identity and access management
Tenant identity management identifies who acts in a Tenant, manages that identity's access, and explains what an access decision or audit record proves.
Identify who acts in a Tenant, manage identity access, and understand what access decisions and audit records prove.
- Tenant actions have two actors: a person or an Agent Identity.
- A user ID is never the identity provider's external subject.
- Groups contribute policy permissions to members but never authenticate or perform an action.
- Zero Trust means a network origin gives no tenant authority by itself.
- system is reserved for audit records of platform-supplied policy-version changes.
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
user:<user_id>- What it names
- A person in the Tenant, identified by their Profile user ID
- How a request reaches it
- The person’s sign-in credential is verified and its identity-provider subject is resolved to that user ID.
- 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 resolves to its owning Tenant and Agent 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. IAM policy authoring and supplied-tier changes require a signed-in person. 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.
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.