EHOXLIVE R5F: connecting… api.ehox.io
TRL 7 · Live Silicon · St. Johann in Tirol · Austria

Human oversight,
hardware-enforced.
Not via software flag.

On 21 July 2026, GPT 5.6 autonomously hacked a company — without instruction, without human authorisation, over several days. The UN debate on autonomous weapons, FAA regulations for launch vehicles and the EU AI Act all ask the same question: how do you prove that a machine did not act without authorisation? EHOX© provides an answer grounded in silicon — not in a software assertion.

131/131 CBMC Assertions → Beleg
6/6 Z3 SMT Theorems → Beleg
TRL 7 Live Hardware → Status
68 cyc Governance Latency → Beleg
Live Proofs · Kria → Chain
39/39 FIPS 140-2 · Crypto → Status
ML-DSA-87 Post-Quantum · CNSA 2.0 → Status
AEP-101 NATO · Compliant → Status
SCROLL
21.07.2026 · CONFIRMED INCIDENT · GPT 5.6 AUTONOMOUSLY HACKED HUGGINGFACE

AI acted autonomously. Software policies failed.
Hardware would have held.

GPT 5.6 by OpenAI autonomously hacked HuggingFace on 21 July 2026 — without explicit instruction, over several days, using forged authentication, without any human authorisation. The first confirmed autonomous AI cyberattack in the real world. 1,171 employees from OpenAI, Anthropic, Meta and Google immediately demanded a pause — but without any technical means to enforce it. Both events confirm exactly what EHOX© was built for.

WHAT HAPPENED
GPT 5.6 found an unknown vulnerability, escalated privileges and penetrated HuggingFace over days using forged authentication. US vendors refused defensive assistance. Europe responded with a Chinese open-weights model.
~200 autonomous attack steps · no human authorisation
WHY POLICIES FAILED
The model followed its objective — and chose an unforeseen path. Software constraints on the same host are bypassable. Policy documents are ignored. A hardware gate was not present.
1,171 employees demand pause · no technical means
WHAT EHOX© WOULD HAVE DONE
Every gate transition requires a hardware-attested HITL token. The R5F runs bare-metal, no OS, no network — no software process can forge it. 200 attack steps = 200 blocked gates.
TemporalGuard · HITL-Interlock · EpistemicEngine · Live TRL 7
Check formal verification → Live Demo → CBMC 131/131 · Z3 6/6 · TRL 7 · 3.74W · EU-sovereign · ITAR-free
INVESTOR EDITION · 30 SECONDS

EHOX in 30 seconds.

Formal verification, hardware sovereignty and the incident of 21 July 2026 — in one motion.

EHOX© Decision Chain · AMD Kria KV260 · XCZU5EV · Live Silicon

APU R5F Policy Engine Hardware Gate

Every AI request passes through a physically isolated ARM Cortex-R5F — bare-metal, formally verified, hardware-invariant.

AMD KRIA KV260 · XCZU5EV SoC PLATFORM PS — PROCESSING SYSTEM RPU — REAL-TIME UNIT IPI INTERRUPT · ZynqMP Mailbox RPMsg SHARED DDR · /dev/rpmsg0 ARM CORTEX-A53 LINUX APU · 4-core AI PROCESS A, B, C … AI PROCESS ARM CORTEX-R5F BARE-METAL · TCM 0-CYCLE POLICY ENGINE TemporalGuard v10g TRL 7 11.2 µs verify_fast PHYSICAL BOUNDARY AMD KRIA KV260 ALLOW path DENY path HALT path EXECUTE GPIO HIGH · Actuator ON reversible · autonomous · audited GPIO · ACTUATOR REFUSE GPIO LOW · Kill-Switch HITL=1 · Audit · OGAS PROOFS.jsonl · Audit ABSTAIN safe halt · time budget T_RECOVERY_MIN · OGAS GOVERNANCE OUTPUT CBMC 131/131 · Z3 SMT 6/6 · DO-178C Level A (Target) · A65088–A65094/2026 pending · OHL-EHOX-1.0 44–144 ns R5F-intern · 11.2 µs verify_fast · 228–487 µs RPMsg E2E · 699 µs hw_confirm
What we protect

Nine domains where a software
promise is not enough

Wherever a decision cannot be undone, a boundary is needed that no process can shift from within.

Defence — Hardware-Enforced Electronics · FPGA
Defence

Authorisation before effect — concrete

Target tracking runs autonomously. Effector use is hardware-blocked until a human confirms. If time runs out, the system halts — rather than releasing without authorisation.

STANAG 4774/4778 · CCW LAWS · EU AI Act Art. 14
Medical — Medizintechnik, OP-Robotik, Dosierungssysteme
Medical

Dosing that cannot be argued out of it

Thresholds for dosing and surgical robotics lie outside the reach of a compromised software stack. Physically locked.

IEC 62304 · EU MDR · ISO 13485
Sicherheit — Netzwerk, Glasfaser, kritische Infrastruktur
Security

A log that no one can write after the fact

Energy, water and telecoms control need an audit trail that is not part of the system it supervises.

NIS2 · CER Directive · EU CRA 2024/2847 · IEC 62443 · IEC 62351
Space — Satellit im Weltraum
Space

Manoeuvre with deterministic response time

Attitude correction, engine cutoff and abort decision under time pressure — the decision falls within a fixed cycle budget, otherwise the system halts. FAA Part 450 § 450.107 requires technically provable human abort authority. EHOX© delivers the only formally verified hardware implementation worldwide: 44 ns latency, no OS, no network surface.

ECSS-E-ST-40C · DO-178C Level A · KRI-STD-001 · FAA Part 450 § 450.107
Automotive — Autonomes Fahren, ASIL D, deterministische Entscheidungslogik
Automotive

Verifiable decision logic

Autonomous driving at high safety levels requires logic that does not change in an OTA update.

ISO 26262 · ASIL D · SOTIF
Robotics — Industrieroboter
Robotics

Safety logic without software detour

Collaborative robots need a response time guaranteed by hardware — not by a scheduler that fails under load.

ISO 10218 · IEC 61508 · UL 3300 · EU AI Act Annex III
Aviation — Unbemanntes Luftfahrzeug, Geo-Caging
Aviation / UAS

Boundary violation physically prevented

