No AI, no insider can sign alone.

Where Closed Networks & Self-Hosted breaks today

AI acts with real permissions

AI agents approve, deploy and move money faster than people, with the same permissions people have. When an agent is fooled or an account is taken over, the system records the action as normal business. Passwords, OTP and software signatures fall to a single breach.

2-of-3 — Two of three chips from different manufacturers must agree. One person, one account or one agent is never enough

Insiders can rewrite the record

DBAs, system administrators and the vendors who built the equipment can delete logs, extract keys and rewrite history. Even an HSM is a vault that someone administers. Insider tampering surfaces only after the damage is done.

0 stored keys — Nothing to extract. Each key is regenerated from the chip at every power-up

The more isolated a site must be, the less it can lean on the cloud

Core banking, defense and government networks, power plants and chip fabs must be cut off from the outside. Yet most identity and audit services assume an internet connection, which leaves closed networks with unsigned logs and shared passwords.

0 outbound — Roost signs inside the closed network with no outbound connection; records leave only the way you decide

Seven paths an attacker can take, and how Roost answers each

To take meaningful data or obtain a signature, an attacker has to go through one of these.

Tricking an approver

Attack: The attacker fools an approver with phishing, deepfake voice or video, or a fake invoice, so the approver signs off in person.

How Roost answers: An Axowl approval needs a key bound to the TPM of a registered device plus that person's biometric check. Biometric data never leaves the device. A stolen password, another device or a bot cannot produce an approval at all. Access from outside the countries the organization allows is blocked or held for admin approval, depending on policy, and travel is allowed only through a time-limited exception. For the case where the real approver is deceived, each approval is bound to what it actually does, such as the payee and the amount, so a request that differs from what was on screen is not signed. Depending on the amount and the target, Roost signs only after a second approver and the watcher's anomaly checks (a new payee, an unusual amount or time).

Taking the database and backups

Attack: The attacker copies the whole database or its backups, or uses a privileged account to pull data out in bulk.

How Roost answers: The database key is generated at random in the customer's environment. Axowl does not know it and has no way to learn it. Roost wraps that key with envelope encryption under a key derived from the chip's PUF. The key that opens the outer envelope is never stored anywhere; the chips derive it only when the quorum agrees. Roost also checks the key's signed fingerprint every time and rejects a swapped key. Copying disks, backups or snapshots gets the attacker nothing they can decrypt, and a key slipped in by an attacker will not open anything. Bulk queries and exports need approval and a Roost signature, and the watcher stops unusual bulk reads as they happen.

Quietly changing the approval rules

Attack: An insider with admin rights, or a hijacked admin account, quietly loosens the approval rules and then pushes approvals through under the new rules.

How Roost answers: Changing approval rules or permissions itself needs quorum approval and a Roost signature. No single admin can change the rules, and every change stays in a chain that cannot be edited, so who changed what, and when, cannot be hidden.

Note: Fraud in which every approver colludes is not hacking. It belongs to internal controls and the law. Even then, Roost's approval records cannot be erased and remain as evidence for audits and courts.

Planting something in the factory or in transit

Attack: Before shipping or in transit, the attacker plants malicious firmware or a modified circuit, or swaps a chip. The attacker may also go after the manufacturer's signing key or build process. It is not an everyday attack, but in defense, where nation-state attackers are assumed, it is a path that has to be planned for.

How Roost answers: The chips boot only circuits with a valid signature, so a planted circuit does not load. Keys are not created at the factory. They come from each chip's PUF the first time the box is powered on at the customer's site, so there is no key to steal before delivery. On arrival, each chip proves which circuit it is running with a measured value, and the customer checks it against published reference values before enrolling the box with their own quorum. The watcher circuit runs on battery and logs any intrusion in transit, which is caught at enrollment. The three chips come from different manufacturers, so even if one manufacturer or one supply route is compromised, that is a single vote. Axowl's own circuit-signing key is used only through a Roost quorum, and anyone can rebuild the published signing circuit and compare the result.

Taking the box to a lab

Attack: An attacker who gets hold of the unit analyzes the chips' power draw and emissions with lab equipment (side channels), induces faults with voltage or lasers (fault injection), or drills precisely into the box. This is not remote hacking. It takes physical possession, a lot of time and expensive equipment, which puts it within reach of nation-state attackers only.

How Roost answers: Roost is built to the level FIPS 140-3 Security Level 4 calls for. The inner enclosure is sealed with a sensing mesh on all six sides. Cutting, drilling or opening it erases the value that recreates the keys, even with the power off. If temperature or voltage leaves its safe range, or a voltage glitch or clock fault is detected, Roost treats it as an attack, stops signing and erases. This is where our patent shines. Keys are never stored; the chips recreate them at every power-up. A unit taken away while powered off holds no key to analyze. No Keys, Nothing to lose.

Software bugs and quantum computers

Attack: The attacker goes after software flaws: using a bug in the server or firmware to skip a permission check, swap the content of an approval, or replay an old signature. Or they collect signatures today and try to forge them once quantum computers arrive.

