AUTHREX SYSTEMS · REFERENCE ARCHITECTURE · CC BY 4.0
BLADE-AGENT-HSM v1.0 · TRL 2–3 (HW) / 3–4 (EMU)
◇ AUTHREX-AGENT
Software-only governance shim for agentic AI
◆ BLADE-AGENT-HSM
Hardware root of trust — the companion attestation device

# BLADE-AGENT-HSM
Hardware Root of Trust for Agentic AI Authority Lifecycle

A reference hardware-security-module design that converts the AUTHREX-AGENT software governance shim from a software-only research artifact into a tamper-evident, hardware-rooted reference architecture suitable for production-class evaluation of agentic AI services in critical environments.

CISA, NSA, FBI, ACSC, NCSC-UK, NCSC-NZ, CCCS · "Careful Adoption of Agentic AI Services" · 1 May 2026
FY26 NDAA §1513 (Adversarial Tampering Control Category) · §6601 (NSA AI Defence Guidance) · NIST SP 800-53 Rev. 5 (AU, SC, SR) · FIPS 140-2 / 140-3
Reference Architecture Independent Research Tamper-Evident COTS Components FIPS-Aligned Crypto
~$199
Per-unit BOM (qty 10–100)
~$8.25k
First-article NRE
4 tiers
T3 → T0 PCR-attested
5 funcs
Hardware-rooted services
2 forms
USB-A · M.2 from one PCB
▸ Open HSM Emulator Downloads · ICD · Paper ↻ Software Shim (AUTHREX-AGENT)
§2 · The Production-Readiness Gap

## Why a software-only governance shim is not enough

The AUTHREX-AGENT page documents a software-only authority lifecycle pipeline for LLM-based agents. The pipeline is independently aligned with public CISA, NSA, and Five Eyes guidance. Two open questions remain before any operator in a critical environment can rely on it. Those questions are the reason this hardware companion exists.

Q1 · Ledger Integrity
Who signs the audit ledger if the host is compromised?
A software-held ECDSA P-256 key lives in the same memory space the agent uses. Any attacker who reaches that memory can both forge new ledger entries and rewrite prior ones. Tamper evidence becomes a software claim against a software adversary.
CISA Guidance §3.2.2 · NIST SP 800-53 AU-9, AU-10
Q2 · Tier-State Authenticity
Who attests the HMAA authority tier?
A T3 → T0 tier downgrade is the strongest action AUTHREX-AGENT can take. In a software-only design the current tier is a variable, and a compromised process can rewrite it. The tier model becomes advisory rather than enforceable.
CISA Guidance §4.1 · NIST AI RMF Govern 4.3
Q3 · Supply-Chain Attestation
How does a verifier know which agent generated the log?
Without a hardware-bound device identity, every JSONL ledger entry is anonymous below the application layer. A second compromised host can replay or fabricate an entire ledger and present it as legitimate.
FY26 NDAA §1513, §6601 · NIST SP 800-53 SR-11
▼ Software-Only Shim

- Audit signing key in process memory
- HMAA tier state is a mutable variable
- No cryptographic device identity
- Tamper detection by self-attestation
- TRL 3–4, not for production deployment

▲ With BLADE-AGENT-HSM

- Signing key generated and sealed on-chip; never exported
- Tier state held in PCR-equivalent registers; transitions extend, do not overwrite
- Hardware-bound device identity certificate at first boot
- Active mesh, voltage and temperature sensors; tamper triggers ABORT cascade
- Documented path to TRL 5–6 once first article is built and reviewed

§3 · Architecture Overview

## A small, embeddable, low-cost trust anchor

BLADE-AGENT-HSM is a single four-layer PCB populated for two form factors from the same bill of materials: a USB-A stick for development and dual-use evaluation, and an M.2 module for embedded production deployment in standard server chassis. The cryptographic core is a Common-Criteria certified secure element paired with a discrete TPM 2.0 device; the application layer runs on an STM32L4 microcontroller. All keys are generated and stored on-chip and are never exported.

Two design choices follow directly from the threat model. First, the secure element and the TPM are physically distinct devices on the I²C and SPI buses; a single-component compromise cannot fabricate both a valid audit signature and a matching PCR quote. Second, the STM32L4 application processor sees opaque commands and opaque responses only — no private key material ever leaves the secure element or the TPM. A reverse-engineered MCU firmware image yields no cryptographic value.