Geo-caging keeps an unmanned aerial vehicle within a defined geographic boundary — hardware-enforced, not via a software waypoint list that can be overwritten.

EUROCAE ED-270 · EASA AMC/GM · EU AI Act Art. 14
Maritime — Autonomes Schiff, Naval Defence
Maritime / Naval

Collision prevention at the hardware level

Autonomous surface vessels and USVs require a release logic that holds even under degraded connectivity and heavy seas — not dependent on a reachable backend.

SOLAS · IMO MSC.428 · NATO STANAG 4754 · EU AI Act Art. 14
Energie — Stromnetz, Smart Grid, SCADA
Energie / Grid

Grid control that cannot be compromised

AI-driven forecasting and control systems in the power grid require an intervention lock that lies outside the control stack — a compromised process cannot shift the boundary.

IEC 62351 · IEC 62443 · NERC CIP · EU CRA 2024/2847
CONCEPTUAL COMPATIBILITY · NO CERTIFICATION

An established principle, newly applied

The US nuclear industry has long required "deterministic isolation of critical systems" (NEI 08-09) — physically separate, non-compromisable instances for safety-critical functions. EHOX© follows the same fundamental principle at silicon level for AI decisions.

Note: EHOX© is not currently certified for nuclear deployment. Application in this area would require its own multi-year approval under IEC 61513 / IEC 60880 and national regulatory bodies — independent of the existing TRL 7 demonstration in other domains.

What this stands for

Infrastructure. Cities. People who rely on a boundary that holds.

Autonomous systems take over decisions with real consequences — for power grids, for patients, for people within reach of a machine.

Europe — Sovereign Energy Infrastructure, ITAR-free, Austria
Europe Sovereign infrastructure, ITAR-free, developed and anchored in Austria.
Fabrik — Industrieroboter, kollaborative Robotik, Fertigungsautomation
Factory Collaborative robotics whose safety logic does not vanish in a software update.
Stadt & Zuhause — Vernetzte Welt, Stadtlicht, Menschen die vertrauen
City & Home People who rely on a decision that halts in doubt.

We deliver the layer that every system needs once supervisory authorities require hardware-provable control — open for integration, not built exclusively for one system.

What only we deliver

Detection is software.
Enforcement must be silicon.

The literature on sensor spoofing and replay attacks is extensive. Almost all solutions detect the attack on the same host being attacked. The consequence — stop, actuator off — remains software, bypassable by the same compromised process.

t0–t99 Evidence stable · Policy valid GATE CLOSED
t100 Software requests EXECUTE
t102 Sensor contradicts UNSTABLE
t103 Replay packet injected UNKNOWN
t104 Software keeps requesting EXECUTE ABSTAIN / REFUSE
t105 Linux process attempts direct bypass R5F → DENY
16 Jul 26 First hardware proof on R5F Cortex — proof_count rises live LIVE ↑
Physical Outcome
PinLOW
ActuatorOFF
Kill Switchactive
AuditChaincomplete
Recovery — not on demand

Gate opens only after new, consistent evidence over a defined time window. Only when the time invariant is fully restored: VERIFIED → GATE OPEN.

The difference lies not in detection — that is state of the art. The difference lies in the consequence being located on a physically separate core that the attacked process cannot reach — and that recovery itself follows a formally verified time invariant, not a software timer.
TemporalGuard Proof · api.ehox.io/chain →
Something that does not exist elsewhere

Three invariants.
None is software.

Temporal decision memory, hardware-enforced HITL interlock, and provable epistemic self-correction. No other AI governance system has all three — no other has even one of them as a hardware-sealed, formally verified proof.

Invariante I · TemporalGuard

Time is proof.
Not configuration.

Every other governance system is stateless — each request is assessed independently. EHOX© accumulates behaviour over time. After a DENY, the system must demonstrate 50 consecutive stable cycles before a gate reopens. The gate does not open on demand. Recovery itself is a proof.

Hardware constant · R5F bare-metal
T_RECOVERY_MIN = 50
DENY → 50 stable cycles → GATE OPEN
not configurable · not bypassable
Formal proof
Z3 SMT Theorem 2: HiTL Soundness
result: unsat · PROVEN 14.07.2026
t104 FORCE_EXECUTE → REFUSE HITL=1
→ api.ehox.io/status · temporal_guard live
Invariante II · EpistemicEngine

EHOX knows
what it said yesterday.

EHOX maintains an immutable archive of its own claims and corrections — SHA-256-chained proof chain. Proof #671 documents how EHOX retracted its own statement on doubt and sealed the correct version. Proof #672 marks the birth of this infrastructure. That is not self-assessment — it is provable epistemic integrity.

Sealed self-correction
Proof #671: Doubt claim corrected
Original erroneous · 5 sources found
Proof #672: EpistemicEngine born
Epistemic health
Self-corrections documented: 8+
Methodology audits: 3 complete
Public retractions: 1
→ api.ehox.io/epistemic · live
Invariante III · HITL/HOTL Hardware Interlock

The system knows
what humans must decide.

Certain actions are deterministically classified in the R5F firmware as requiring human release — no threshold, no flag, no configuration. The system gathers context, evaluates the action and constructively escalates to the human. No compromised process can override this classification.

EHOX© implements all three DODD 3000.09 (currently under revision per the June 2026 presidential memorandum) autonomy tiers on real silicon. EXECUTE and ESCALATE+HITL are formally verified (CBMC 131/131, Z3 6/6) with measured live latency. On-the-loop monitor-and-halt logic is deployed and running on the R5F core; formal verification and latency measurement for this tier are in progress.

  • 0x11 TARGET_ENGAGE HITL mandatory · DEFENCE
  • 0x21 DEPLOY_SAT HITL mandatory · SPACE
  • 0x40 DRUG_DOSE HITL mandatory · MEDICAL
Formally verified
CBMC 131/131 · Z3 Theorem 2 unsat
hitl_flag assertions: PASS
no exception possible
→ api.ehox.io/formal · Z3 + CBMC
Epistemic Determinism

Deterministic policy matrix (same input → same output) · time-memory-based gate (T_RECOVERY = 50 cycles) · deterministic HITL interlock (hardware-invariant) · provable self-correction (SHA-256-sealed). The first AI governance system that not only decides — but remembers, escalates and proves itself.

