Understand delegated authority across people, organizations and AI agents.
Delegated authority describes a bounded permission for one actor to act on behalf of another under defined conditions. Proving identity alone does not establish that authority.
Six readers, six questions
Each reader arrives with a different decision in mind. The explainers are written so each reader can find their answer without reading everything.
Enterprise architect
How does delegated authority differ from authentication and authorization?
IAM or security lead
How is privilege bounded, and how is it withdrawn?
AI systems architect
Can an agent act for a person or an organization?
Developer
How do I implement the pattern?
Risk, privacy or audit
What can be evidenced, and by whom?
Economic buyer
Why does this matter to the business?
Four things this explainer does not say
These are frequent misreadings. Each one is corrected here so the concepts are not stretched beyond what they establish.
“Logging in means I can act for my employer.”
Sign-in establishes identity. It does not establish a mandate.
“An AI agent is trusted, so it can do anything.”
An agent's identity does not grant unlimited authority.
“A log proves the action was allowed.”
Evidence explains a recorded decision.
“A credential is the same as permission.”
A credential carries a claim. Access still depends on a decision.
Five terms, five different questions
A sign-in, a permission and a logged decision are separate things. Each term says what it means and what it does not establish.
Identity
Who or what the actor is. It does not grant permission.
Authentication
Checking the actor. It does not establish a mandate.
Delegated authority
A bounded basis to act for someone or something else.
Authorization
Deciding whether a specific action is permitted in current context.
Evidence
The reviewable context of a decision. It is not a substitute for permission.
No inference. Being verified, being affiliated with an organization, or holding a credential does not, by itself, establish permission to act.
What a bounded delegation must specify
These are conceptual model dimensions. They are not a confirmed API schema, and no product field names are implied.
| Dimension | Plain-language meaning |
|---|---|
| Delegator | The party whose authority is passed on |
| Scope | What the authority covers, and what it does not |
| Time | The period in which it can be used |
| Revocation | How and when the authority can be withdrawn |
How delegated authority begins, changes and ends
A teaching sequence. It is a conceptual model, not a description of any running system.
Unknown currency is not current permission. If the status of an authority is not confirmed, this page does not treat it as an active grant.
Choose the route that matches your role
Each path lists the order of reading. Destinations marked pending are not yet approved, so they do not link anywhere.
Enterprise architect
- 1Read the concept boundaries
- 2Read the authority anatomy
- 3Read the lifecycle
- 4Follow to Architecture Guides
IAM or security lead
- 1Read the denial example
- 2Read continuous trust
- 3Read evidence and privacy
- 4Follow to Trust resources
Developer
- 1Read the concept boundaries
- 2Read the authority anatomy
- 3Follow to API Reference
Four illustrative cases
Each case is labelled illustrative. None confirms that a particular product or workflow is available.
Employee for employer
A delegate acts for their employer, within a defined mandate.
Supplier for customer
A partner acts for a customer organization for one purpose and period.
Service in a workload
A service acts under a context assigned to its workload.
AI agent for a sponsor
An agent invokes one constrained action for an authorized sponsor.
A request outside its scope is refused
Example: a delegate may read one resource but asks to change it. The decision must check the action, the resource and current context separately. The delegate's identity alone is not enough.
Within scope (illustrative)
Action: read
Resource: the named record
Context: within the time window
Outside scope (illustrative)
Action: update, not granted
Decision: denied, with neutral reason
Identity alone: insufficient
Authority can become stale
A change in role, organization context, policy, device or security signal, or simply time, can require re-evaluation. The actual triggers depend on the approved implementation.
Expiry
Authority ends at the stated time.
Revoked authority
Withdrawn where the mechanism permits.
Outdated evidence
Records of the past, not current permission.
Re-evaluation
A fresh check against current context.
Explain a decision without collecting more than it needs
A decision can be explained through a reference to the actor, the authority, the policy version, the outcome and any change. Retention and visibility depend on verified policy and permissions.
Boundaries of the page
These functions belong to other destinations or to no public destination at all.
How this explainer stays accurate
Every explainer is tied to a named owner, a review record and the sources its claims rest on. Changes are versioned, not overwritten.
Accountable owner
Named in the content registry for each explainer.
Technical review
Product and architecture confirm each concept and boundary.
Review date
Shown only once a review is recorded and approved.
Frequently asked questions
Find answers to common questions about Zoiko iD
Exact details live in the authoritative sources
This page explains concepts. Interfaces, tested steps and release changes live in their own destinations.
Architecture Guides
How the trust layer fits your systems.
API Reference
Exact interfaces, from the developer documentation.
Talk to an identity expert
Discuss your use case with a specialist.
Keep reading, or move to the architecture.
Read the other explainers, follow the architecture guides for system context, or talk to an identity expert about your use case.
