Identity, authority and evidence for enterprise systems.
Zoiko iD is designed to help enterprises establish who or what is acting, evaluate bounded authority, respond to changing trust signals and preserve reviewable evidence across existing identity and application estates. Supported integrations and deployment patterns must be confirmed for your environment.
- 01ActorWho or what is acting
- 02MandateBounded authority
- 03PolicyRules applied now
- 04DecisionOutcome for this request
- 05EvidenceReviewable record
Authenticate is not authorize, and neither proves a mandate
Enterprises often ask one system to answer three different questions. Keeping them separate prevents a successful sign-in from being read as permission to act.
- Authenticate — who is this?
- Authorize — may this action happen?
- Prove the mandate — on whose behalf, and why?


Five distinct nodes, each with its own owner
Actor and organization, mandate, policy, decision and reviewable evidence. Each node has its own limits, so none can stand in for another.
Text equivalent. An actor (person, service or AI agent acting for an organization) makes a request; a mandate states who granted authority, purpose, resources and timeframe; policy is evaluated against current context; a decision is produced for this request; reviewable evidence records the basis and is shown only to authorized reviewers.
Your existing systems stay authoritative for what they own
Existing identity providers, directories and applications continue to own the functions they already run. Zoiko iD is designed to sit alongside them as an overlay, with explicit boundaries.
Start from the question your team owns
CIO / CTO
Architecture and coexistence with your estate.
Architecture → talk to an expert
CISO / IAM
Controls for delegation, revocation and trust.
Security → authority model
Architect
Federation, APIs, organization and machine boundaries.
Architecture → developers
AI lead
Sponsorship and bounded action for agents.
Agent identity → limits → evidence
Procurement
Owner, documentation and the evaluation route.
Corporate details → sales

Five conceptual gates
These gates describe how an evaluation is usually structured. Each has an owner, and none commits you to a timeline or a deployment.
- 1.DiscoverRead how the architecture fits.
- 2.ScopeChoose the identity classes in view.
- 3.ValidateReview architecture, API and trust material.
- 4.GovernAgree controls with security and privacy.
- 5.OperatePlan ongoing ownership and change.

What the enquiry asks
Submitting starts a review. It is not a booking, a quote, an offer or a commitment. The receipt confirms only that the request was received.

- Work email
- Required; syntax checked
- Full name
- Required
- Organization
- Required; not verified
- Role
- Optional: CIO/CTO, Security/IAM, Engineering, Procurement, Other
- Evaluation area
- Required: enterprise access, delegated authority, AI-agent access, credentials, other
- Country or region
- Optional; used for routing only
- Message
- Optional; no credentials, secrets or personal records
- Privacy acknowledgment
- Required; links to the privacy policy
Submit control is not shown. States covered: submitting, received, unknown outcome, route unavailable.
Talk to an identity expert about
your enterprise evaluation.
Share your architecture and what you need to decide. An expert will confirm what is supported for your environment. Submitting a request does not book a meeting or create an offer.
Enterprise identity & delegated
authority
Identity, authority and evidence for enterprise systems.
Zoiko iD is designed to help enterprises establish who or what is acting, evaluate bounded authority, respond to changing trust signals and preserve reviewable evidence across existing identity and application estates. Supported integrations and deployment patterns must be confirmed for your environment.
Zoiko iD is designed to help enterprises establish who or what is acting, evaluate bounded delegated authority, respond to changing trust signals and preserve reviewable evidence alongside existing identity and application estates. Authentication confirms identity; authority decides what an actor may do. Supported integrations are confirmed for each environment.
View developer docs → (route pending)
- 01ActorWho or what is acting
- 02MandateBounded authority
- 03PolicyRules applied now
- 04DecisionOutcome for this request
- 05EvidenceReviewable record
Conceptual trust chain. A text equivalent is in the first section of the design below. Not a product screenshot.
Decision criteria
Authenticate is not authorize, and neither proves a mandate
Enterprises often ask one system to answer three different questions. Keeping them separate prevents a successful sign-in from being read as permission to act.
- Authenticate — who is this?
- Authorize — may this action happen?
- Prove the mandate — on whose behalf, and why?


How a decision is made and explained
Five distinct nodes, each with its own owner
Actor and organization, mandate, policy, decision and reviewable evidence. Each node has its own limits, so none can stand in for another.
Text equivalent. An actor (person, service or AI agent acting for an organization) makes a request; a mandate states who granted authority, purpose, resources and timeframe; policy is evaluated against current context; a decision is produced for this request; reviewable evidence records the basis and is shown only to authorized reviewers.
Architectural coexistence
Your existing systems stay authoritative for what they own
Existing identity providers, directories and applications continue to own the functions they already run. Zoiko iD is designed to sit alongside them as an overlay, with explicit boundaries.
Identity provider
Authentication
Alongside, as an overlay
Automatic compatibility with every vendor
Applications
Business actions
Requests decisions and enforces them
Replacement of application logic
Policy decision
Rule evaluation
Bounded decision inputs and context
Universal production engine guarantees
Evidence owner
Authoritative record
Provenance and decision context
Immutable or legally sufficient logs
Support for a specific identity provider, protocol or application is confirmed for your environment. No universal compatibility is claimed.
Evaluation paths
Start from the question your team owns
CIO / CTO
Architecture and coexistence with your estate.
Architecture → talk to an expertCISO / IAM
Controls for delegation, revocation and trust.
Security → authority modelArchitect
Federation, APIs, organization and machine boundaries.
Architecture → developersAI lead
Sponsorship and bounded action for agents.
Agent identity → limits → evidenceProcurement
Owner, documentation and the evaluation route.
Corporate details → sales

Enterprise adoption
Five conceptual gates
These gates describe how an evaluation is usually structured. Each has an owner, and none commits you to a timeline or a deployment.
Discover
Read how the architecture fits.
Scope
Choose the identity classes in view.
Validate
Review architecture, API and trust material.
Govern
Agree controls with security and privacy.
Operate
Plan ongoing ownership and change.

Request a review
What the enquiry asks
Submitting starts a review. It is not a booking, a quote, an offer or a commitment. The receipt confirms only that the request was received.
Form not yet enabled
Work email
Required; syntax checked
Full name
Required
Organization
Required; not verified
Role
Optional: CIO/CTO, Security/IAM, Engineering, Procurement, Other
Evaluation area
Required: enterprise access, delegated authority, AI-agent access, credentials, other
Country or region
Optional; used for routing only
Message
Optional; no credentials, secrets or personal records
Privacy acknowledgment
Required; links to the privacy policy
Submit control is not shown. States covered: submitting, received, unknown outcome, route unavailable.
Questions
Direct answers for enterprise evaluators
Next step
Talk to an identity expert about your enterprise evaluation.
Share your architecture and what you need to decide. An expert will confirm what is supported for your environment. Submitting a request does not book a meeting or create an offer.



