Control how access is handed on.
Server-side governance of how credentials are derived.
Know which agent acted on whose authority, and stop it in one step.
YAR gives every delegation — to a colleague, a contractor, an app or an AI agent — a parent, a budget and an expiry, enforced when the credential is created. Revoke one, and everything derived from it goes too.
Access rarely stays where it was granted.
A manager asks a new starter to renew a contractor; the contractor brings in a specialist for a week; an AI assistant spins up a helper agent. Each hop is approved in a different place — the identity provider, a ticket, a Salesforce connected app — and none of them holds the whole chain. When something goes wrong, nobody can say quickly who authorised what, what was passed on, or how to pull it all back.
OAuth tokens stolen from a single third-party integration were used against the Salesforce data of more than 700 organisations.
Source: AppOmni, Salesloft Drift incidentHow it works.
{{ phase.msg }}
What makes YAR different.
Derivation happens server-side.
Token formats such as Macaroons, Biscuit or Tenuo let the holder narrow a token offline. That is fast, but nobody sees the full delegation tree, and revocation depends on expiry or on every verifier holding an up-to-date revocation list. YAR issues every child credential itself, so the tree is visible, budgets hold, and revocation takes effect at the next check.
Structure, not content.
YAR stores opaque IDs, parent links, limits and timestamps — no names, no payloads. Your systems keep identity and join it locally, so YAR stores no names or identity attributes — only opaque identifiers that your systems resolve locally.
Not a blockchain.
One operator, an append-only log, no consensus, no mining, no tokens. The nearest relative is a certificate-transparency log.
The science.
YAR enforces three properties when a credential is created, not after the fact.
- 01 Bounded attenuation A derived credential never exceeds its parent in depth, budget, scope, permitted operations or lifetime.
- 02 Bounded propagation Each credential carries a budget and a depth limit, checked and updated in one atomic step, so the number of credentials that can descend from a root is bounded by the budget and depth limits set at issuance.
- 03 Erasure-safe revocation Revoking a credential invalidates its descendants by walking parent links that survive data erasure.
Two ways to work with us.
Design-partner pilot
YAR runs beside your stack on one delegation flow — contractor onboarding, a partner integration or an AI-agent chain — and produces the chain-of-custody record, budgets and cascade revocation.
Apply to pilotLicence
For identity, SaaS-security and agent platforms. License the engine for your own token service, or talk to us about the patent application.
Talk to usWho it's for.
Regulatory evidence.
YAR provides technical evidence relevant to these controls. Organisations determine how their obligations are implemented and evidenced; YAR does not make an organisation compliant on its own.
Origin.
TARTU, ESTONIA
YAR combines process engineering, twelve years of enterprise IT and CRM delivery, and legal training.
It was designed from direct experience of how access and integrations are granted through fragmented request channels — as the missing architectural piece to evidence regulatory compliance.
Questions.
Is YAR a blockchain?+
No. One operator, an append-only log, no consensus, no mining, no tokens. The closest analogue is a certificate-transparency log.
Does it replace Okta, Entra ID, SailPoint or Salesforce?+
No. They establish who someone is and what a role allows. YAR records and limits how that access is handed on once it leaves its origin.
How is this different from Macaroons, Biscuit or Tenuo?+
Those narrow a token offline, in the holder's hands. YAR does derivation server-side, so the whole tree is visible, budgets are enforced, and a revocation reaches every descendant at its next check.
What is patented?+
A European patent application (EPO, filed 28 May 2026), System and method for constraint-enforced propagation of credentials, covers the method. It is pending, not granted, and not yet published. Current stage: search.
Where does our data live?+
YAR stores structure: opaque IDs, parent links, limits and timestamps. Names and content stay in your systems, which join them locally.
What happens when someone asks for erasure?+
Associated personal data is erased. The opaque structural record stays, so revocation and audit keep working. Keeping that record should rest on a legal obligation or legal claims (GDPR Art 17(3)(b) or (e)).
Is it production-ready?+
The engine (v1.1) is implemented and tested under controlled conditions. We are taking a small number of paid design partners for Q1 2027 to run it against real delegation flows.
Talk to us.
Tell us about a delegation flow you need to govern.