Machine & Agent Identity Guides
Machine identity establishes an identity for a non-human actor such as a service or workload. AI-agent identity addresses actors that can initiate or coordinate actions. Proving an actor’s identity does not by itself grant authority: permitted actions depend on policy, scope, purpose, context and any required delegation. Evidence helps explain how those decisions were made.
Four kinds of non-human actor
These are educational categories, not runtime object types. An actor can fall into more than one category, and no category automatically carries delegated authority.
Service
A named software component that offers a function to others.
Concern: who is callingExample: a reporting service
Workload
A running unit of work, such as a job or container, with its own context.
Concern: context changesExample: a batch job
Machine
A device or physical process acting in the world.
Concern: physical safetyExample: a sensor gateway
AI agent
An actor that initiates or coordinates actions toward a goal.
Concern: scope of actionExample: a task assistant
Overlap disclaimer. A service can run as a workload, and an agent can call services. Each category describes a role, not a guarantee of what the actor may do.
Filter by actor, topic and depth
Filters appear only for values the approved guide registry supports. No guide inventory is published in this layout, so the counts below show the empty state.
Optional: search architecture topicsActor type
Topic
Reader depth
0 guides match these filters
No guides match these filters
Remove a filter, or clear all. Your selections are kept until you change them.
Search is temporarily unavailable. Browse the actor types and topics on this page instead. We will not describe the library as empty.
Choose a track by your role
Each track is an editorial reading order. Tracks do not record completion, and steps are not certifications.
Architect
Trust boundaries and where decisions are made.
- Actor taxonomy
- Identity vs authority
- Overlay model
Developer
How an integration path connects to documentation.
- Machine lifecycle
- Credential boundaries
- API Reference
Security
Policy, lifecycle and what happens on change.
- Continuous trust
- Revocation patterns
- Evidence model
AI teams
Sponsorship, mandates and tool access.
- Agent sponsorship
- Mandate bounds
- Delegated authority
From discovery to retirement
A conceptual sequence of text steps. No credential rotation period or expiry default is implied.
Discover or establish
The actor is registered
Authenticate
Presented identity is checked
Evaluate policy
Rules applied to the request
Use allowed scope
Only in-bounds actions
Monitor context
Changes are noticed
Disable and retire
Access is ended
Secrets are handled outside this guide. No secret value, key material or rotation schedule is shown. Specific mechanisms are described only in approved technical documentation.
An agent acts for someone, within limits
Six elements define an agent's authority. Each one is a design concept. Where enforcement is not verified, this guide says “design concept”, not “currently enforces”.
Agent principal
The identity that acts.
Sponsor
The human or organization accountable for it.
Task mandate
The task the agent is allowed to perform.
Resource and tool bounds
The resources and tools that may be used.
Duration
The period in which the mandate applies.
Accountable owner
The person who answers for outcomes.
Four questions, four different answers
Identity, authentication, authority and evidence each answer a different question. Authentication alone does not make an agent safe to act.
| Concept | Question it answers | What it does not answer |
|---|---|---|
| Actor identity | Who or what is this actor? | Whether the actor may act now |
| Authentication | Did the presented identity check pass? | Whether a requested action is permitted |
| Policy and authority | Is this action permitted, in this scope, now? | Why a past decision was made |
| Evidence | Why and when was a decision made? | Whether the authority is still current |
Authentication alone does not ensure agent-safe behavior. A correct identity check still needs a bounded mandate and a current policy decision.
Changing context can change the answer
Risk signals, expiry, access limitation and revocation are architectural patterns. Timing and triggers are examples, not promised guarantees.
Re-evaluation
A fresh check against current context.
Limitation
Narrowing what the actor may do.
Revocation
Withdrawing authority, where the mechanism permits.
Expiry
Authority ends at the stated time.
Explain a decision, without exposing data
Evidence explains the actor, the authority source, the policy version, the context, the decision time and any later change. The example below is synthetic and uses placeholders only.
Synthetic example · placeholders only · not a real recordDecision record (synthetic)
Illustrative- Actor reference
- [actor-id]
- Authority source
- [mandate-ref]
- Policy version
- [policy-version]
- Context
- [context-summary]
- Decision time
- [timestamp]
- Later change
- [change-ref, if any]
Overlay, not replacement
A conceptual map of how an existing identity provider, a workload platform, a policy point and downstream services relate. It names no providers and claims no protocol support.
Existing identity provider
Continues to authenticate people and services.
Your systemWorkload platform
Runs the services and jobs that act.
Your system
Policy point
Evaluates the request against current rules.
Intended design
Downstream services
Receive only requests that are in bounds.
Your system
No protocol or provider claim. Automatic federation and specific protocol support are not asserted here. Exact interfaces come from the API Reference and Integrations pages, once approved.
Five readers, five routes through this guide
Each reader arrives with a different decision. The routes below show where to start and where each one leads next.
Security lead
Reads the actor comparison, then the lifecycle, then evidence.
Next: Trust Center
Developer
Reads the workload concepts, then goes to exact interfaces.
Next: API Reference
AI engineer
Reads sponsorship and mandate bounds before anything else.
Next: Delegated Authority
Enterprise architect
Reads the overlay map and the integration boundaries.
Next: Architecture Guides
Screen-reader user
Moves from the filters to the diagram text equivalent.
Next: any guide, full text
How every guide in this library is structured
This is the layout each guide follows. It is a template, not a guide.
Title and one-sentence answer
The question the guide answers
Concept topic and depth
Editorial tags, reviewed
Question-led headings
Each section answers one question
Steps and caveats
What holds, and what does not
Related documentation
Approved routes only
Owner, reviewer and review date
Shown only when verified
Withdrawn or superseded notice
Points to a supported replacement
Content type and link
Editorial type, resolved route
Four things this guide does not let you assume
These are the most frequent mistakes readers make. Each one is corrected here, so the concepts are not stretched beyond what they establish.
“A machine identity can do anything its host can.”
An identity establishes who is calling. It does not establish what the caller may do.
Correct: each action needs an explicit, bounded permission.
“An agent with a sponsor is fully accountable.”
A sponsor is one part of the picture. Scope, duration and the policy in force also bound the agent.
Correct: sponsorship is necessary, not sufficient.
“Rotating a secret makes it safe.”
Rotation reduces one risk. It does not change what the actor is permitted to do.
Correct: lifecycle and authority are separate controls.
“A log entry proves the action was allowed.”
Evidence explains a recorded decision. It does not prove that authority is still current.
Correct: check current status separately.
Questions to ask any vendor, including us
Use these to test a claim before you rely on it. They are questions, not answers, so this page does not assert any of the outcomes they ask about.
Which actor types does the product name explicitly, and which ones does it leave out?
Ask for the written list, not a general assurance.
How is a mandate bounded: by action, resource, purpose and time?
Ask for a worked example in your own terms.
What happens to an agent's access when its sponsor leaves the organization?
Ask for the process and who approves it.
When a permission is changed, how soon does that change take effect?
Ask for the approved timing statement and its source.
What does a decision record contain, and who can see it?
Ask for field names and access roles in writing.
Which protocols and integrations are generally available today?
Ask for the current support statement, dated and sourced.
Who approves what before a guide is published
No single writer decides a technical claim. Each kind of statement has its own approver. A missing approval blocks publication rather than being filled in by guesswork.
| Role | Approves | Cannot do alone |
|---|---|---|
| Editorial | Drafts concept explanations and structure | Create technical truth to fill a gap |
| Product | Confirms intended positioning | Approve an implementation claim alone |
| Engineering and Security | Verifies protocol, implementation and secret-handling statements | Approve legal or personal-data wording |
| Legal and Privacy | Approves regulatory and personal-data implications | Approve technical behaviour |
| SEO | Owns canonical routes and structured data | Change a claim's meaning |
| Accessibility and QA | Signs off interaction and assistive-technology coverage | Waive a failed test |
Every guide records where it came from
Each published guide carries these fields. A field that has not been verified is shown as not recorded, never as a made-up date or name.
Source references
The approved first-party documents each claim rests on.
Shown for every claim
Owner and reviewer
The named roles accountable for the content and its technical accuracy.
Shown once assigned
Review date and version
The date of the last substantive review, and the version number.
Not recorded until reviewed
Change history
Substantive edits are versioned, not silently overwritten.
Kept with each version
Withdrawal and replacement
A withdrawn or superseded guide points to a supported replacement.
Notice shown where relevant
Review trigger
A change in a referenced product or standard prompts a new review.
Review scheduled on change
Each page owns its own question
Adjacent guides cover related ground. This page links to them rather than repeating them, so each topic has one canonical home.
Identity Guides
Core concepts: identity, authentication, credentials.
Owns fundamentals
Architecture Guides
Reference patterns and trust boundaries.
Owns patterns
Delegated Authority Explainers
Mandates, scope, time and revocation.
Owns mandates
API Reference
Exact executable contracts.
Owns contracts
- machine identity guide
- service account identity
- workload identity
- AI agent identity
- non-human identity security
- agent authorization
- delegated authority for agents
Teaching examples use masked, synthetic values
Examples show the shape of a record without exposing a real identity, tenant or secret. Every identifier below is a placeholder.
Never copy a real value into an example. Real identifiers, tokens and customer records are excluded from every guide.
- Agent reference
- agt-XXXX-masked
- Sponsor reference
- sps-XXXX-masked
- Workload reference
- wkl-XXXX-masked
- Secret value
- [not shown]
- Tenant
- [not shown]
Boundaries of this guide
A short list of what belongs elsewhere. Each item links to the page that owns it, rather than being answered here.
Does not issue credentials
Credential issuance is covered in the technical documentation.
Does not create mandates
No grant is created or changed from this page.
Does not give legal advice
Regulatory and legal questions go to counsel and the Privacy Notice.
Does not publish availability
Which integrations are live is stated only in approved status records.
Does not certify conformance
No certification or compliance statement is made here.
Does not describe your deployment
Diagrams are reference patterns, not your topology.
Before you act on any of this
Concepts here are a starting point. Before you design around them, confirm the following with the people who own each system.
Which non-human actors exist in your estate today
Inventory them before choosing a model.
Who sponsors each actor, and who answers for it
Name a person, not a team alias.
What each actor needs, and nothing more
Write the bounds before granting any access.
What must be true before this page goes live
This page is a prepared draft. Each gate below must be met and recorded before publication. Until then, the page makes no live claim.
Canonical route
Bound to the approved route registry.
Pending
Guide inventory
Reviewed guides exist in the registry.
PendingClaim approvals
Every technical claim has an approved source.
Pending
Accessibility verification
Keyboard, zoom and reflow tests pass.
Pending
Frequently asked questions
Find answers to common questions about Zoiko iD
Keep learning, or move to the technical material.
Read the architecture guides for system context, the Delegated Authority Explainers for mandates, or speak with an identity expert about your environment.
Architecture Guides
Developer documentationMachine & Agent Identity Guides
Understand how machines, services, workloads, and AI agents are identified—and why authenticated identity is only one part of governing what they can do.
Machine identity establishes an identity for a non-human actor such as a service or workload. AI-agent identity addresses actors that can initiate or coordinate actions. Proving an actor’s identity does not by itself grant authority: permitted actions depend on policy, scope, purpose, context and any required delegation. Evidence helps explain how those decisions were made.
Talk to an identity expert → (route from approved registry, pending)
Conceptual teaching pattern
Workloads
Machines
AI agents
Signals
Four kinds of non-human actor
These are educational categories, not runtime object types. An actor can fall into more than one category, and no category automatically carries delegated authority.
Service
A named software component that offers a function to others.
Concern: who is callingExample: a reporting service
Workload
A running unit of work, such as a job or container, with its own context.
Concern: context changesExample: a batch job
Machine
A device or physical process acting in the world.
Concern: physical safetyExample: a sensor gateway
AI agent
An actor that initiates or coordinates actions toward a goal.
Concern: scope of actionExample: a task assistant
Overlap disclaimer. A service can run as a workload, and an agent can call services. Each category describes a role, not a guarantee of what the actor may do.
Conceptual examples. Not product or deployment descriptions.
Filter by actor, topic and depth
Filters appear only for values the approved guide registry supports. No guide inventory is published in this layout, so the counts below show the empty state.
Actor type
Topic
Reader depth
0 guides match these filters
No guides match these filters
Remove a filter, or clear all. Your selections are kept until you change them. The topic list in the sections below remains available.
Search is temporarily unavailable. Browse the actor types and topics on this page instead. We will not describe the library as empty.
Choose a track by your role
Each track is an editorial reading order. Tracks do not record completion, and steps are not certifications.
Architect
Trust boundaries and where decisions are made.
- Actor taxonomy
- Identity vs authority
- Overlay model
Developer
How an integration path connects to documentation.
- Machine lifecycle
- Credential boundaries
- API Reference
Security
Policy, lifecycle and what happens on change.
- Continuous trust
- Revocation patterns
- Evidence model
AI teams
Sponsorship, mandates and tool access.
- Agent sponsorship
- Mandate bounds
- Delegated authority
From discovery to retirement
A conceptual sequence of text steps. No credential rotation period or expiry default is implied.
Discover or
establishThe actor is
registered
Authenticate
Presented identity
is checked
Evaluate
policyRules applied to
the request
Use allowed
scopeOnly in-bounds
actions
Monitor
contextChanges are
noticed
Disable and
retireAccess is ended
Secrets are handled outside this guide. No secret value, key material or rotation schedule is shown. Specific mechanisms are described only in approved technical documentation.
Agent sponsorship and delegation
An agent acts for someone,
within limits
Six elements define an agent's authority. Each one is a design concept. Where enforcement is not verified, this guide says “design concept”, not “currently enforces”.
Agent principal
The identity that acts.
Sponsor
The human or organization accountable for it.
Task mandate
The task the agent is allowed to perform.
Resource and tool bounds
The resources and tools that may be used.
Duration
The period in which the mandate applies.
Accountable owner
The person who answers for outcomes.
No auto-grant. An agent's identity, its sponsor's position, or a credential alone does not give it authority. Every permission must be explicitly bounded.
Delegated Authority Explainers → (destination pending approval)
Identity versus authority
Four questions, four
different answers
Identity, authentication, authority and evidence each answer a different question. Authentication alone does not make an agent safe to act.
| Concept | Question it answers | What it does not answer |
|---|---|---|
| Actor identity | Who or what is this actor? | Whether the actor may act now |
| Authentication | Did the presented identity check pass? | Whether a requested action is permitted |
| Policy and authority | Is this action permitted, in this scope, now? | Why a past decision was made |
| Evidence | Why and when was a decision made? | Whether the authority is still current |
Authentication alone does not ensure agent-safe behavior. A correct identity check still needs a bounded mandate and a current policy decision.
Continuous trust and revocation
Changing context can
change the answer
Risk signals, expiry, access limitation and revocation are architectural patterns. Timing and triggers are examples, not promised guarantees.
Re-evaluation
A fresh check against current context.
Limitation
Narrowing what the actor may do.
Revocation
Withdrawing authority, where the mechanism permits.
Expiry
Authority ends at the stated time.
Evidence and privacy
Explain a decision, without
exposing data
Evidence explains the actor, the authority source, the policy version, the context, the decision time and any later change. The example below is synthetic and uses placeholders only.
Synthetic example · placeholders only · not a real record
Decision record
(synthetic)
Illustrative- Actor reference
- [actor-id]
- Authority source
- [mandate-ref]
- Policy version
- [policy-version]
- Context
- [context-summary]
- Decision time
- [timestamp]
- Later change
- [change-ref, if any]
Evidence & Audit →No customer evidence, secrets or fingerprintable identifiers appear here.
Enterprise integration
Overlay, not replacement
A conceptual map of how an existing identity provider, a workload platform, a policy point and downstream services relate. It names no providers and claims no protocol support.
Existing identity provider
Continues to authenticate people and services.
Your systemWorkload platform
Runs the services and jobs that act.
Your system
Policy point
Evaluates the request against current rules.
Intended design
Downstream services
Receive only requests that are in bounds.
Your system
No protocol or provider claim. Automatic federation and specific protocol support are not asserted here. Exact interfaces come from the API Reference and Integrations pages, once approved.
Guide detail template
How every guide in this
library is structured
This is the layout each guide follows. It is a template, not a guide.
Title and one-sentence answer
The question the guide answers
Concept topic and depth
Editorial tags, reviewed
Question-led headings
Each section answers one question
Steps and caveats
What holds, and what does not
Related documentation
Approved routes only
Owner, reviewer and review date
Shown only when verified
Withdrawn or superseded notice
Points to a supported replacement
Content type and link
Editorial type, resolved route
Common misreadings
Four things this guide does
not let you assume
These are the most frequent mistakes readers make. Each one is corrected here, so the concepts are not stretched beyond what they establish.
“A machine identity can do anything its host can.”
An identity establishes who is calling. It does not establish what the caller may do.
Correct: each action needs an explicit, bounded permission.
“An agent with a sponsor is fully accountable.”
A sponsor is one part of the picture. Scope, duration and the policy in force also bound the agent.
Correct: sponsorship is necessary, not sufficient.
“Rotating a secret makes it safe.”
Rotation reduces one risk. It does not change what the actor is permitted to do.
Correct: lifecycle and authority are separate controls.
“A log entry proves the action was allowed.”
Evidence explains a recorded decision. It does not prove that authority is still current.
Correct: check current status separately.
Reader journeys
Five readers, five routes through this guide
Each reader arrives with a different decision. The routes below show where to start and where each one leads next.
Glossary
Terms used on this page
- Non-human actor
- Any actor that is not a person, such as a service, workload, machine or agent.
- Principal
- The identity that presents a request.
- Sponsor
- The accountable human or organization behind a non-human actor.
- Mandate
- A bounded statement of what an actor may do, on what, for what purpose and for how long.
- Overlay
- A design where a new layer sits beside existing systems, not in place of them.
- Re-evaluation
- Checking a permission again against the context that exists at that moment.
- Decision record
- The explanation of an outcome, kept under privacy controls.
- Currency
- Whether a statement is still current, shown only when its review is recorded.
Evaluation checklist
Questions to ask any vendor, including us
Use these to test a claim before you rely on it. They are questions, not answers, so this page does not assert any of the outcomes they ask about.
Which actor types does the product name explicitly, and which ones does it leave out?
Ask for the written list, not a general assurance.
How is a mandate bounded: by action, resource, purpose and time?
Ask for a worked example in your own terms.
What happens to an agent's access when its sponsor leaves the organization?
Ask for the process and who approves it.
When a permission is changed, how soon does that change take effect?
Ask for the approved timing statement and its source.
What does a decision record contain, and who can see it?
Ask for field names and access roles in writing.
Which protocols and integrations are generally available today?
Ask for the current support statement, dated and sourced.
Editorial governance
Who approves what before a guide is published
No single writer decides a technical claim. Each kind of statement has its own approver. A missing approval blocks publication rather than being filled in by guesswork.
| Role | Approves | Cannot do alone |
|---|---|---|
| Editorial | Drafts concept explanations and structure | Create technical truth to fill a gap |
| Product | Confirms intended positioning | Approve an implementation claim alone |
| Engineering and Security | Verifies protocol, implementation and secret- handling statements | Approve legal or personal- data wording |
| Legal and Privacy | Approves regulatory and personal-data implications | Approve technical behaviour |
| SEO | Owns canonical routes and structured data | Change a claim's meaning |
| Accessibility and QA | Signs off interaction and assistive- technology coverage | Waive a failed test |
Content provenance
Every guide records where it came from
Each published guide carries these fields. A field that has not been verified is shown as not recorded, never as a made-up date or name.
Source references
The approved first-party documents each claim rests on.
Shown for every claim
Owner and reviewer
The named roles accountable for the content and its technical accuracy.
Shown once assigned
Review date and version
The date of the last substantive review, and the version number.
Not recorded until reviewed
Change history
Substantive edits are versioned, not silently overwritten.
Kept with each version
Withdrawal and replacement
A withdrawn or superseded guide points to a supported replacement.
Notice shown where relevant
Review trigger
A change in a referenced product or standard prompts a new review.
Review scheduled on change
Privacy-by-design examples
Teaching examples use masked, synthetic values
Examples show the shape of a record without exposing a real identity, tenant or secret. Every identifier below is a placeholder.
Never copy a real value into an example. Real identifiers, tokens and customer records are excluded from every guide.
Masked example, synthetic
- Agent reference
- agt-XXXX-masked
- Sponsor reference
- sps-XXXX-masked
- Workload reference
- wkl-XXXX-masked
- Secret value
- [not shown]
- Tenant
- [not shown]
What we measure, and what we never collect
Categories only, never content
Analytics record which kinds of guide were opened, not what a reader typed or who they are. The lists below are the rule.
We may record
Which guide category was opened- Which filter category was changed
- That a search was submitted, and how many results appeared
- Which documentation link was followed
We never record
Raw search text- User or account identifiers
- Credentials, keys or tokens
- Tenant or customer data
Collection depends on the approved consent configuration and retention policy. Where consent is not configured, nothing is collected beyond what the site needs to function.
Publication status
What must be true before this page goes live
This page is a prepared draft. Each gate below must be met and recorded before publication. Until then, the page makes no live claim.
Canonical route
Bound to the approved route registry.
Pending
Guide inventory
Reviewed guides exist in the registry.
PendingClaim approvals
Every technical claim has an approved source.
Pending
Accessibility verification
Keyboard, zoom and reflow tests pass.
Pending
Approval of this draft is not certification. It does not make a product feature available, and it does not make an unverified guide public.
Related Resources Learn pages
Each page owns its own question
Adjacent guides cover related ground. This page links to them rather than repeating them, so each topic has one canonical home.
Owns fundamentalsIdentity Guides
Core concepts: identity, authentication, credentials.
Owns patternsArchitecture Guides
Reference patterns and trust boundaries.
Owns mandatesDelegated Authority Explainers
Mandates, scope, time and revocation.
Owns contractsAPI Reference
Exact executable contracts.
- machine identity guide
- service account identity
- workload identity
- AI agent identity
- non-human identity security
- agent authorization
- delegated authority for agents
Topics above are search themes this guide is written to answer. They are not claims about how many guides exist.
Accessibility commitments
Readable, navigable and usable without a mouse
These are design commitments that are tested before release. Each one applies to every section on this page.
Text first
Every diagram has a full text equivalent in reading order.
Keyboard operable
Filters, links and controls are reachable and visibly focused.
Clear structure
One H1, logical H2 and H3 headings, and labelled controls.
Zoom and reflow
Content reflows at 320px and remains usable at 400% zoom.
Target standard: WCAG 2.2 AA. Motion is reduced where the reader asks for it, and no meaning depends on colour alone.
What this page does not do
Boundaries of this guide
A short list of what belongs elsewhere. Each item links to the page that owns it, rather than being answered here.
Does not issue credentials
Credential issuance is covered in the technical documentation.
Does not create mandates
No grant is created or changed from this page.
Does not give legal advice
Regulatory and legal questions go to counsel and the Privacy Notice.
Does not publish availability
Which integrations are live is stated only in approved status records.
Does not certify conformance
No certification or compliance statement is made here.
Does not describe your deployment
Diagrams are reference patterns, not your topology.
Readiness for your environment
Before you act on any of this
Concepts here are a starting point. Before you design around them, confirm the following with the people who own each system.
Which non-human actors exist in your estate today
Inventory them before choosing a model.
Who sponsors each actor, and who answers for it
Name a person, not a team alias.
What each actor needs, and nothing more
Write the bounds before granting any access.
Questions
Direct answers on machine and agent identity
Next step
Keep learning, or move to the technical material.
Read the architecture guides for system context, the Delegated Authority Explainers for mandates, or speak with an identity expert about your environment.