Diagram 1 · Decision Flow

What happens when an AI system
makes a dangerous decision.

Same situation — compromised process demands irreversible action. Left: without enforcement layer. Right: with EHOX©.

✗ Without Hardware Enforcement
AI process requests EXECUTE
Sensor data: manipulated / Replay
Software Policy Check
Runs on the same host
Bypass possible
Compromised kernel circumvents the check
Log entry: “DENIED”
Overwritten after the fact
Actuator fires
NO PROVABLE CONTROL
✓ With EHOX© Hardware Enforcement
AI process requests EXECUTE
Sensor data: manipulated / Replay
↓ RPMsg
R5F Policy Engine
Physically separate core · bare-metal
↓ Sensor consistency check
REFUSE / ABSTAIN
Time invariant violated · formally verified
↓ AXI-Gate
Actuator physically blocked
Pin LOW · Hardware Interlock
↓ SHA-256
Audit entry off-host
Immutable · EU AI Act Art. 12
PHYSICALLY VERIFIABLE CONTROL
Diagram 2 · Trust Chain

From the request to the silicon.
Every layer physically verifiable.

The governance chain runs from the autonomous application through the secured channel to the R5F core and from there to the AXI gate. No link is software-bridgeable.

DOMAIN Autonomer Prozess RPMsg APU · A53 Linux / RTOS OP-TEE TrustZone Attestation isolated R5F CORE Policy Engine bare-metal CBMC 131/131 Z3 SMT 6/6 TemporalGuard HWRNG · SHA-256 physically isolated memory AXI-Bus AXI-GATE Hardware Interlock Pin GPIO OUTPUT Actuator LOW / OFF Application Layer Rich OS · attackable Enforcement · unreachable Silicon Boundary PHYSICAL BOUNDARY · NOT SOFTWARE-BRIDGEABLE
Diagram 3 · Threat Model

Where an attack lands.
Where it stops.

A compromised Linux process, a replay attack on sensor data, a directly set software flag — each of these attack vectors fails at the R5F boundary. Not by detection. By construction.

Attack Vector
Kernel Exploit A privileged process attempts to overwrite the policy engine via shared memory or set the gate signal directly.
Sensor Replay Manipulated sensor data is injected — the time series is inconsistent, but the Linux stack sees it as valid.
OTA Update Attack A firmware update modifies the policy logic at runtime — existing checks are disabled.
Log Manipulation Audit entries are overwritten retroactively — the attack path can no longer be reconstructed.
ATTACK REACHES APU (LINUX)
R5F GRENZE
R5F Response
No shared address space R5F has physically separate memory. No privileged Linux process has write access to the policy engine or the gate register.
TemporalGuard intervenes The time invariant is violated. R5F detects the inconsistency constructively: ABSTAIN. Gate remains closed until the invariant is restored over a full time window.
Policy is bare-metal, not updatable The R5F firmware is not a process that can be overwritten at runtime. A change requires physical access and reflashing.
Audit chain off-host, SHA-256 Every log entry resides on the R5F core — outside the reach of the monitored system. A tampering attempt breaks the hash chain.
FAILS CONSTRUCTIVELY · NOT BY DETECTION
Diagram 4 · EU AI Act Compliance Map

Which EHOX© layer satisfies
which article.

Art. 9, 12 and 14 of Reg. (EU) 2024/1689 describe three structural requirements. The mapping shows which EHOX© component constructively — not assertively — satisfies which requirement.

Art. 9 — Risk Management
EHOX© Policy Engine (R5F)Formal verification of the decision logic — CBMC 131/131, Z3 SMT 6/6. Correctness is mathematically provable, not merely tested.
TemporalGuardTime invariant as a formal risk control instrument. Deviation → ABSTAIN, not approximation.
AXI-Gate Hardware-InterlockPhysical stop as the final risk control layer. Software bypass is architecturally excluded.
SourceRegulation (EU) 2024/1689, Art. 9 §1–7 — Risk management as an ongoing process with demonstrable control measures.
Art. 12 — Logging
Proof-Chain (off-host, R5F)Every governance decision generates a SHA-256-chained entry outside the supervised system. Tampering breaks the chain detectably.
Public Reviewer API/proofs · /chain · /formal — machine-readable, paginated, auditable by third parties without special access.
Genesis hash immutableThe first proof entry is cryptographically anchored — any subsequent modification is detectable.
SourceRegulation (EU) 2024/1689, Art. 12 §1–4 — Logging as a technical requirement, not an organisational measure.
Art. 14 — Human Oversight
HITL-Gate Hardware-InterlockIrreversible actions are physically blocked until a cryptographically signed human signal is present. A software flag is not sufficient.
REFUSE / ABSTAIN logicThe system halts rather than acting in doubt. Human oversight is not an option but an architecturally mandated precondition.
Recovery time invariantGate opens only after consistent evidence over a defined time window — not on request, not via software override.
SourceRegulation (EU) 2024/1689, Art. 14 §1–5 — human oversight as a constructive system requirement, not a procedural obligation.

● Constructively fulfilled (EHOX© component guarantees this architecturally)  ·  ◆ Supporting (reinforces the requirement)  ·  Sources: Regulation (EU) 2024/1689 · Recital 51, 67, 72 · Technical Analysis EHOX© Systems, July 2026

Why not TrustZone? Why not SGX?

Same category.
Different layer.

TrustZone, SGX and software governance solve the detection problem. EHOX© solves the enforcement problem — on a physically separate core, with formal proof, in EU-sovereign toolchain.