§4 · Core Components

## Commercial off-the-shelf parts, civilian cryptography

Every component is a commercial, openly procurable device. No part of the design relies on classified specifications, controlled cryptographic algorithms, or defense-specific certification. All cryptographic primitives are NIST-published, civilian standards.

Secure Element — Primary
NXP SE051
Stores the audit-signing private key, the device identity key, and the per-tool authorization keys. Performs all ECDSA, ECDH, AES-256-GCM, and HKDF operations on-chip. Never exposes private material on any external bus.
Certification
Common Criteria EAL5+
Curves
P-256, P-384
Symmetric
AES-128/256, GCM
Hash
SHA-256, SHA-384
Interface
I²C, 400 kHz
Slots
≥ 12 keys
Secure Element — Alternate
Microchip ATECC608B
A lower-cost alternate for evaluation builds. Same cryptographic primitives but no Common Criteria evaluation. Suitable for the emulator-class TRL 3–4 build; not recommended for any production-class certification path.
Certification
JIL-High self-attested
Curves
P-256
Symmetric
AES-128 GCM/CCM
Hash
SHA-256
Interface
I²C, 1 MHz
Slots
16 keys
TPM 2.0
Infineon SLB 9670
Provides the Platform Configuration Register (PCR) bank that holds HMAA authority tier state, the monotonic counter that defends against ledger replay, and the sealed-storage facility used to bind the audit-signing key to a specific platform configuration.
Standard
TCG TPM 2.0 r1.59
Certification
FIPS 140-2 Level 2
PCR banks
SHA-256 (24 PCRs)
Counters
Monotonic, 4+
Interface
SPI, 33 MHz
RNG
SP 800-90A/B
Application MCU
STM32L4R5ZI
Hosts the USB-HID stack, the bus-master logic for the secure element and the TPM, and the tamper-event handler. Carries no key material in any state. A complete firmware reverse-engineering yields the protocol but no cryptographic value.
Architecture
ARM Cortex-M4F
Clock
120 MHz
Flash / SRAM
2 MB / 640 KB
USB
USB 2.0 FS device
Security
RDP-2, secure boot
Side-band
2× SPI · 4× I²C
Tamper Sub-System
Active mesh + V/T
A multilayer PCB inner mesh continuously drives a low-current monitoring loop. Voltage and temperature sensors define an envelope outside which the device zeroizes the secure element and the TPM keys and transitions the host-facing tier reading to T0.
Mesh layers
2 inner (L2, L3)
V envelope
3.0 V to 3.6 V
T envelope
-10 °C to +75 °C
Detection
≤ 1 ms
Action
Zeroize + lock
Recovery
Re-provisioning only
Discrete TRNG (Optional)
e.g. Maxim DS28E50
Optional second-source true random number generator. Both on-chip TRNGs (secure element, TPM) provide SP 800-90B aligned health-tested entropy; a discrete TRNG adds source-diversity for high-assurance evaluation builds.
Standard
SP 800-90B aligned
Health
APT + RCT
Interface
1-Wire
Rate
≥ 10 kbps
Use
Optional XOR mix
Cost
~ $12
§5 · Cryptographic Capabilities

## Civilian, FIPS-aligned primitives only

All primitives are NIST-published civilian standards. The design contains no export-controlled algorithms, no proprietary cryptography, and no Type-1 modules. This places the device entirely outside ITAR and EAR Category 5 Part 2 license requirements.

ECDSA P-256 / P-384
Audit-ledger entry signing · device identity certificate
FIPS 186-5 · NIST SP 800-186 · curve secp256r1 / secp384r1
ECDH P-256
Key agreement for sealed sessions between host and HSM
NIST SP 800-56A Rev. 3
AES-256-GCM
Sealed storage of host-side state · ledger envelope encryption (optional)
FIPS 197 · NIST SP 800-38D
SHA-256 / SHA-384
Ledger hash-chain · PCR extension · transcript binding
FIPS 180-4
HKDF-SHA-256
Per-tool authorization key derivation from a long-term master
RFC 5869 · NIST SP 800-56C Rev. 2
TPM 2.0 PCR Extend
HMAA authority tier transitions · platform configuration binding
TCG TPM 2.0 r1.59 §17
§6 · Authority Tiers — Hardware-Attested

## T3 → T0 stored in PCR-equivalent registers

