Identity limits: allow results, policies, and audit events

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 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; assurance levels define that second question and what satisfies it. A group and an audit-only system origin cannot authenticate at all. Membership in a named tier does not bypass the action–resource decision, 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 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 holds whatever an administrator confers on it, up to what that administrator holds, so read a subject’s complete access rather than reasoning from its kind. Tenant access policies owns those combination and authoring rules, and carries the recommendation on where to keep permission management.

A Library Grant can allow or refuse one concrete person or Agent Identity on one Library path; 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, and Task attribution. By default, it also bounds which Task events and Task history it reads; a policy author with authority to confer the permission can widen that access with a grant. 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 owns the exact Tenant boundary. An IAM allow never authorizes a customer Tool’s external Effect. Secure integration 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 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 owns the complete record inventory, query and export limits, and proof procedure. For limits outside IAM, read scope and limits.