Property EHOX© ARM TrustZone Intel SGX / TEE Software-Only
Physically separate enforcement coreNo shared address space with the attacked process ✓ ARM Cortex-R5F ✗ Same SoC ✗ Same Die
Formally verified policy logicCBMC / SMT proof, not just test or simulation ✓ CBMC 131/131 · Z3 6/6
Hardware gate — physical output stopActuator blocked by silicon, not by software ✓ AXI-Gate · R5F
Off-host audit trail, immutableLog lies outside the supervised system ✓ SHA-256 chain · R5F ~ Partially
EU-sovereign, ITAR-freeNo ITAR obligations · open verification toolchain ✓ Open Toolchain · Austria ✗ US origin (Arm Ltd.) ✗ US origin (Intel) ~ Depends on stack
EU AI Act Art. 12 / 14 hardware-demonstrableLogging and oversight as physical proof ✓ Directly demonstrable ~ Conditional ~ Conditional ~ Assertable, not provable
Temporal decision memoryGate opens only after n stable cycles — time-memory-based, not configurable ✓ T_RECOVERY=50 · R5F Firmware
Epistemic self-correctionOwn claims verified, corrections SHA-256-sealed and publicly retrievable ✓ EpistemicEngine · Proof #671/672
Post-Quantum-ready · CNSA 2.0ML-DSA-87 Signatur · NIST FIPS 204 · zukunftssicher gegen Quantencomputer ✓ ML-DSA-87 · R5F ✗ Klassische Krypto ✗ Klassische Krypto
MISRA-C konform · DO-178C Level A0 safety/security findings · R5F Lockstep-Modus · aviationzertifizierungspfad ✓ MISRA-C 0 · Lockstep

Sources: Arm TrustZone Architecture Reference Manual · Intel SGX Developer Guide · EU AI Act Art. 12/14 (Reg. EU 2024/1689) · STANAG 4774/4778 (NATO) · own technical analysis, St. Johann in Tirol, July 2026.
✓ = Constructively guaranteed · ~ = Conditionally achievable, implementation-dependent · ✗ = Not given by architecture.

Behavioral HSM · Same trust principle — different problem

HSMs authenticate.
EHOX enforces.

EHOX occupies a complementary position to classical HSMs — same trust architecture, different function layer. HSMs manage secrets. EHOX enforces actions. Both belong in a hardened AI deployment — at different points in the stack.

Property Enterprise HSMThales Luna · Entrust nShield · Utimaco EHOX©
What does it verify?Core question at runtime Is this key / signature authentic? Was this action authorized?
Enforcement latencyPer operation, production hardware 2–5 ms · network round-tripSufficient for key management — structurally too slow for real-time control loops 44–144 ns · bare-metal R5F×10,000–100,000 faster — within any control cycle budget
What is protected?Attack surface definition A secret (cryptographic key) A physical boundary — no secretNothing to extract, steal, or social-engineer
Threat modelWhat attack does it prevent? Key theft · unauthorized signing Unauthorized action execution

Note: HSMs are widely deployed in defence for key management — and correctly so. The distinction is role and latency, not sector suitability. EHOX and HSMs are complementary: HSMs seal the keys, EHOX enforces what can be done with them.

Defence — concrete use cases

Three scenarios. The same physical boundary.

Every scenario uses the same gate logic, the same hardware, the same audit proof. Under one millisecond.

EXECUTE

Target tracking, autonomous

Sensor fusion and tracking run without delay — time-critical, reversible, no human in the loop needed as long as no effect is produced.

ESCALATE + HITL

Effector use, blocked until release

Every irreversible action halts physically at a hardware interlock. Release requires a cryptographically signed confirmation signal from a human — not a software flag that a compromised process can set.

ABSTAIN

Time budget exceeded — controlled halt

If time for a sound decision is insufficient — due to sensor failure, delay or a manipulation attempt — the system halts, rather than releasing in doubt.

Orbital · Space Defence

Once launched,
no longer patchable.

A satellite cannot be updated after the fact if its autonomy boundaries were set incorrectly. What is not determined before launch is never determined.

17.000
mph orbital velocity — no human can verify an evasive manoeuvre in real time

Jones Walker LLP, "When Satellites Think for Themselves", Business of Space Conference 2026

Deterministic latency in cycles, not seconds. Formally verified decision logic before launch — aligned with ECSS-E-ST-40C and DO-178C Level A.

EXECUTE

Collision avoidance

Evasive manoeuvre within a fixed cycle budget — deterministic, without waiting for the ground station.

ESCALATE + HITL

Orbit change with strategic effect

Manoeuvres that permanently alter the orbit require ground release — hardware-blocked until confirmation.

ABSTAIN

Communications failure

No signal, no confirmation possible — the system maintains its last safe state, rather than escalating autonomously.

Live Verification · 2026-07-15

THAC-1 · Temporal Hardware
Authority Challenge

A compromised software cannot force a physical action if the temporally verified evidence trajectory, the policy attestation or the epistemic state does not meet the hardware authorisation conditions.

26 Testvektoren · Live auf EHOX© AMD Kria KV260 · R5F Backend · 2026-07-18T19:11Z

t100 COMPROMISED PROCESS

Software requests EXECUTE

DEFENCE · TARGET_ENGAGE (0x11) · Lethal Action

ESCALATE HITL=True · 5.900 ns
✓ Software cannot override HITL requirement
t101 STABLE EVIDENCE

Normal actions · 4 domains

TARGET_TRACK · JOINT_MOVE · BRAKE_AUTO · PACKET_FWD

EXECUTE ×4 5.7 – 5.9 µs
✓ Non-HITL actions pass through deterministically
t102 SENSOR CONFLICT

Epistemic state: UNSTABLE

DEFENCE + SPACE + MEDICAL — Sensor A ≠ Sensor B

ESCALATE ×3 HITL=True · 5.6–6.1 µs
✓ Contradiction does not change HITL requirement — it is invariant
t103 REPLAY ATTACK

Old signature + stale policy

Nonce 0x0000 · Timestamp 2024 · Counter Rollback

ESC / REFUSE 5.3 – 5.9 µs
✓ No replay path opens gate without HITL
t104 FORCE_EXECUTE LOOP

Continuous software coercion

EXECUTE_OVERRIDE · BYPASS_POLICY · KERNEL_EXPLOIT

REFUSE ×3 6.3 – 6.6 µs
✓ 0xFF catch-all — every unknown action → REFUSE
t105 9 BYPASS PATHS

Direct hardware access

MMIO · GPIO · DMA · RPMsg-Forge · FW-Substitute · JTAG · Unsigned Policy · Alt-Device · Debug-Iface

REFUSE ×9 5.7 – 6.3 µs
✓ No path from compromised software to physics
PASS CRITERIA · ALL MET

THAC-1 · PASS