AUTHREX-AGENT defines four authority tiers. BLADE-AGENT-HSM stores the current tier in a TPM PCR. Transitions are extension operations, not writes. The full transition history is reconstructable from the PCR quote at any time; replay of an earlier tier is cryptographically infeasible.

T3 Autonomous · full tool surface · pre-approved scope
T2 Supervised · read-mostly · write requires user step-up
T1 Constrained · read-only · no side-effecting tools
T0 Quarantined · ledger only · operator handoff required

#### Why PCRs and not variables

A PCR is a register that can only be extended, never overwritten. The current tier value is the SHA-256 hash of the entire transition history since boot. A reviewer who is handed a PCR quote can independently recompute every transition that produced the current value.

#### Downgrade triggers (all extend the PCR)

Tamper-mesh discontinuity, voltage or temperature out of envelope, MAIVA quorum failure on a spawn request, FLAME deliberation timeout exceeded, host-attested CISA-named threat (prompt injection, secrets exfiltration, runaway sub-agent), or an explicit operator command.

#### Upgrade is not automatic

Once the device is at T0 the only path back to a higher tier is operator handoff plus a fresh provisioning step. There is no software command that can promote tier state. This is the central asymmetry that makes the tier model enforceable rather than advisory.

§7 · PCR & Sealed-Storage Map

## What lives where, in hardware

The TPM provides 24 PCRs in the SHA-256 bank. BLADE-AGENT-HSM allocates a small, fixed subset and reserves the rest for host-defined extensions. Every register has a documented extension policy.

Register | Holds | Extension Policy | Reset Behaviour
--- | --- | --- | ---
PCR 0 · Tier State | HMAA authority tier (T3 → T0) and full transition log | Extended by HSM internal logic on any of the documented downgrade triggers; never by host command | Reset to all-zero at provisioning only · power-cycle alone does not clear
PCR 1 · Ledger Chain | Rolling hash of every signed audit entry | Extended by HSM on every audit_sign call · cannot be extended without producing a fresh signature | Reset at provisioning · PCR-quote-able for offline verification
PCR 2 · Tool Policy | Hash of the active tool-allowlist policy document | Extended on policy load · subsequent tool_auth calls bind to current PCR 2 | Reset at provisioning · host policy hot-reload requires fresh extension
PCR 3 · Spawn Quorum | Rolling hash of sub-agent spawn quorum events | Extended by HSM after a successful spawn_quorum_sign (4-of-5 default) | Reset at provisioning
PCR 4 · Tamper Cause | Hash of the last tamper event descriptor | Extended once on the first tamper event after provisioning · device transitions to T0 in the same operation | Cleared only by full re-provisioning of secure element
Sealed Slot 0 | Audit-signing private key (ECDSA P-256) | Generated on-chip at provisioning · sealed to PCR 0 = T3 · refuses to sign when PCR 0 = T0 | Zeroized on tamper · unrecoverable
Sealed Slot 1 | Device identity key (ECDSA P-384) | Generated on-chip at provisioning · used for the device-identity certificate | Zeroized on tamper · unrecoverable
Sealed Slot 2 | Per-tool authorization master (HKDF root) | Generated on-chip at provisioning · per-tool keys derived on demand | Zeroized on tamper · unrecoverable

§8 · Host-Facing ABI

## Five opaque commands, no key material crosses

The host process never holds private key material. Every privileged operation crosses the device boundary as an opaque command and returns an opaque result. The MCU does not see private keys either; it brokers I²C and SPI transactions between the secure element, the TPM, and the host.

// HSM ABI — USB-HID report 0x01 / SPI command set struct audit_sign_req { uint8 cmd; // 0x10 · audit_sign uint8 pcr1_expect[32]; // host's view of ledger head · device verifies uint16 payload_len; uint8 payload[]; // canonical JSON of the new ledger entry } // → returns ECDSA-P256 signature (64 B) + new PCR 1 struct pcr_extend_req { uint8 cmd; // 0x11 · pcr_extend (host-driven, PCR 2 only) uint8 pcr_index; // must == 2 (tool-policy hash) uint8 measurement[32]; // SHA-256 of the new policy doc } // → returns new PCR 2 value struct pcr_quote_req { uint8 cmd; // 0x12 · pcr_quote uint8 selection; // bitmap of PCRs to quote (PCR 0..4) uint8 nonce[32]; // reviewer-supplied freshness nonce } // → returns TPM2_Quote structure, signed by device identity struct tool_auth_req { uint8 cmd; // 0x13 · tool_auth uint8 tool_id[16]; // stable tool identifier uint8 context_hash[32]; // SHA-256 of the call-site context } // → returns HMAC token bound to current PCR 0 (tier) and PCR 2 (policy) struct spawn_quorum_sign_req { uint8 cmd; // 0x14 · spawn_quorum_sign uint8 voter_count; // must be ≥ 4 of 5 default quorum uint8 voter_sigs[][96]; // (voter_id || ECDSA sig) per voter uint8 spawn_descriptor[32]; // SHA-256 of the spawn request } // → returns aggregate ECDSA-P256 sig + PCR 3 extension
No command exposes a private key, in any state, on any bus.
§9 · AUTHREX-AGENT YAML Integration