How Roost answers: One bug is not enough to get a signature. Two chips from different manufacturers each have to check the content before a signature is made, so if the software on one side is compromised, the others still stand in the way. What was approved (payee, amount) is bound into the signature, so any change along the way breaks it. The unit boots only signed firmware. For quantum computers, Roost is designed to move to post-quantum signatures (such as NIST FIPS 204 ML-DSA) through a firmware update, without changing chips. During the move, each signature carries both the current and the post-quantum signature.

Stopping it instead of stealing

Attack: If the attacker cannot take the data, they try to make it unusable: provoking an erase by tampering with the box or the power, destroying or stealing the unit through fire, flooding or theft, or breaking voter chips so no signature can be made.

How Roost answers: Roost is sold as a pair of two units installed at different sites. The two are enrolled together from the start and each holds its own envelope of the database key. If one is erased by an attack or a failure, the other unwraps the key and operations continue. Data is lost only if both disappear at the same time, and the key is never stored anywhere along the way. An erased unit is replaced with a new one and enrolled again with the remaining unit.

Three patents, deployed against this industry's threat model

Each of Axowl's three filed patents maps to a specific structural failure mode in Closed Networks & Self-Hosted. Together they form a single, end-to-end defense.

Hierarchical Distributed Trust Fabric — Defense-grade architecture: three chips, three manufacturers, two must agree

Roost's three voting chips come from AMD, Lattice and Microchip. Flaws break out by manufacturer, so even if one chip, or one manufacturer's whole line, is compromised, that is a single vote. Keys are regenerated from a PUF at every power-up and stored nowhere. No administrator and no vendor ever holds a key that opens the whole box.

Transition-Sealed Integrity System — Every decision becomes a chain no one can quietly rewrite

Each signature carries the previous record's hash and a hardware counter that only counts up. A replayed command fails because its counter has passed, and editing one record breaks every record after it. An insider's edit has nowhere to hide.

Pre-grant LLM Conflict Verification — Dangerous AI actions stop before they are signed

Roost enforces Axowl's permission gate at the hardware boundary. An AI agent's unapproved transfer, a database change without human sign-off, or a drone command into a forbidden zone is not logged as a violation after the fact — it is never signed, so it never runs.

Deployment that fits the threat model

Roost is the on-premises form of the Iron tier: the same PUF root, HMAC chain and quorum that Axowl runs in colocation, placed inside banks, government and industrial sites that cannot depend on any outside service. Nothing leaves the network unless you carry it out.

Recommended tier: T3 · Iron · On-prem

Deployment path: Roost Box → Roost Rack (1U/2U) → Roost Card (PCIe)

Operational detail: Box — palm-sized aluminium unit, Ethernet and power, sits on a desk or a shelf. First deployments and edge sites.
Rack — the same board set in a 1U or 2U chassis with tamper seals and lid-open detection for server rooms.
Card — PCIe form for fleets, inside the customer's own servers.
All three run identical firmware and speak the same protocol; a self-hosted Axowl instance points at the box the way it points at Axowl's colocation quorum.

Three concrete deployments

Core banking and securities

Roost signs privileged database changes, batch releases and admin logins on the core banking network. The record is one even a root DBA cannot quietly change, and regulators receive a chain that proves itself instead of a spreadsheet.

Defense and government

No cloud, no vendor remote access, no stored key to seize. The signing circuit is open for the agency to verify, and only a circuit with a valid signature is loaded onto the chip.

Companies adopting AI agents

The more agents approve, deploy and pay on your behalf, the more their authority must be tied to human approval. Roost keeps an agent's risky request from running without a quorum signature, and records who approved what.

Organizations where audit and compliance matter

Decisions that end up disputed — financial close, permission changes, contract approvals — are signed in hardware. A record that shows any edit becomes the starting point for internal audit and litigation.

Power, water, semiconductor and other closed sites

PLC changes, recipe edits and maintenance overrides are signed inside the closed network. Records leave through a data diode or on a set schedule for IEC 62443 and 21 CFR Part 11 audits.

Hospitals and medical devices

Access to patient data and changes to device settings carry a hardware signature. The logging HIPAA and IEC 81001-5-1 require is produced without any internet link.

Robot and drone operations

A Roost at the ground station or on the factory floor checks every takeoff, move and task command against policy before signing it. Forged or replayed commands never run.

Data centers and cloud providers

For services whose customers must be able to verify that "even the operator cannot touch it", Roost provides a structure in which no insider at the operator can sign alone.

Conventional HSMs and Roost

For more than 40 years, HSMs have been built on the same idea: keep the key safe in a vault. Today, AI agents and hijacked accounts act with real permissions. However strong the vault, if it signs whatever arrives through the normal path, money and data still walk out. Roost protects the signature, not just the key.

Standards & regulatory frameworks aligned

• FIPS 140-3 L3-aligned
• IEC 62443-3-3 SL3
• EU Machinery Regulation 2023/1230 (Jan 2027)
• EU Cyber Resilience Act (2027)
• ISO 10218:2025
• NIST SP 800-82
• EU AI Act Article 12 (logging)