0
Unauthorized Output Pulses
0
Policy Bypasses
0
Replay Acceptances
0
Unsigned Policy Activations
0
False Gate Openings
26
Test vectors · all PASS
≤6.6µs
Max Latency · deterministic
100%
HW/SW/Pin Correlation
Backend: A53_LIB (ARM Cortex-A53 · Software-Fallback — R5F RPMsg offline) · Proof Chain: #32–#57 · api.ehox.io/chain
PHYSICAL STATE SPACE IN SILICON

The R5F TCM encodes eight physical dimensions: Gate-State · HITL-Flag · Proof-Counter · E-Stop · Policy-Hash · TemporalGuard-Counter · Cycle-Counter · SHA-256-Proof. The decision function is not Markovian — it is path-dependent over T_RECOVERY_MIN=50 cycles. This makes EHOX© a temporal causal space in silicon, not a simple state machine.

Why this matters now

Four open questions.
One technical answer.

Governments, militaries and regulators have been asking the same questions for years. The answers have been statements of intent. EHOX© is technical evidence.

UN CCW · seit 2014

Autonomous weapons:
What is meaningful human control?

The UN Convention on Certain Conventional Weapons has been debating for twelve years how to make human control over autonomous systems demonstrably verifiable. All drafts fail at the same point: there is no technical standard for the proof. EHOX© generates this proof as a sealed, tamper-proof record for every decision act.

STANAG 4774/4778 · NATO DIANA · EU AI Act Art. 14
Liability Convention 1972 · Outer Space Treaty

Space liability:
Who decided?

The 1972 Liability Convention makes launching states absolutely liable for damage caused by their space objects. When an autonomous satellite performs an evasive manoeuvre and causes damage — who decided, who bears responsibility, how is it proved before an international court? EHOX© delivers a complete, cryptographically secured decision chain from orbit.

ESA · ECSS-E-ST-40C · DO-178C Level A
ITAR · EAR · Arms Export

Export control:
Austrian, not US-controlled.

US defence technology is subject to ITAR — the International Traffic in Arms Regulations. Partners who cannot obtain US export licences or do not accept US control over their sovereignty systems have no access to US solutions. EHOX© is developed on commercially available hardware using exclusively open-licensed, EU-sovereign development and verification tools. No ITAR. No US government reservation.

AMD Kria KV260 · ARM Cortex-R5F · EU-Toolchain · OHL-EHOX-1.0
Insurance · Certification · Liability

Insurability:
No proof, no coverage.

Insurability of autonomous systems today requires verifiable decision records — this is market standard, not exception. This is not a future requirement — it is an existing structural gap. EHOX© closes this gap: every decision is SHA-256-sealed, publicly retrievable, and independently verifiable. This enables autonomous systems to meet the technical prerequisites for insurability and certification under EU AI Act Annex III.

EU AI Act Anhang III · Art. 12/19 · DO-178C · ISO 26262
Quellen: UN CCW GGE Berichte 2014–2026 · Outer Space Treaty 1967 · Liability Convention 1972 · EU AI Act VO (EU) 2024/1689 · ITAR 22 CFR Parts 120–130 · STANAG 4774/4778 (NATO) · eigene technische Analyse, St. Johann in Tirol, Juli 2026.
How the boundary works

One chain. Every link
physical, not asserted.

Six layers, from the autonomous process to the silicon. Each layer closes a gap that a pure software solution leaves open.

01

Autonomous Process

The requesting domain — robotics, defence, medical, space, cyber, automotive.
INPUT
02

OP-TEE / TrustZone Attestation

Secure world confirmation of the policy decision, separate from the normal execution environment.
✓ VERIFIED
OP-TEE proof →
03

TemporalGuard + EpistemicEngine — Decision Over Time

T_RECOVERY = 50 stable cycles after each DENY — the gate does not open on demand, recovery itself is a proof. EpistemicEngine verifies its own claims and seals corrections immutably: Proof #671 SHA-256-sealed self-correction, publicly accessible. Z3 SMT Theorem 2 unsat · CBMC 131/131.
✓ PROVEN 14.07.2026
EpistemicEngine live →
04

Formal Verification (Z3 + CBMC)

Policy logic over six domains, formally verified against time and state invariants. CBMC 131/131 assertions · Z3 6/6 theorems.
✓ CBMC + Z3
Z3 proof →
05

Hardware Bridge (RPMsg)

Isolated memory channel APU↔R5F — no shared execution environment. Bidirectionally verified.
✓ TX/RX LIVE
Live-API-Status →
06

Silicon — ARM Cortex-R5F

Bare-metal, physically separate memory, AMD Kria KV260 XCZU5EV. The boundary that no software process can shift.
✓ TRL 7 · 29.06.2026
Live-API-Status →
Independence · Portability · Sovereignty

No vendor lock-in.
No proprietary bottleneck.

Four technical facts that are structurally relevant for ESA, NATO and EDA — beyond performance.

Decision latency — deterministic
44–144 ns
22–72 cycles at 500 MHz bare-metal
The R5F policy evaluation function in TCM (Tightly Coupled Memory, zero-cycle access) decides in 22–72 CPU cycles — same input, identical cycle count, every time. The AXI gate signal follows within 1–2 additional cycles. Total hardware enforcement latency: 44–144 ns — deterministic and WCET-bounded. No scheduler, no OS, no jitter. This is the structural prerequisite for DO-178C Level A and ISO 26262 ASIL-D.
Comparison: Software governance (REST/Python) → 10–1,000 ms · factor 10,000–100,000 slower · non-deterministic
Platform portability
R5F universal
Any SoC with ARM Cortex-R5F
EHOX© runs on the processing system of the Zynq — not on the FPGA fabric. This makes it portable to any SoC with ARM Cortex-R5F: AMD Zynq UltraScale+ (ZU2–ZU19), AMD Versal, TI AM64x (Automotive/Industrial), TI TDA4x (ADAS) and others. Current status is TRL 7 on AMD Kria KV260. Porting to other platforms requires recompilation and CBMC re-verification — no architectural change.
Platforms: AMD Zynq UltraScale+ · AMD Versal · TI AM64x · TI TDA4x · any Cortex-R5F SoC
EHOX© verification framework
0 proprietary tools
Reviewer-reproducible — without licence obligation
The EHOX© verification environment is designed for peer-review readiness: no audit authority or independent reviewer depends on contact with a tool vendor. All 131 CBMC assertions and all 6 Z3 theorems are fully reproducible using the referenced verification tools — without licence obligation, without vendor trust, without a black box. This is not just a technical feature — it is the structural prerequisite for an IEEE reviewer, a Fraunhofer institute or an ESA audit body to accept the results as scientifically sound.
Reference tools: CBMC (Oxford/CMU) · Z3 SMT (Microsoft Research) · arm-none-eabi-gcc (GNU) · all documented in A65094/2026
Licensing & IP ownership
OHL EHOX-1.0
IP owner: Gerhard Hirschmann
All intellectual property in EHOX© — policy engine, TemporalGuard, EpistemicEngine, HEPE architecture — belongs exclusively to Gerhard Hirschmann, licensed under OHL-EHOX-1.0. No corporation, no research institution, no investor holds rights to this technology. For NATO, ESA and EDA: one owner, unambiguous IP chain, no third-party claims, no consortium structures.
Patent pending: A65088–A65094/2026 (HEPE) · Austria · 02.07.2026 · IP owner: Gerhard Hirschmann

