Protocol architecture

Four protocols.
One governance stack.

The Yandeh Holdings portfolio covers the complete authority governance stack for distributed autonomous systems — from machine identity through communication admission, incident response governance, and the cryptographic receipt infrastructure underlying all of it.

The stack
Layer 01
Identity
AMIAP
Machine identity & execution authority
Cryptographically attested machine identity bound to constraint-evaluated execution authority artifacts. No action executes without a valid signed artifact evaluated against the runtime context at execution time.
Layer 02
Governance
VEMP
Communication admission control
Pre-decryption admission via artifact-bound state machines. HSM key release conditioned on admission compliance. Lineage constraints propagated to derived communications.
AIRAP
Incident response governance
Artifact-bound cyber remediation with ten-state deterministic lifecycle enforcement and severity-based escalation authority.
CVEAR · Layer 03 · Evidence
Cryptographically Verifiable Execution Authorization Receipt Protocol
Hash-chained · replay-proof · cross-domain verifiable · append-only registry · horizontal across all layers
Horizontal Root
Protocol deep dives
AM
AMIAP · YH-AMIAP-001 · G06F 21/57 · H04L 9/32
Autonomous Machine Identity & Authority Protocol
Conventional identity and access management systems — including OAuth 2.0, SPIFFE, and XACML — evaluate authorization at credential issuance time, not at execution time. By the time an autonomous machine acts on its authorization, the runtime conditions that justified the grant may have changed. AMIAP closes this gap by requiring that every execution request be accompanied by a cryptographically signed authority artifact evaluated against the runtime context at the exact moment the computational operation is requested.
Prior art deficiency
No existing system encodes, for a specific machine and a specific execution scope, the precise constraints that must hold at execution time, validates those constraints against a runtime context obtained at the moment of the request, and records the result as a tamper-evident cryptographic receipt enabling independent third-party verification — all within a single protocol.
Contribution 01
Authority artifact
Cryptographically signed data structure encoding machine identity binding, execution scope, permission boundary, execution constraints, integrity proof obligations, and authority expiration. Signed within a Hardware Security Module.
Contribution 02
Runtime constraint evaluation
Multi-dimensional constraint evaluation against runtime context obtained at execution time — not at session establishment, authentication, or credential issuance. Scope, boundary, action authorization, temporal constraint, and integrity evidence evaluated concurrently.
Contribution 03
Tiered authority delegation
Formal mechanism by which a machine entity holding an authority artifact can issue sub-artifacts encoding a bounded subset of the parent authority to subordinate machine entities, with cryptographic lineage binding and revocation propagation.
Contribution 04
Verifiable execution receipt
Cryptographic proof structure produced by the enforcement point binding the authorization decision, authority artifact identifier, runtime context digest, and evaluation result — enabling any authorized third party to confirm the decision without accessing the enforcement point's internal state.
IPC: G06F 21/57 · H04L 9/32 · Filed 2025 · Track One · 30 claims · 4 independent
VP
VEMP · YH-VEMP-001 · H04L 9/32 · G06F 21/60
Verifiable Enterprise Messaging Protocol
Secure messaging architectures — including S/MIME, OpenPGP, and TLS-based transport — grant access to communication content upon possession of a decryption key. There is no admission evaluation between message delivery and content access. VEMP introduces that missing layer: a dual-plane architecture in which the admission control plane evaluates a message authority artifact against the ciphertext before any decryption key is released from the Hardware Security Module.
Prior art deficiency
No existing communication system maintains a formally defined multi-state communication state machine with artifact-bound state-transition validation, enforces admission control prior to decryption key release with defined failure behavior, propagates authority constraints cryptographically to derived communications, or produces tamper-evident verifiable receipts for each state transition.
Contribution 01
Pre-decryption admission control
Admission evaluation performed on the ciphertext against the message authority artifact, before any decryption key is released. Failed admission retains the communication object in the first plane without content exposure.
Contribution 02
Nine-state communication automaton
Formally defined states: delivered, admission-pending, admitted, release-qualified, released, partially-released, reevaluation-pending, revoked, expired. Each transition requires validation of artifact-encoded preconditions.
Contribution 03
Lineage constraint propagation
Derived communications — replies, forwards, AI-agent responses — are cryptographically bound to the authority constraints of the parent communication. No derived communication can assert a wider scope or weaker cryptographic profile.
Contribution 04
Post-quantum HSM key release
Decryption key release conditioned on admission compliance and enforced within the HSM boundary using FIPS 204 (ML-DSA) and FIPS 203 (ML-KEM) post-quantum cryptographic primitives.
IPC: H04L 9/32 · G06F 21/60 · Filed March 2026 · Track One · 30 claims · 4 independent
CV
CVEAR · YH-CVEAR-001 · H04L 9/32 · G06F 21/64 · Forthcoming
Cryptographically Verifiable Execution Authorization Receipt Protocol
Authorization decisions in distributed autonomous systems are currently recorded, if at all, as internal log entries that are not portable, cannot be presented to independent third parties as self-contained proof, require access to the issuing system's internal state to verify, and cannot be cryptographically chained to detect deletion or reordering. CVEAR defines what a receipt actually is — a structure that can be verified by anyone, anywhere, without asking the enforcement point anything.
Prior art deficiency
No existing system defines a protocol-required unique receipt identifier enabling deterministic chain construction, a request-bound nonce with requester-contribution property preventing enforcement-point-unilateral replay, cross-domain portability without shared infrastructure, a receipt registry query protocol, multi-party receipt co-signing as a post-issuance endorsement, or post-revocation receipt annotation without chain modification.
Contribution 01
Globally unique receipt identifier
Protocol-required unique identifier incorporating the enforcement point's globally unique identifier as a mandatory component. Enables deterministic chain construction and unambiguous registry indexing across heterogeneous enforcement architectures.
Contribution 02
Request-bound nonce
Nonce contributed by the requesting machine entity incorporating its identifier and a session-unique value the enforcement point cannot generate unilaterally. Prevents replay of the receipt as authorization for any execution other than the specific request instance that generated it.
Contribution 03
Cross-domain portability
A receipt generated by an enforcement point in one administrative domain can be verified by any authorized verifier in any other domain using only the receipt and the enforcement point's public key — without shared infrastructure or communication between domains.
Contribution 04
Post-revocation annotation
When an authority artifact is subsequently revoked, receipts generated before revocation remain valid and unmodified in the registry, but receive an annotation identifying revocation timestamp and reason — preserving chain integrity while enabling verifiers to distinguish pre- and post-revocation receipts.
IPC: H04L 9/32 · G06F 21/64 · Standalone root application · Forthcoming · 25 claims · 4 independent
AR
AIRAP · YH-AIRAP-001 · H04L 9/32 · G06F 21/57 · Forthcoming
Autonomous Incident Response Authority Protocol
SOAR platforms, SIEM systems, EDR agents, and XDR architectures execute millions of automated remediation actions annually — yet no existing system defines a formal protocol governing authority over these actions. Platforms execute playbooks and apply policy rules, but no existing system binds each remediation action to a signed, incident-scoped authority artifact evaluated at execution time. AIRAP defines that protocol.
Five prior art deficiencies addressed
No incident-scoped authority artifact. No formal incident-response state machine. No artifact-bound constraint validation at execution time. No formal severity-tier escalation semantics producing versioned artifact extensions. No cryptographically verifiable, tamper-evident response receipt chain. AIRAP provides all five.
Contribution 01
Incident authority artifact
Cryptographically signed data structure encoding, for a specific incident: authorized remediation actions explicitly enumerated, prohibited actions, affected asset scope, authority expiration, severity tier, escalation rules, revocation triggers, and delegation rights.
Contribution 02
Ten-state lifecycle automaton
DETECTED → VALIDATED → TRIAGED → AUTHORIZED → CONSTRAINED_EXECUTION → ESCALATED → REMEDIATED → REEVALUATION_PENDING → REVOKED → CLOSED. Each transition requires cryptographic validation of the incident authority artifact.
Contribution 03
Severity-based escalation
Four-tier severity model (LOW, MEDIUM, HIGH, CRITICAL) with formal escalation semantics. Each escalation produces a new artifact version with expanded authorized action scope, signed by the escalating authority with a reference to the predecessor version.
Contribution 04
Distributed responder coordination
Primary-secondary delegation model in which a primary responder holds the master incident authority artifact and delegates sub-artifacts to secondary responders, each encoding a bounded, non-overlapping scope with conflict detection.
IPC: H04L 9/32 · G06F 21/57 · Forthcoming · Track One (planned) · 26 claims · 3 independent