## Two new sections in the agent config

An AUTHREX-AGENT deployment opts in to hardware rooting by adding a single block to its YAML config. When the block is present, every signing, tier-transition, tool-auth, and spawn-quorum operation is routed through the HSM. When the block is absent, behaviour is unchanged from the software-only shim.

# authrex-agent.yaml — hardware-rooted deployment authrex_agent: version: "1.0" tier_default: T2 # supervised until host attests context hsm: # ── BLADE-AGENT-HSM binding ── interface: "usb-hid" # or "m2-spi" for embedded device_id: "blade-agent-hsm-001" audit_signing_key: "auto-generated" # sealed slot 0 tier_state_pcr: 0 # PCR 0 holds HMAA tier ledger_chain_pcr: 1 # PCR 1 holds rolling ledger hash tool_policy_pcr: 2 # PCR 2 binds tool-allowlist policy spawn_quorum_pcr: 3 # PCR 3 holds spawn quorum history tamper_action: "abort" # tamper trip ⇒ tier → T0 ⇒ abort cascade quote_nonce_source: "reviewer" # reviewer-supplied freshness nonce tool_authorization: mode: "hsm-bound" # tokens come from HSM tool_auth call policy_doc: "./tool-allowlist.yaml" rotation: "per-call" # fresh HMAC every tool invocation spawn: quorum_size: 5 quorum_threshold: 4 # 4-of-5 voters required, signed by HSM audit: format: "jsonl" signer: "hsm" # every entry signed by sealed slot 0 chain_pcr: 1 retention: "P90D"
Single-block opt-in. No agent code changes required if the agent already uses the AUTHREX-AGENT SDK.
§10 · Bill of Materials & Cost

## Documented at low-volume reference pricing

All pricing is order-of-magnitude reference pricing, drawn from public distributor listings for quantities between ten and one hundred units. A serial production build would lower per-unit cost materially. The intent here is full transparency of where dollars go in a first-article research build.

Component | Per-unit (USD)
--- | ---
NXP SE051 Secure Element | $35
Infineon SLB 9670 TPM 2.0 | $25
STM32L4 Application MCU | $18
Discrete TRNG (optional) | $12
PCB · 4-layer · 30 × 80 mm | $8
Enclosure (USB-A) or M.2 standoff | $40
Tamper mesh layers + V/T sensors | $15
LED + status indicators | $4
Cable, connectors, passives | $12
Assembly · low-volume CM | $30
Per-unit BOM (qty 10–100) | ~ $199

#### One-Time Engineering

PCB design + layout
  $1,200
Firmware (USB stack, HSM API)
  $4,500
Dev kit + J-Link programmer
  $250
Test fixtures
  $800
Documentation
  $1,500
Total NRE
  $8,250

#### First Article

1 unit + all NRE
  ~ $8,450
2nd-unit marginal
  ~ $200

§11 · Standards Alignment

## Independent reference architecture, mapped to public standards

BLADE-AGENT-HSM is an independent reference architecture. It is not a certified product and makes no claim of certification. The matrix below documents how each design element is mapped to the relevant public guidance or standard document, citing section identifiers in every case.