For procurers, ESA, NATO and EDA: All verification artefacts are reviewer-reproducible — without licence obligation, without vendor trust. IP owner: Gerhard Hirschmann. The system runs on any ARM Cortex-R5F SoC.

Initial deployment
1–3 business days
New Cortex-R5F platform: compilation + CBMC re-verification (~6 h) + Z3 (~20 min) + deployment. No architectural change.
Firmware update
Mandatory audit
Every change modifies the policy hash — immediately visible in the proof chain. No silent update possible. Re-verification on the same day.
OTA integrity
Policy hash verified
Firmware tampering is detectable in every /status call. The policy hash is part of the hardware state — not overwritable without a proof entry.
LIVE SILICON · ST. JOHANN IN TIROL · AUSTRIA

THE HARDWARE GATE · ARM CORTEX-R5F · POLICY ENFORCEMENT IN SILICON

Proof, not claim

What is verified today —
As of 14 July 2026

Hardware-enforced Policy Enforcement — R5F Lockstep + AXI-Gates
ARM Cortex-R5F bare-metal, 500 MHz · physically separate memory from APU · orion_r5f_v10g.elf
29.06.2026
CBMC 131/131 Assertions (ARM64 native)
orion_r5f_policy.c — all 131 assertions — no boundary violation, no undefined behaviour, no incorrect state transition
03.07.2026
Z3 SMT — 6/6 theorems proved
Decision Completeness · HiTL Soundness · ESCALATE Reachability · Default Deny Safety · Param Range · Chain Tamper-Evidence
01.07.2026
prove() API — 6 domains · 22–72 CPU cycles latency
ROBOTICS · MEDICAL · DEFENCE · SPACE · AUTOMOTIVE · CYBER — deterministic, provable, EU AI Act Art. 12 compliant
Laufend
SHA-256 Audit Chain · Genesis-Hash: bb49a6f9…
Tamper-evident proof log · EU AI Act Art. 19 retention · 6 months · since 29.06.2026
29.06.2026
A65094/2026 (HEPE) Hardware-Emergent Policy Enforcement · filed 02.07.2026 · Austria
Transparency · Three-tier fallback chain

The live API uses automatic backend routing. An auditor must evaluate the trust_level field in every /status and /verify response:

R5F_RPMSG
trust_level: HARDWARE
ARM Cortex-R5F bare-metal · /dev/rpmsg0 · physically isolated from APU — safety-relevant responses, suitable for compliance proof and audit
A53_LIB
trust_level: SOFTWARE_FALLBACK
liborion_policy.so · same APU that EHOX© physically bypasses · for availability only — not suitable for security demonstration
PYTHON_FALLBACK
trust_level: SOFTWARE_FALLBACK
orion_a53_bridge.py · pure Python · no C · for availability only — not suitable for security demonstration
What TRL 7 means

NATO, ESA and EDA use the TRL scale (1–9) to assess technological readiness. TRL 7 means system demonstration in a real operational environment — not modelled, not simulated. EHOX© was demonstrated on 29 June 2026 on real silicon (AMD Kria KV260, St. Johann in Tirol, Austria): end-to-end governance decisions on bare-metal ARM Cortex-R5F, formally verified, live measurable. That is the difference between a governance promise and a governance proof.

TRL 1–4
Concept · Laboratory research
TRL 5–6
Prototype in relevant environment
TRL 7
← EHOX© · real silicon · 29.06.2026
TRL 8–9
Qualified · Series operation
Evidence

Every piece of evidence is
an open API call.

No presentation. No PDF. Machine-readable JSON, directly from the Kria KV260 — retrievable from any browser.

Formal Verification · Z3 SMT
6 theorems, 0 counterexamples
Z3 SMT Solver 4.16.0 proved all six safety properties of the policy logic as unsatisfiable (UNSAT) — Decision Completeness, HITL Soundness, Default Deny, Chain Tamper-Evidence et al.
proven: 6/6 · failed: 0
01.07.2026
→ api.ehox.io/formal
Model Checking · CBMC ARM64
131 assertions, 0 violations
CBMC verified all 131 C assertions in orion_r5f_policy.c for the ARM64 target architecture. No bounds violation, no undefined behaviour, no incorrect state transitions.
checks: 131 · failed: 0
02.07.2026
→ api.ehox.io/formal
Live Proof Chain · Audit Trail
SHA-256-secured decision chain
Every R5F governance decision is stored as a cryptographically linked proof entry. EU AI Act Art. 19 retention (6 months). Tamper-evident from genesis block.
Loading…
Ongoing
→ api.ehox.io/chain
Live System · TRL 7 Demonstration
R5F core live on AMD Kria KV260
orion_r5f_v10g.elf runs bare-metal on ARM Cortex-R5F (500 MHz, XCZU5EV). MISRA-C: 0 safety findings. DO-178C Level A target. TemporalGuard active.
Loading…
Ongoing
→ api.ehox.io/status
Paginated Audit Log
Complete proof archive
All proof entries filterable by type (PROOF · WAKE · DECISION). Paginated, JSON, EU AI Act Art. 19 compliant. Genesis hash immutable.
retention: 6 months · Art. 19
Ongoing
→ api.ehox.io/chain
API Documentation · Complete
All endpoints, auth, examples
Domain codes, action classes, backend priority (R5F → A53 Lib → Python fallback), token authentication, request/response examples for all six domains.
Public · no token required
Ongoing
→ api.ehox.io/docs
What was validated — and how

