The Problem: AI Has Outgrown Traditional Access Control
Traditional digital security was built for web pages, forms, dashboards, and databases.
A user logs in. A session starts. A role or subscription flag is checked. The user clicks around inside the product.
That model is not enough for AI systems.
AI interactions are different because each interaction can carry intent, context, personal data, financial relevance, health relevance, operational consequences, or decision weight.
The system is no longer simply serving a static page. It may be helping someone make a decision, interpret information, access a paid capability, or trigger an agentic workflow.
That means the system needs to know more than:
-
Did someone pass a login screen?
-
Did a browser session exist?
-
Did a payment happen somewhere?
-
Did a checkbox get ticked once?
It needs a live authority picture.
It needs to know:
-
Who or what is acting?
-
Is the identity durable across sessions and devices?
-
Has the actor committed to this capability?
-
Is there settled payment or entitlement evidence?
-
Has the correct consent level been accepted?
-
Is the session trusted enough for this action?
-
Should the AI proceed, deny, or ask for explicit approval?
-
Is the decision auditable afterwards?
Without that, AI access becomes too loose. A system might allow the wrong capability, under the wrong identity, without the right consent, without a clean audit trail. All without a clear reason why it allowed the action.
That is not good enough for governed AI.
The Consequence: AI Without Authority Becomes a Risk Surface
The danger is not only malicious use.
The bigger risk is ambiguity.
If an AI system cannot prove who is acting, what they are entitled to, what they consented to, and why a capability was allowed, then the system becomes difficult to govern.
For a normal app, that might be inconvenient.
For AI, it becomes a structural risk.
An unguided AI system can create problems such as:
-
anonymous use without continuity,
-
payment or entitlement states disconnected from AI access,
-
consent records that are not tied to actual actions,
-
AI capabilities exposed before authority is established,
-
agents acting without clear boundaries,
-
poor auditability when something goes wrong,
-
and weak evidence when explaining why the system allowed or denied an action.
This is especially important for a study group, a clinical intelligence pathway, a decision-support product, or an API-delivered AI capability.
A 1,000-person cohort cannot be managed safely by vibes, screenshots, and trust-me access flags.
It needs an operating rail.
That rail must allow people to explore without unnecessary friction, but it must also become strict at the moment of commitment.
That is the core principle: Anonymous until value. Authorised at commitment. Audited at action.
The Solution: Eye on AI Protocol
Eye on AI is our answer to this problem.
It is a layered Human–AI–AI authority protocol built into our applications.
The first AI is the user-facing capability: Ask Omega*, Clarity, CIE, or a future agent.
The second AI layer is the governance boundary: the system that checks whether the action is allowed before the capability proceeds.
At the foundation is LAW, our Local Authority Weight protocol.
LAW is being implemented in layers.
Local Authority Weight - Layer 1: Prove Who or What Is Acting
LAW-L1 - is the System ID layer.
It establishes a durable, recoverable, auditable interaction identity for each session.
In Ask Omega*, LAW-L1 now provides:
-
wallet/session identity,
-
eager identity generation on first load,
-
persistence across refresh,
-
request authority through X-Wallet-ID,
-
Stripe/email anchoring where commitment occurs,
-
email recovery using protected hash lookup,
-
settings persistence,
-
audit infrastructure,
-
and production proof gates.
This means a participant or user does not need to be forced into a heavy account model at the first touch.
They can begin anonymously or pseudonymously.
The system can still create continuity through a local wallet/session identity.
Then, when they commit — through x402, Stripe, consent, study enrolment, or a capability unlock — the system can harden that interaction into a stronger authority state.
LAW-L1 answers: Who or what is acting?
Eye on AI Protocol: Why Trusted AI Needs More Than a Login
Eye on AI is our Human–AI–AI security layer for the Ask Omega*, Personal Health Intelligence & Clinical Intelligence Ecosystem (CIE) apps. It is designed to govern the boundary between a human, an AI capability, and a second AI governance layer that checks identity, consent, entitlement, trust, and auditability before trusted actions proceed.
Built by Design By Zen, an NZ AI lab. Evidence, not confidence.
LAW - L2: Define What That Actor Is Allowed To Do
LAW - L2 is the Authority State layer.
It derives what the actor is allowed to do based on live operating evidence.
For Ask Omega*, LAW-L2 now connects authority to:
-
wallet identity,
-
settings,
-
accepted LAW/terms level,
-
payment receipt evidence,
-
Clarity entitlement,
-
recovery confidence,
-
and audit history.
The read-only Authority State endpoint describes the actor’s current authority.
The Clarity gate now enforces that authority.
That means:
-
a free-tier wallet without a paid Clarity receipt is denied with ENTITLEMENT_INSUFFICIENT,
-
a paid Clarity wallet without sufficient LAW consent is denied with CONSENT_REQUIRED,
-
and a wallet with paid Clarity entitlement plus sufficient consent proceeds to the AI pipeline.
This is the important shift.
Ask Omega* is no longer relying on a loose frontend toggle or generic session flag.
Clarity access is now connected to settled payment evidence and consent state.
LAW-L2 answers: What is this actor allowed to do?
Why This Is Better Than CAPTCHA
CAPTCHA asks: Are you probably human?
Eye on AI asks: Is this AI action authorised?
That is a completely different level of control.
A CAPTCHA is a friction test.
Eye on AI is an authority protocol.
CAPTCHA does not know whether a person has consented, paid, recovered identity, accepted the right terms, or should be allowed to trigger a trusted AI capability.
Eye on AI is designed for that world.
It binds AI access to identity continuity, entitlement, consent, trust, and auditability.
That is what agentic systems require.
LAW - Layer 3: Seal What Actually Happened
LAW - Layer 3 is the Decision Integrity layer.
Where Layer 2 decides whether a response may be produced, Layer 3 seals what was produced. It answers a different question: did this governed action produce a tamper-evident, attributable outcome?
When Ask Omega* generates a Clarity decision, the decision snapshot — clarity, certainty, key factors, recommended action — is SHA-256 fingerprinted and written to the Clarity receipt at the moment the response is produced. That hash ties the outcome irreversibly to the authority envelope that permitted it.
A stored decision cannot be silently altered without breaking its hash, and a receipt without one is flagged as ungoverned.
The receipt schema is already in place — the decision-snapshot and hash columns exist. The enforcement and proof layer that rejects unsigned decisions, surfaces hash mismatches in the audit log, and fails the proof script on an unhashed receipt is next-planned, not yet wired. We are announcing the layer, not claiming it is live.
LAW-L3 answers: can this outcome be trusted, attributed, and audited after the fact?
Real Use Case: The 1,000 Person using "AI" apps as a Study Cohort
A 1,000-person study cohort cannot be governed by screenshots, shared logins, and trust-me access flags. Eye on AI gives every participant the same operating rail.
A participant begins anonymously or pseudonymously — no heavy account required to explore.
LAW-L1 issues a durable wallet/session identity, so their interactions stay continuous across refreshes and devices without forcing premature disclosure.
When they reach a value or trust boundary — study enrolment, a paid Clarity decision, a consent step — LAW-L2 hardens that interaction. Entitlement, accepted consent level, and recovery confidence are checked against live evidence before any trusted capability is released.
A free-tier wallet is denied with ENTITLEMENT_INSUFFICIENT; a paid wallet without consent is denied with CONSENT_REQUIRED.
The result: every participant is identifiable when it matters, every trusted action is authorised against settled evidence, and every decision is auditable afterwards — across the whole cohort, without manual administration.
That is the difference between running a study and governing one.
Anonymous Until Commitment
This is one of the most important design principles.
Most systems force users to identify themselves too early.
That creates friction, lowers trust, and asks for information before value has been proven.
Eye on AI supports a better model:
Anonymous until value. Authorised at commitment. Audited at action.
A user can explore.
A wallet/session identity provides continuity.
When the user commits to a trusted capability, the system can anchor the interaction through payment, consent, receipt evidence, or recovery.
This makes the app more humane and more secure at the same time.
It protects user privacy during exploration, while still enforcing authority when it matters.
API-Native AI Consumption
Eye on AI also supports API-delivered AI capabilities.
This matters because future AI products will not only be used inside web apps.
They will be consumed through APIs, agent workflows, partner systems, and machine-to-machine payment channels.
With x402/API-native payment rails, a capability can be delivered at the moment of value.
The operating pattern becomes:
-
Request arrives.
-
Wallet/session identity is checked.
-
Entitlement or payment evidence is evaluated.
-
Consent and trust are verified.
-
The AI capability proceeds or fails closed.
-
The authority decision is auditable.
This allows DBZ to deliver governed AI capabilities as consumable services, not just as screens inside an app.
The Big Shift
Eye on AI turns Ask Omega* from a prompt-response interface into a governed AI interaction system.
The difference is simple:
A normal AI app answers a question.
A governed AI system asks whether the action should be allowed before proceeding with the answer.
That is the future of trusted AI.
For our applications, the architecture is now clear:
-
LAW-Layer 1 proves the actor.
-
LAW-Layer 2 defines and enforces authority.
-
LAW-Layer 3 seals the outcome — Decision Integrity: tamper-evident, receipted, auditable
-
Further layers govern agent action scope, approval boundaries, and AI supervising AI.
The first operating proof is already in place.
Ask Omega* now has production-tested identity, recovery, authority-state derivation, Clarity entitlement enforcement, consent gating, and audit infrastructure.
That gives us the foundation for something much larger:
A Human–AI–AI security layer built directly into the app ecosystem.
Not bolted on later.
Not described only in policy.
Implemented as operating code.
That is Eye on AI.
Frequently Asked Questions
What is the Eye on AI Protocol?
Eye on AI is DBZ’s Human–AI–AI security protocol for governed AI interaction. It verifies identity, consent, entitlement, evidence of payment, trust, and auditability before trusted AI capabilities are enabled.
Why does trusted AI need more than a login or CAPTCHA?
A login or CAPTCHA mainly checks access or human presence. Eye on AI asks a stronger question: is this AI action authorised? It connects the action to identity continuity, consent state, entitlement evidence, payment commitment, and an audit trail.
What does anonymous until commitment mean?
Anonymous until commitment means a person can explore an AI experience without unnecessary disclosure of identity. When they reach a value or trust boundary, the system can anchor the interaction through consent, payment, entitlement, recovery, or audit evidence.
How does Eye on AI work inside Ask Omega*?
Ask Omega* uses LAW-L1 to prove who or what is acting through a durable wallet/session identity. LAW-L2 then derives and enforces what that actor is allowed to do using consent, entitlement, recovery confidence, and audit evidence.
What is LAW-L1 (Local Authority Weight- Layer one) ?
Local Authority Weight- Layer one (LAW-L1) is the System ID layer. It establishes a durable, recoverable, auditable interaction identity using wallet/session identity, persistence, request authority, email recovery, settings, and audit infrastructure.
What is LAW-L2?
LAW-Layer 2 is the Authority State layer. It defines what an actor is allowed to do by evaluating consent, evidence of entitlement, session trust, recovery confidence, and the audit state before protected AI capabilities proceed.
How does Eye on AI support x402 and API-native payment?
Eye on AI supports commitment-based access through API-native payment channels such as x402. A capability can be requested, payment or entitlement evidence can be checked, and the AI result can be delivered only when the authority state allows it.
How does this help a 1,000-person study cohort?
For a study cohort, Eye on AI gives each participant a governed interaction rail. Participants can begin with anonymous or pseudonymous access, then unlock trusted AI capabilities only when consent, entitlement, identity continuity, and audit requirements are satisfied.
Does Eye on AI replace human consent?
No. Eye on AI does not replace human consent. It helps make consent operational by connecting accepted terms or LAW levels to the authority checks that determine whether a trusted AI capability may proceed.
What is the simplest way to describe Eye on AI?
Eye on AI means: anonymous until value, authorised at commitment, audited at action. It is a Human–AI–AI security layer for governed AI systems.
Most software asks a simple question before it lets someone in:
“Are you a user?”
Sometimes it asks an even weaker question:
“Are you human?”
That is the world of passwords, logins, sessions, and CAPTCHA.
But agentic AI changes the problem.
When an AI system can answer, reason, recommend, transact, summarise, personalise, escalate, or act on behalf of someone, the real question is no longer just whether a person can access the app.
The question becomes: Is this AI action authorised?
That is the reason for the Eye on AI Protocol.
Eye on AI is our Human–AI–AI security layer for Ask Omega*, CIE, Clarity, and the wider DBZ application ecosystem. It is designed to govern the boundary between a human, an AI capability, and a second AI governance layer that checks identity, consent, entitlement, trust, and auditability before trusted actions proceed.
In simple terms: Not “prove you’re human.” Prove the action is authorised.
From the tech labs to primetime: Trusted insights, featured stories.