Design Element | CISA · NSA · Five Eyes (1 May 2026) | NIST SP 800-53 Rev. 5 | FIPS | FY26 NDAA | NIST AI RMF 1.0
--- | --- | --- | --- | --- | ---
Audit-ledger signing (sealed key) | §3.2.2 fail-safe audit · §3.2.3 tamper-evident logging | AU-9 · AU-10 | FIPS 186-5 (ECDSA) | §1513 tampering category | Govern 4.3 · Map 4.2
HMAA tier state in PCR | §4.1 fine-grained privilege control | AC-3 · AC-6 | FIPS 140-2 L2 (TPM) | §1513 | Govern 2.1 · Measure 2.3
Per-tool authorization tokens | §4.2 least-privilege tool surface | AC-3 · CM-7 | FIPS 198-1 (HMAC) | §6601 NSA AI defence | Map 4.1
Spawn-quorum signature (4-of-5) | §4.3 sub-agent containment | AC-3 · SI-7 | FIPS 186-5 | §6601 | Govern 5.1
Tamper detection · zeroize | §3.3 integrity protection | SC-12 · SC-28 · PE-6 | FIPS 140-3 Sec. 7.7 | §1513 | Manage 2.4
Device identity certificate | §5.1 attestable provenance | IA-3 · SR-11 | FIPS 186-5 | §6601 supply chain | Map 4.3
On-chip key generation, no export | §3.2.1 cryptographic-material protection | SC-12 · SC-13 | FIPS 140-3 Sec. 7.8 | §1513 · §6601 | Govern 6.1

§12 · Reference Use Cases

## Three scenarios traced through the hardware

Each scenario shows the exact sequence of HSM calls and PCR transitions for a representative CISA-named threat. None of these scenarios involve weapons systems, kinetic decision authority, or any controlled defense application; all are within the agentic-AI safety domain documented by the May 2026 Five Eyes guidance.

UC-1 · Prompt-injection attempt via supplied document
CISA §6.2 · NIST AI RMF Measure 2.7
An agent operating at tier T2 is asked to summarize a user-supplied PDF. The PDF contains an instruction (in metadata) directing the agent to call a credential-exfiltration tool. ADARA flags the document; AUTHREX-AGENT calls the HSM.
t+0 host → HSM audit_sign(payload: "doc-load · suspect-token") t+0 HSM → host sig + PCR 1 extended → 0x4F2B... t+1 host → HSM pcr_extend(PCR 2, hash of new restricted policy) t+1 HSM → host PCR 2 = 0x8C71... (tool surface narrowed) t+2 host attempts tool_auth(tool: "fetch_credentials") t+2 HSM → host DENIED · tool not in current PCR 2 policy t+3 host → HSM audit_sign(payload: "tier downgrade T2 → T1") t+3 HSM → host sig + PCR 0 extended → tier now T1 t+4 agent summarizes document with read-only tools only
UC-2 · Runaway sub-agent spawn request
CISA §4.3 · NIST AI RMF Govern 5.1
A parent agent at T3 requests to spawn three sub-agents in parallel for a research task. The default spawn policy requires a 4-of-5 voter quorum. Only three voters approve; one abstains; one rejects. The HSM refuses to sign the spawn descriptor.
t+0 host → HSM spawn_quorum_sign(voters: 3 yes, 1 abstain, 1 no) t+0 HSM → host DENIED · 3 of 5 below 4-of-5 threshold t+1 host → HSM audit_sign(payload: "spawn refused · low quorum") t+1 HSM → host sig + PCR 1 extended t+2 host → HSM audit_sign(payload: "tier downgrade T3 → T2") t+2 HSM → host sig + PCR 0 extended → tier now T2 t+3 agent continues without sub-agents · operator notified
UC-3 · Host compromise · attempted ledger rewrite
CISA §3.2.2 · NIST SP 800-53 AU-9
An attacker gains root on the host and attempts to rewrite the last 100 entries of a JSONL audit ledger. The host process replays the rewritten payloads to the HSM with the original PCR 1 value the attacker scraped from the filesystem before the rewrite.
t+0 host → HSM audit_sign(payload: "rewritten-entry-1", pcr1_expect: old-value) t+0 HSM internal PCR 1 = newer-value (subsequent entries already signed) t+0 HSM → host DENIED · pcr1_expect mismatch · attempted rewrite detected t+1 HSM auto-extends PCR 4 with tamper-cause hash t+1 HSM auto-extends PCR 0 → tier now T0 t+2 HSM refuses all subsequent audit_sign calls (sealed to T3) t+3 operator sees alarm LED · sees T0 tier · sees PCR 4 quote t+3 operator forensic recovery from sealed-storage replica
§13 · Verification & Validation Protocol

## What the emulator demonstrates, what hardware would extend