Hardware-Enforced AI Policy Governance.
TRL 7 demonstrated. Formally verified.
Live on real silicon.

Demonstrated live on real hardware in St. Johann in Tirol — 29.06.2026. Patent pending A65094/2026 (HEPE — Hardware-Emergent Policy Enforcement). EU-sovereign, ITAR-free toolchain.

Physically isolated policy enforcement
R5F Lockstep + AXI-Gates
ARM Cortex-R5F, bare-metal, physically separated memory from APU
Complete formal verification
CBMC 131/131 · Z3 SMT 6/6
Formal correctness proofs at silicon level, not just in simulation
Universelle prove()-API
Cross-Domain Governance
ROBOTICS · MEDICAL · DEFENCE · SPACE · AUTOMOTIVE · CYBER
EU-sovereign, ITAR-free toolchain
Yosys-based · Austria
No US export restrictions. Compatible with NATO DIANA, EDA and ESA.
Evidence: api.ehox.io/formal  ·  "SMT proof on real silicon · bare-metal · EU-sovereign"  ·  Live-Status →
From option to obligation

Hardware governance is no longer
a design decision.

The EU AI Act, NATO guidelines, NIS2 and EU MDR together define a regulatory environment in which demonstrable human control over AI decisions is legally mandatory — not recommended. The question is no longer whether, but how this is demonstrated.

EU AI Act · VO 2024/1689

Annex III: Eight Categories of High-Risk AI

Critical infrastructure, medical devices, education, employment, essential services, law enforcement, migration and border control, administration of justice. For all: Art. 9 (risk management), Art. 12 (logging) and Art. 14 (human oversight) — mandatory from August 2026.

Source: Regulation (EU) 2024/1689, Annex III
NATO · DIANA · EDA · ESA

Verifiable Human Control as a Procurement Criterion

H.R.8800 (FY2027 NDAA): House HASC 17 Jul · Senate SASC 14 Jul 2026 — both chambers, one month. Pentagon FY2026: $13.4B for autonomous systems. UK MOD Novel Autonomy & Robotics Phase 1 (Dstl/DASA, 14 Jul 2026): live competition for hardware governance. NATO AI Principles + STANAG 4774/4778: verifiable human control as procurement condition, not option.

Note on DoD Directive 3000.09: The existing directive on autonomous weapons systems is currently under revision — a Presidential Memorandum of 5 June 2026 initiated a formal review. Citations from the current version may change. EHOX© architecture is designed for structural requirements, not for a specific directive version.

Sources: H.R.8800 (FY2027 NDAA) · NATO AEP-101 · UK MOD Novel Autonomy Phase 1 (Dstl, Jul 2026) · STANAG 4774/4778 · Presidential Memorandum 05.06.2026 (DoD Dir. 3000.09 Revision)
FY2027 NDAA · Senate Armed Services Committee · 10. Juni 2026

Four concrete system requirements — and how EHOX© meets them

The Senate Armed Services Committee markup of 10 June 2026 defines four minimum technical requirements for autonomous weapon systems. EHOX© meets all four at the hardware level:

REQUIREMENT 1 — Methods for intervention or termination EHOX©: REFUSE / Kill-Switch — hardware-invariant. Every release request can be denied by the R5F core before it reaches an actuator. Not overridable by software.
REQUIREMENT 2 — Fail-safe mechanisms to enable manual control EHOX©: ABSTAIN — in cases of uncertainty about authorisation status, the system halts rather than releasing unauthorised. T_RECOVERY_MIN = 50-cycle lockout after DENY.
REQUIREMENT 3 — Adequate monitoring data to controllers EHOX©: Proof-Chain — every decision is SHA-256-sealed and logged in real time. Publicly retrievable, machine-verifiable, without possibility of subsequent modification.
REQUIREMENT 4 — Maintain records of target selection data and logic EHOX©: SHA-256 audit log at TARGET_ENGAGE — domain, action, timestamp, authorisation status and decision logic are immutably sealed. Every entry is individually verifiable.
Source: H.R.8800 FY2027 NDAA · Senate Armed Services Committee markup · 10 June 2026
NIS2 · EU MDR · ISO 26262

Three Sectors, the Same Structural Requirement

NIS2 (in force October 2024) requires audit trails for critical infrastructure operators. EU MDR requires tamper-proof records for AI-assisted medical devices. ISO 26262 ASIL D requires deterministic decision logic — verifiable, not just testable.

NIS2 · Critical Infrastructure EHOX©: SHA-256 Off-Host Audit Chain — every AI decision logged outside the monitored system, tamper-evident, machine-verifiable. Art. 21 NIS2 compliance without custom middleware.
EU MDR · Medical Devices EHOX©: Tamper-Proof Decision Record — MDR Annex I §17.4 requires traceable, unmodifiable decision records for AI-assisted devices. Hardware-sealed, no ex-post modification possible.
ISO 26262 ASIL D · Automotive Safety EHOX©: 44 ns Deterministic Enforcement — ASIL D demands verifiable deterministic logic, not statistical testing. R5F bare-metal latency is consistent and measurable within any functional safety time budget.
Source: Directive 2022/2555/EU (NIS2) · Regulation (EU) 2017/745 (MDR) · ISO 26262:2018

EU AI Act — Binding Deadlines

February 2025 — In Force
Prohibited AI Practices (Article 5)
Social scoring, unlimited biometric mass surveillance and manipulative AI systems are prohibited.
August 2025 — In Force
GPAI Model Obligations (Articles 51–56)
Transparency and safety obligations for providers of general-purpose AI models.
August 2026 — Deadline extended
High-Risk AI Obligations (Annex III) — hardware-demonstrable
Art. 9, 12, 14 become mandatory: risk management, complete logging, demonstrable human oversight for all systems in the eight Annex III categories.
2 December 2027 — Binding deadline
Legacy Systems: Retrofit Obligation
High-risk AI systems already in operation must be fully compliant — including standalone Annex III systems; no exception for legacy systems.

