01
Software controls / implemented
Exact requests and accountable stops
Single-use grants, replay rejection, bounded synthetic tools, in-flight accounting and signed records. Tests exercise races, changed arguments and denied paths.
Syntony / Hardware
In development
METRONOME
Authority outside
the workload.
A dedicated control appliance for agent and tool evaluation benches. ME-01 is designed to place request authorization and destination credentials outside the AI host, with explicit stops and inspectable records.
For AI security and evaluation teams testing agents against controlled services.
01 / Agent hostRequest a tool action
02 / ME-01 brokerAuthorize the exact call
03 / Test serviceExecute through a connector
04 / EvidenceInspect the result
01 / Why a separate device
The host can fail.
Authority stays separate.
Consider an agent that gains administrator access on its evaluation host. It can alter host-local controls and read credentials stored there. ME-01’s target architecture keeps the permitted service path under a separate administrator and operating system.
Design scenario / host compromise
- 01
The agent changes the request.
A previously approved lookup becomes a configuration change, or the agent attempts a direct connection to the target.
- 02
The appliance owns the service path.
The proposed broker checks the full request against a single-use grant. Target credentials remain on ME-01; the agent has no direct target route.
- 03
The changed action is rejected.
Qualifying this outcome requires a real connector, isolated management, no alternate path and target-side observations. Those appliance tests are the next milestone.
Where hardware adds a boundary
Choose a separate appliance when the evaluated host must not own its authorization policy, destination credentials or management interface.
Where software may be enough
A software broker on trusted infrastructure can enforce the same request policy. Physical separation is useful when a separate host and controlled cabling are part of the threat model.
The baseline trusts ME-01’s own kernel, firmware and administrator. It does not establish containment after compromise of the controller itself.
02 / The device
One service path.
Separate authority.
The first ME-01 profile is an application broker on a compact, fanless appliance. Agent requests terminate at the broker; approved connectors make separate calls to the test service. IPv4 and IPv6 forwarding remain disabled.
TRUSTED OPERATOR CONSOLESeparate management interface↓
Evaluated host
No direct target route
Agent
Requests a bounded tool call
No target credentialsNo direct target route
Separate appliance
IP forwarding disabled
ME-01
Policy + grant verification
Application broker + connectors
IP forwarding disabled
Controlled environment
Independent observation
Test service
Receives connector calls
Scoped destination and APIIndependent observation
Authenticated request ingressAllowlisted application callsNo transparent routing or bridging
The working prototype mediates fixed in-memory services. Network ingress, destination credential custody and real service connectors are required appliance integrations; private supervisor IPC is not an agent-facing interface.
Control Node
ME-01
Fanless. Four wired interfaces.
Dedicated management path.
Reference envelope144 × 143 × 55 mm
Reference platform
Protectli VP2430e. Optional TPM-02 configuration subject to OEM confirmation; appliance integration is in development.
Operator authorization
Two distinct enrolled operators sign an exact request using separate PIV keys. The adapter is implemented; physical-token ceremony tests are next.
Device trust
The TPM is intended for device-key custody and boot measurements checked against an approved policy. This integration is separate from operator authorization and remains to be built.
Network architecture
Separate management, agent and target interfaces. The fourth port is reserved and disabled by default. Physical roles are verified during commissioning.
Planned logical port roles
01Management
02Agent host
03Test environment
04Reserved / disabled
03 / Control mechanisms
Exact permission.
Explicit stop.
The controller binds approval to a complete request and consumes that grant once. STOP closes new admissions and reports any work already admitted; recovery requires fresh authorization.
Software foundation / appliance integration next
The workload does not own authority.
The software prototype separates the controller and synthetic broker from the workload process. ME-01’s appliance profile moves that service boundary to a separately managed host, with target credentials held by its connectors.
Host independence requires the commissioned topology and real connector path. The prototype alone demonstrates process separation.
What the stop means
Admission closed is a precise result.
Already admitted work is tracked separately. A returned acknowledgement does not undo completed effects or cancel a job a remote service has accepted.
Separate qualification work package
An external link interlock.
A fail-disconnected interlock beyond ME-01’s target interface is under consideration for independent link interruption. No device is selected or qualified. It would interrupt that link; remote jobs and other paths remain separate concerns.
04 / Existing software evidence
A recorded fixture.
A verifiable record.
This 72-second narrative presents an archived Linux fixture on a shared kernel. It covers software denials and resource checks, preceding ME-01’s dual-operator controller work. It is not an appliance, current authorization or egress-cutoff test.
Establish the environment.
The recorded fixture will load after integrity verification.
Record verification pending
FIXTURE / SELECTED OBSERVATIONS
Verifying the recorded fixture…
Software-managed signer · Shared host kernel
00:00 / 01:12
Signed public derivative
Loading recorded data…
Playback unlocks after verification of the signed public record. The chapters are explanatory narration, not a measured execution timeline. Historical AEGIS identifiers remain unchanged.
Verification pending.
Download signed record ↓05 / Development path
Build the boundary.
Measure its behavior.
The controller and bounded broker provide a working software foundation. The next release must connect that mechanism to a real test service and qualify the physical deployment.
Software
02
First appliance integration / next
A bounded path to a real test service
Authenticated, size-bounded request ingress; a fixed connector with credentials off the agent host; forwarding disabled; isolated management. Measure request rejection and stop behavior from the target side, including already admitted calls.
03
Trust and recovery / qualification
Operator keys and device identity
Test physical PIV approvals, enrollment, revocation and recovery. Integrate TPM device keys and boot measurements with explicit verification policy. Operator authentication and platform attestation are separate results.
04
Independent link interruption / separate work package
Qualify an external interlock
Select and test a fail-disconnected device against a defined controller-failure model. Measure established traffic, power loss and recovery before making a physical-cutoff claim.
Technical references Design inputs, not certification or test results
- Protectli VP2430eSelected reference platform and manufacturer specifications.
- Microsoft: Trusted Platform Module overviewKey protection and platform measurements are distinct from traffic enforcement.
- Yubico: PIV attestationDevice-origin key evidence and policy attributes; not proof of a person’s informed intent.
- NIST SP 800-207Policy decisions and enforcement at resource boundaries.
- Linux kernel: watchdog APIA watchdog reset is not an independently qualified network disconnect.
Technical review
Bring a boundary.
Examine the design.
Discuss an agent, a test service and the action you need to control. Review the software prototype or explore the ME-01 hardware design with our team.
Request a pilot