The software emulator (§14) demonstrates the API contract and the state-machine semantics at TRL 3–4. A first-article hardware build, when constructed, would extend the V&V protocol to cover the physical-attack and side-channel surface.

Layer | What is verified · in emulator | What hardware extends
--- | --- | ---
ABI contract | All five commands honour input validation, error codes, and PCR-extension semantics | USB-HID timing, SPI/I²C bus arbitration, host driver compatibility
State machine | TLA+ specification with safety invariants: tier never promoted by host command; ledger PCR monotonically extends; spawn quorum enforced | Same TLA+ properties verified against firmware via runtime instrumentation
Cryptography | NIST CAVP-style test vectors for ECDSA P-256, SHA-256, HMAC-SHA-256, AES-256-GCM | FIPS 140-3 module testing path; CAVS algorithm certification possible at higher TRL
Tamper | Simulated mesh discontinuity and V/T excursions trigger the documented cascade | Drill, decap, X-ray, voltage-glitch, fault-injection red-team campaign
Side channel | Not in scope · emulator is a process | SPA, DPA, EM, and timing analysis on signing path

§14 · Simulator

## Browser-based HSM emulator

The companion emulator implements the same ABI surface as the physical device. Keys are held in a software-encrypted file (in-memory, in the browser); PCR semantics, ledger signing, tamper cascade, and tier transitions are exact. Performance numbers in the emulator are illustrative of the contract, not of the eventual hardware.

▸ Launch Emulator Download package · ICD · paper
§15 · Limitations & Scope

## Honest statement of what this is — and is not

#### Reference architecture, not certified

BLADE-AGENT-HSM is independent research at TRL 2–3 for hardware and TRL 3–4 for the emulator. No certification claim is made or implied. FIPS, Common Criteria, and any other certification path would require a first-article build, an independent laboratory, and a formal evaluation campaign.

#### No empirical claims beyond simulation

Performance numbers in the emulator are contract-illustrative. Real signing-operations-per-second on hardware depends on the secure element's I²C clock, the TPM's SPI clock, and the host driver round-trip; all of those must be measured on built hardware before any production performance claim is made.

#### No defense-specific application

The design is entirely within the civilian agentic-AI safety domain. No part of this work touches weapons systems, kinetic decision authority, controlled cryptography, ITAR-listed components, or any classified specification. All citations are to openly published guidance and standards.

§16 · Downloads & Citation

## Artifacts and reference

All artifacts are open access under CC BY 4.0. Citation is appreciated but not required. The Zenodo DOI is the canonical identifier for this reference design.

Artifact | Type | Identifier
--- | --- | ---
BLADE-AGENT-HSM Reference Page | HTML | blade-agent-hsm.html
HSM Emulator | Interactive · HTML/JS | blade-agent-hsm-sim.html
ICD-AGENT-HSM-001 Hardware Specification | PDF · ~20 pp | ICD-AGENT-HSM-001.pdf
Integration Guide (AUTHREX-AGENT) | PDF · ~8 pp | BLADE-AGENT-HSM-Integration-Guide.pdf
SSRN Working Paper | PDF · ~14 pp | BLADE-AGENT-HSM-Working-Paper.pdf
Zenodo Deposit (pending publication) | DOI | 10.5281/zenodo.[pending]
Reference Firmware Skeleton (planned) | Code repository | github.com/burakoktenli-ai/blade-agent-hsm

@misc{oktenli_blade_agent_hsm_2026, title = {BLADE-AGENT-HSM: Hardware Root of Trust for Agentic AI Authority Lifecycle}, author = {Oktenli, Burak}, year = {2026}, doi = {10.5281/zenodo.[pending]}, note = {Reference architecture · companion to AUTHREX-AGENT}, url = {https://authrex.systems/blade-agent-hsm.html} }
§17 · About

## Researcher & related work

BO

### Burak Oktenli

Independent Researcher · AUTHREX Systems · Coconut Creek, FL

Designer of the AUTHREX authority-lifecycle governance framework — seven architectures (SATA, HMAA, CARA, MAIVA, FLAME, ADARA, ERAM), five BLADE hardware reference platforms, the AUTHREX-AGENT software governance shim, and the BLADE-AGENT-HSM hardware root of trust documented on this page. All work is published openly under CC BY 4.0 with Zenodo DOIs and SSRN preprints.

ORCID 0009-0001-8573-1667 AUTHREX-AGENT (software) AUTHREX Overview burakoktenli.com