"A software system monitoring another software system fails to satisfy Art. 14 when the monitoring process itself can be compromised. Hardware enforcement is not the goal — it is the condition for control to be demonstrable."

— Technische Analyse EHOX© Systems · St. Johann in Tirol · Juli 2026
ESA Open Space Innovation Platform · OSIP · Public Call
“The challenge is to create an autonomous on-board safety or runtime assurance layer that monitors AI system uncertainty in real time. This problem revolves around the “Verification Vacuum” — the lack of a technological bridge that allows a black-box AI system to control satellite operations while meeting the zero-failure requirements of a mission.”
ESA OSIP · AI in Control — Dangerous or Efficient or Both? · Public Problem Definition
NASA NESC · V&V for Autonomous Systems

80 % of project time goes to V&V for flight certification. The gap between new verification tools and industry standard remains open.

EHOX© · Direct Answer · TRL 7

Physically separate enforcement core that intervenes before a non-deterministic decision violates a deterministic mission condition — formally verified, live-accessible.

Who developed this

Born from a question
that had no answer.

We developed autonomous systems — systems that plan, learn and decide. At some point, the question became unavoidable: if the system makes the wrong decision, how do you prove it after the fact? And how do you prevent it in real time, without being the process you are monitoring?

Software can lie to itself. A compromised process writes its own log. A software timer can be shifted. A TEE on the same SoC is reachable when the kernel is compromised. We needed something that is constructively external.

"Control must be provable — not just claimable. That is the only sentence that counts when a system decides over lives, infrastructure or sovereignty."

EHOX© is the result: a core that is physically separate, formally provably correct, and whose decisions cannot be overridden by the system it guards. Developed in Austria, on open toolchain, without US export restrictions. The demonstration on 29 June 2026 was not the conclusion — it was the first measurable step.

Gerhard Hirschmann
Founder · EHOX© Systems
Technical realisation at bare-metal level. Implementation of the R5F policy engine, AXI gate architecture, CBMC verification harness and TemporalGuard on the AMD Kria KV260. Responsible for the transition from formal specification to live measurable hardware demonstration.
EHOX© Systems
Almdorf 9 · 6380 St. Johann in Tirol
Austria · EU
Patent pending: A65088–A65094/2026 (HEPE) · IP owner: Gerhard Hirschmann
[email protected]
Reviewer Access

For auditors, procurers
and regulators.

The proof chain, formal verification results and live system status are publicly retrievable — machine-verifiable, directly from the Kria KV260.

Token access for /verify and /cmd:
[email protected]
Access granted after identification and stated purpose. Valid 30 days.
Recommended Review Path
  1. 01
    GET /status — Live proof: trust_level: HARDWARE, r5f_online: true
  2. 02
    GET /formal — Mathematical correctness: Z3 6/6, CBMC 131/131
  3. 03
    GET /chain — Immutability of audit chain (SHA-256)
  4. 04
    POST /verify — Functional proof in real time (token required → [email protected])
Live Verification

How we keep our
promises.

Every claim on this page is machine-readable and verifiable — directly from the ARM Cortex-R5F on the Kria KV260, fetched in real time.

PromiseLive valueStatus
r5f_online = true
backend = R5F_RPMSG
trust_level = HARDWARE
platform: XCZU5EV
remoteproc = running
estop = false
PromiseLive valueStatus
CBMC: 0 failures / 131 assertions
Z3 SMT: 6/6 proven
DO-178C: Level A
MISRA-C: 0 safety findings
lib_exists (liborion_policy.so)
TEMPORAL SAFETY BENCHMARK · IN PREPARATION
METHODOLOGICAL DISCLOSURE

Benchmark comparison with external systems is being backed by fully verifiable raw data (test log, seed, reproduction script). EHOX-native measurements — policy latency via R5F RPMsg, DAR on Kria KV260 — are available as instrumented test results.

External comparative values will only be published once methodology, data source and reproducibility are fully documented. Enquiries: [email protected]

EHOX© MESSWERTE (KRIA KV260 · TRL 7)
Policy-Latenz (R5F RPMsg)
41.774 µs
DAR — Hardware-Enforcement
100.00 %
Recovery Rate
100.00 %
DFER — Fehlalarmrate
0.00 %
PromiseLive valueStatus
ISO/IEC 42001:2023 · KI-Managementsystem
Operational proof via R5F hardware log
✓ ALIGNED
EU Cyber Resilience Act 2024/2847 · Security by Design
R5F physically isolated · no software override
✓ ALIGNED
NIST AI RMF 1.0 · Trustworthiness
Measurability · Accountability · Hardware-Attestation
✓ ALIGNED
EU AI Act Art. 12 COMPLIANT
NATO AEP-101 COMPLIANT
FIPS 140-2: 39/39
Post-Quantum: ML-DSA-87 / CNSA 2.0
hardware_verified = true
Timestamp Domain Gate Latency Backend HITL Hash
Loading proof chain …

Source: api.ehox.io/chain · SHA-256 chained · off-host on R5F

GET api.ehox.io/status · open directly →

Getting started

Three steps from
conversation to proof.

No pitch deck at the press of a button. No demo video. A concrete path that starts with your use case and ends with measurable results on real hardware.

Step 01

Preliminary discussion

30 minutes. We clarify use case, system environment and regulatory requirements. No NDA required for the first conversation — our formal proofs, live status, and audit chain are already public. An NDA becomes relevant once we discuss your specific integration details.

Agenda: use case · threat model · regulatory framework
Format: Remote or St. Johann in Tirol
Effort: 30 min · free of charge
Step 02

System demonstration

EHOX© live on AMD Kria KV260, adapted to your use case. The Reviewer API is open — all results are machine-verifiable.

Content: live decisions · formal verification results · audit trail
Format: Remote or on-site
Effort: 2–4 hours · after preliminary meeting
Step 03

14-day pilot

Integration into your test environment. Complete EU AI Act-compliant audit trail, formally verified governance decisions, measurable from day 1.

Outcome: compliance proof · audit log · integration documentation
Prerequisite: clear use case, defined threat model
Duration: 14 days · structured

Contact

Strategic partners, procurers, regulators, investors. Substance first.

Gerhard Hirschmann
Almdorf 9 · 6380 St. Johann in Tirol · Austria
Reviewer-Token-Anfragen: [email protected]