Security for identity,
authority and
evidence.
Security is more than sign-in. Zoiko iD is designed to link actor identity with bounded authority, policy decisions, changing trust signals and reviewable evidence.
Designed architecture, not a certificationIdentity, authority and evidence work
together
Each pillar answers a different question. Keeping them separate prevents a successful sign-in from being read as permission.
Identity
Who is acting. Authentication and verified identity for people, organizations, services and agents.
Authority
What that actor may do: bounded by grantor, action, resource, purpose, policy, expiry and revocation.
Evidence
What was decided and why, with the actor, decision basis, policy context and relevant changes available for review.
Six designed stages, each with its own owner
Every stage is a design intent. None is a claim that a stage is live for your environment.
Verify identity
Bound authority
expiry.
Evaluate policy
policy and context.
Read signals
supported.
Re-evaluate
changes.
Record evidence
Each challenge has a different owner
Impersonation, excessive delegation, stale grants and missing decision context need different controls and different owners. No control here is a guarantee.
| Security challenge | Architectural control | Owner | Approved proof route |
|---|---|---|---|
 | Verified identity before any authority is evaluated | Identity system and Security | Pending route registry |
 | Grants bounded by action, resource, purpose and expiry | Product and Security | Pending route registry |
 | Re-evaluation when authority or trust context changes | Security source | Pending route registry |
 | Decision evidence stored with its basis and policy context | Evidence owner | Pending route registry |
Signing in does not authorize a sensitive
action
Two decisions for the same signed-in person. The policy engine implementation is not verified here; the examples show the decision order only.
Authenticated, not authorized
- The actor is verified.
- No mandate covers this resource.
- The request is denied and the reason is recorded.
Authenticated and authorized
- The actor is verified.
- A current mandate covers this action, resource and purpose.
- Policy and context are checked again at decision time.
Qualifier: the specific policy engine and its behavior are not claimed here.
A grant has boundaries
Authority can be constrained by grantor, grantee, action, resource, purpose, policy, expiry and revocation. The card shows the fields; its values are invented.
Redacted grant card
IllustrativeAn agent should not inherit broad authority
Being able to authenticate does not give a workload or an agent broad permissions. Each non-human
principal needs a sponsor, a mandate, a duration and a role boundary.
Human
themselves or
their organization.
Organization
inferred from an email
domain.
Service
identity and a narrow
role.
Machine
process with bounded
duty.
AI agent
sponsored authority. Tool
use is never automatic.
Reviewable without
over-collecting
Evidence is useful when a reviewer can identify the actor, the decision basis, the policy context and the relevant changes. Only minimal fields are described here, and access is controlled.
Scope and retention. No tamper-proof, indefinite-retention or export claim is made. Retention is set by the approved privacy policy.
Decision record anatomy
Illustrative schemaDesigned to complement your existing
systems
Zoiko iD is designed to complement existing identity providers, applications and policies through governed integrations. Each system stays responsible for its own enforcement.
Identity provider
Authenticates the person or service.
Zoiko iD authority
Evaluates proposed authority and policy context.
Relying application
Enforces its own decision before acting.
Evidence owner
Holds the authoritative decision record.
Text version of the boundary diagram
- The identity provider authenticates the actor.
- The Zoiko iD authority layer evaluates proposed authority and policy context.
- The relying application enforces the decision in its own runtime.
- The evidence owner holds the authoritative record.
Exact runtime contract for Zoiko iD requires engineering sign-off. Integration status is checked against the capability registry.
Operational assurance comes from its
owners
This page explains the architecture. Certifications, incident history, service status and vulnerability reporting
are held by their own authoritative pages.
Trust Center
Approved assurance records and attestation status.
Security Advisories
Service advisories from their owning page.
Responsible Disclosure
How to report a suspected vulnerability.
Privacy
Personal-data disclosures and rights wording.
Availability and status
Current operational state of services.
Documentation
Technical references for integration.
Request a security
briefing
Discuss your identity, delegation and evidence requirements with a Zoiko iD specialist. Please do not include passwords, tokens or incident details in this form.
Confirmation means we have received your request. It does not mean the request is accepted or scheduled. Submission is not connected in this layout.
Frequently asked questions
Find answers to common questions about Zoiko iD
Evaluate security architecture and
delegated authority with
the Zoiko iD team.
Bring your identity estate, your delegation requirements and your evidence expectations. For technical depth, read the developer documentation first.
Designed architecture
No certification implied