[ Capability ]
Evidence register →
Runtime Authority Governance for Autonomous and AI-Enabled Systems
AUTHREX develops methods and software for controlling what an autonomous system or AI agent is permitted to do as the evidence supporting its actions changes.
Our mission is to help U.S. Government teams translate operational authority limits into explicit software controls, testable behavior and reviewable evidence.
The research problem: a system's permission to act may depend on evidence that becomes stale, inconsistent, unavailable or insufficient for the next action. AUTHREX investigates how that permission should narrow, what conditions must be met before it can expand again, and how those decisions can be tested and reviewed.
The intended benefits are objectives for a sponsor to evaluate, not properties to assume: preserving appropriate human oversight; constraining unsupported actions; supporting mission continuity within authorized limits; and improving the evidence available to technical reviewers. AUTHREX does not determine government policy, does not guarantee mission safety, does not prevent every autonomous failure, and does not make a system compliant with any requirement.
[ In One Minute ]
What a Reviewer Needs First
Six questions, each answered in one line from the records on this site, with the section that carries the detail.
| Question | Answer | Detail |
|---|---|---|
| What AUTHREX develops | Software controls and specifications that narrow what an autonomous system or AI agent is permitted to do when the evidence behind its actions degrades, and that govern the conditions for restoring that permission. | Five capability areas |
| Which government problems the work addresses | Runtime assurance and runtime monitoring of autonomous and AI-enabled systems; interlocks and guardrails for machine-learning functions; bounded permissions, tool access and action records for AI agents; containment and staged restoration when an AI agent acts outside its intended scope; verifiable assurance evidence for software in operation. | Relevance to U.S. Government priorities |
| What can be evaluated today | Governance Kernel v1.0-QA10 (source by request), AUTHREX-SAFING v1.5.0 (released console and package), AUTHREX-ABORT Build 0.6 and AUTHREX-QUARANTINE 2.2.5 (browser consoles), 21 TLA+ modules categorized by model faithfulness; AUTHREX-DEFEND 0.1.6 separately, on request to U.S. Government organizations. | Available for technical evaluation |
| Why the founder is qualified to undertake the work | A Bachelor of Science in Computer Science (University of South Florida, 2020), a Master of Business Administration (Lynn University, 2026) and a Master of Professional Studies in Applied Intelligence in progress (Georgetown University); the artifacts on this site; three peer-reviewed journal articles; two Air Force Research Laboratory white-paper evaluations on record. | Founder and technical background |
| What a bounded engagement could deliver | An authority-state specification, an enforcement-boundary description, scenarios and versioned configurations, test traces with replay instructions, findings and counterexamples, and an assurance argument with explicit assumptions and unresolved claims; scope agreed with the sponsor first. | An actionable engagement |
| Where the evidence and the remaining limitations can be inspected | The claim and evidence register, the formal coverage page, each artifact's own page and the engineering boundary; every line on this site carries its principal limit beside it. | Claim and evidence register |
[ Five Capability Areas ]
Product and research taxonomy →
What AUTHREX Does, Area by Area
Each area names the work AUTHREX undertakes, the artifact that supports it, the scope demonstrated today and a deliverable a scoped evaluation could produce. Demonstrated means shown in an existing artifact on synthetic data in its stated environment; proposed means work that still needs development, sponsor input or integration.
| Area | Work AUTHREX undertakes | Supporting artifact | Demonstrated scope today | Possible evaluation deliverable (proposed) |
|---|---|---|---|---|
| A. Authority policy and state modeling | Defining permitted actions, evidence prerequisites, authority states, degradation conditions, human approval points and restoration rules for a workflow. | The HMAA tier model (A3 full autonomy to A0 revoked) and its bounded TLA+ check; the draft authority interface and gate monitor on the Engineering Basis page (sections 7b and 8); each release's own tier vocabulary (section 2). | Specifications and model-relative checks exist; tiers and restoration guards are documented per artifact and not normalized to one scheme. No sponsor workflow has been modeled. | A versioned authority-state specification and transition table for one sponsor-defined workflow. |
| B. Runtime permission controls | Software that evaluates whether a proposed action is permitted under the applicable policy and evidence conditions, at a stated enforcement boundary. | Governance Kernel v1.0-QA10: agent tool calls pass through an MCP proxy and are gated by authority tier before any tool executes, with a human approval queue under RBAC and signed policy loading. | Implemented software, author-tested on loopback with synthetic data (container suite: 83 passed, 1 skipped). The enforcement boundary is the proxy: the check governs only calls routed through it and depends on host integrity, protected keys and downstream enforcement; a tool reached without the proxy is not governed. Bypass tests have not been run (integration boundary). | A scoped software integration prototype with documented interfaces, assumptions and bypass tests. |
| C. Controlled degradation and restoration | Narrowing, holding, revoking and restoring permissions under stated conditions, with the behavior of each release kept distinct. | AUTHREX-SAFING v1.5.0: safe-state entry on a demanded fault, hold and deepen while it persists, exit only under an authorized re-arm with human approval. AUTHREX-QUARANTINE 2.2.5: a case opens at T0, return passes through read-only probation to a new epoch-scoped grant after custodian approvals. AUTHREX-ABORT Build 0.6: a lapsed irreversible action latches down for the rest of the run. HMAA hysteresis and stepwise upgrade: specification only. | Each behavior is demonstrated in its own synthetic console; no release implements every restoration guard, and the HMAA restoration delay is specified, not implemented. Recovery is simulated, never physical. | Degradation and restoration scenarios with explicit approval, expiry and recovery conditions for one workflow. |
| D. Assurance testing and formal analysis | Scenario testing, adversarial cases, selected formal models, release checks and reproducible test records. | SAFING verification (1,061 checks; 2,488,320 enumerated executions; 50 of 50 mandatory mutants killed); ABORT (two frozen TLA+ modules checked across 21 and 35 configurations; 105 tests; 34 release checks); QUARANTINE (74 engine and 44 console tests; 11 of 11 non-equivalent mutants killed; two external review rounds); the Formal Coverage taxonomy of 21 TLA+ modules. | A formal result applies to its stated model, properties, assumptions and explored bounds. Two modules are faithful to the code they model, and one of them located an open defect in production source (the MAIVA quorum check at n = 1); surrogate models are findings about mechanism classes, not about implemented code. All testing is author-run and not independently reproduced. | A test plan, scenario set, versioned configuration, results, counterexamples and the unresolved findings. |
| E. Decision records and review evidence | Logging, policy identification, integrity checks, replay and reviewer exports, stated per artifact. | Governance Kernel: signed policy loading, a checkpointed hash-chain ledger, tamper detection that distinguishes clean ledgers, forged records and tail truncation, and reviewer packet export. AUTHREX-SAFING: a SHA-256 hash-chained ledger replayed from its seed. Fourteen consoles carry a hash-chained decision ledger and deterministic replay (Simulation Laboratory). | A hash chain shows that a record is consistent with itself; a signature binds a record's content to a signing key; an authentic checkpoint, protected separately from the record, helps detect changes to the records committed before it; replay checks that the record is consistent with the recorded inputs and configuration. These mechanisms do not prove that the record is complete or that a recorded action was actually executed. External anchoring is open across the set (what the record shows). | An evidence package connecting requirements, authority decisions, test traces, results and the remaining integration gaps. |
Nothing here has been fielded, independently reproduced or given a formal TRL determination. The seven framework stages named on this site (SATA, HMAA, ADARA, MAIVA, FLAME, CARA and ERAM) exist as specifications, models and consoles; the Governance Kernel release implements the agent tool workflow, not an integration of all seven.
[ Relevance to U.S. Government Priorities ]
Crosswalk register →
Where the Work Meets Official Guidance
Each row connects an official document to the work in technical terms, names the evidence available today and states the evaluation still needed. Guidance is marked as guidance and policy as policy. Every row cites provisions read on 21 October 2026. No agency has assessed or accepted any mapping. Nothing here is a compliance, certification, authorization or endorsement claim, and the existence of a governance mechanism reduces no software safety requirement. Acquisition authorities are kept apart from technical alignment and appear only under company and engagement information.
| Government need or guidance | Relevant AUTHREX contribution | Evidence available today | Evaluation still needed |
|---|---|---|---|
| Developmental Test and Evaluation of Artificial Intelligence-Enabled Systems Guidebook, OUSD(R&E) DTE&A, February 2025. Guidance; provision level. Section 3.4, Use of Formal Methods in AI; Section 3.5.3.4, Runtime Monitoring of Machine Learning; Section 4.3, Requirements Development, on testability; traceability of data and models as a Responsible AI expectation. | Candidate contribution: a deterministic governor around a learned component, monitored and recorded at runtime, with TLA+ models as formal-methods evidence for the authority automaton. The guide itself notes that an actuator-monitor or governor architecture may permit high-fidelity modeling of the monitor. | 21 TLA+ modules categorized by model faithfulness, two of them faithful (Formal Coverage); replayable records in the consoles; the Kernel's gated tool calls. | Formal results are bounded and model-relative; the sponsor supplies the tools, the T&E expertise and the system under test. No AI-enabled system has yet been governed in a test. |
| Developmental Test and Evaluation of Autonomous Systems Guidebook, OUSD(R&E) DTE&A, September 2025. Guidance; provision level. Section 5.5.2, Runtime Assurance: a deterministic wrapper with the authority to intervene; continuous monitoring, anomaly detection, response mechanisms, data recording, safe recovery, failure detection and recovery. Section 5.2.7, Assurance Cases. Section 5.3.5, Adversarial Testing. | Candidate contribution: the governance layer as a runtime-assurance wrapper in the guide's sense, with the authority state, the hold and the record as its response mechanisms and data recording; the claim register as the start of an assurance case. | Seeded consoles, Kernel tests and hash-chained records, all synthetic (claim register). | The guide's additional V&V of the wrapper itself has been met only by self-tests. No sponsor-defined scenario, no adversarial campaign against the governor and no assurance case for a platform. |
| Machine Learning System Safety Engineering Guide with Implementation Process and Tasks Supporting MIL-STD-882E w/Change 1, OUSW(R&E) Systems Engineering and Architecture, January 2026. Guidance; provision level. Section 2.2: lowering the Function Control Category of an ML-enabled function through interlocks and guardrails, with the mitigations themselves demonstrating sufficient level of rigor; design-analysis task DA-3 on wrappers that verify or intervene; Appendix A on interlocks, watchdogs and guardrails. | Candidate contribution: the governance gate as an interlock or guardrail intended to lower the function's control category, with the hold-for-human path as the predetermined intervention. | Specification and simulation; the Kernel's tool gating in software (integration boundary). | The mitigation must carry its own level-of-rigor evidence to a program's LOR table; none has been produced, and no hazard analysis has been delivered. |
| MIL-STD-882E with Change 1, 27 September 2023. Standard; applies when invoked by a solicitation or contract; provision level. Section 4.4 and Table IV, software control categories: Autonomous (level 1) without the possibility of predetermined safe detection and intervention; Semi-Autonomous (level 2) allowing time for predetermined detection and intervention by independent safety mechanisms. Sections 4.3.1 to 4.3.8, the system safety process. | Candidate contribution: an independent mechanism for predetermined detection and intervention, so that a governed function can be assessed below the Autonomous category; a hazard log tying authority restrictions to hazards. | A ten-risk register in the technical specification follows the severity and probability structure (crosswalk register). | No hazard analysis (Tasks 201 to 209) against a platform; no risk accepted by any authority; the standard has not been invoked for any AUTHREX work. |
| DoDD 3000.09, Autonomy in Weapon Systems, Office of the Under Secretary of Defense for Policy, 25 January 2023. DoD directive for autonomous and semi-autonomous weapon systems; text read 21 October 2026. Paragraph 1.2.a: systems designed to allow commanders and operators to exercise appropriate levels of human judgment over the use of force; 1.2.a.(1)(b): a system unable to complete an engagement within the intended timeframe, geographic area and constraints terminates the engagement or obtains additional operator input before continuing; 1.2.a.(2)(c): technologies and data sources transparent to, auditable by and explainable by relevant personnel; 1.2.a.(3)(b) and (c): transparent feedback on system status and clear procedures for trained operators to activate and deactivate system functions; Section 3, paragraph c.(2): additional T&E for each new or revised operating state, and changes to the state transition matrix may require whole system follow-on operational T&E. Paragraph 1.1.b: the directive does not apply to autonomous or semi-autonomous cyberspace capabilities, unarmed platforms, or systems that are not weapon systems. | For weapon-system programs only, as candidate engineering responses: the hold before an irreversible action, as a way to obtain additional operator input before continuing (1.2.a.(1)(b)); a record of each authority decision (1.2.a.(2)(c)); the displayed authority state with explicit hold and restore steps (1.2.a.(3)); and authority states and transitions written as an explicit specification, so that a change to them is visible to the T&E of Section 3. | Specification and simulation: the AUTHREX-ABORT latch on a lapsed irreversible action, synthetic (AUTHREX-ABORT; Heilmeier answers). | Paragraph 1.1.b places the agent, infrastructure and space profiles outside the directive unless a weapon system is involved. No weapon-system program and no program-specific evidence. |
| Implementing Responsible Artificial Intelligence in the Department of Defense, Deputy Secretary of Defense memorandum, 26 May 2021, and the Responsible Artificial Intelligence Strategy and Implementation Pathway, prepared by the DoD Responsible AI Working Council, June 2022 (texts read 21 October 2026). DoD policy direction. The five DoD AI Ethical Principles, including Traceable (auditable methodologies and documentation), Reliable (explicit, well-defined uses, tested across the life cycle) and Governable (the ability to detect and avoid unintended consequences and to disengage or deactivate deployed systems that demonstrate unintended behavior). Pathway Tenet 2, Warfighter Trust: a test and evaluation and verification and validation framework that integrates real-time monitoring, algorithm confidence metrics and user feedback; LOE 2.2.2: AI vendors and developers whose systems have human-facing interfaces to provide traceable feedback on system status and clear procedures for trained operators to activate and deactivate system functions; LOE 2.2.3(b): processes for operators to report changes in capability performance, outcomes, emergent behavior and disengagement. | Addresses a problem discussed in the principles: a specified path to withhold or narrow a system's authority when its evidence degrades, and a record of each authority decision, offered as engineering material for the Governable and Traceable principles and for the operator reports of LOE 2.2.3(b); the displayed authority state, with explicit hold and restore steps, as material for the status feedback and activation procedures of LOE 2.2.2. | Tier and hold behavior in the consoles; the Kernel's signed audit evidence (claim register). | Whether an authority narrowing counts as disengagement of a deployed system is a program and policy determination. No program has evaluated the layer against its Responsible AI implementation, and no operator study of the displays is on record. |
| Careful Adoption of Agentic AI Services, joint cybersecurity information sheet by the National Security Agency, the Australian Signals Directorate's ACSC, CISA and partner agencies, announced by NSA on 30 April 2026 and by CISA on 1 May 2026; the document prints no issue date. Guidance; read 21 October 2026, page numbers as printed. Least privilege for agents (page 7); tool use restricted to an approved allow list, logging of agent tool usage, trigger-action protocols that automatically restrict agent permissions when unexpected behavior emerges, and agents prohibited from modifying their own privileges (page 18); no autonomous execution of high-impact actions without prior human approval (page 22). | Supports evaluation of these practices with implemented mechanisms: tier-gated tool calls, a human approval queue for requests above the tier, a ledger of gated requests, and re-escalation only by explicit operator action. | Governance Kernel v1.0-QA10, synthetic data; the AUTHREX-AGENT console. | Not evaluated against the practice list by anyone other than the author; no deployment on an agent platform. |
| Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, National Security Agency, Version 1.0, May 2026. Guidance; read 21 October 2026. Least privilege for MCP agent processes; approval workflows that MCP itself cannot enforce at protocol level; logging of all tool and model invocations with the exact parameters and identities; caution with dynamic tool discovery; explicit control and segregation of tools that handle sensitive data. | Candidate contribution: an authorization and approval layer outside the protocol, at the proxy between agent and tool, with per-invocation records. | Governance Kernel v1.0-QA10: MCP SDK governance on loopback. | No evaluation against a production MCP deployment; token lifecycle, discovery control and server inventory are outside what the release demonstrates. |
| Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, joint cybersecurity information by NIST's Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), the NSA Super Intelligence Security Center (SISC) and CISA, PP-26-4396, Version 1.0, October 2026, released 16 October 2026; read 21 October 2026 with NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025, on which the practices draw. Voluntary guidance, primarily for organizations training or evaluating highly capable SI agents on long-horizon tasks with limited human supervision; it may also apply to deployers of such agents. Practice 1.1, least privilege for agent access to information, systems and tools; 1.6, an SI control policy with intended responses to defined scenarios and infrastructure for automated enforcement; 1.7, mechanisms to rapidly block, contain or terminate agent activity; 3.5, detection with escalation for human review or automated responses, for example with canaries placed in environments; 5.3, tamper-resistant logs with reliable timestamps that cover tool calls and security-control decisions; 6.1 and 6.2, shutdown policies for unintended activity, control failures and monitor outages or tampering, calibrated to the capability of the model and the severity or scope of the incident, and automatic shutdown of impacted trajectories when a control failure or an incident in progress is detected; 7.3 and 7.5, containment layers validated before agents restart, and the recovery decision and remaining risks documented before activity resumes. | Candidate contribution: tier-gated tool calls under a signed policy, with requests above the tier held for human approval, as least privilege and automated enforcement (1.1, 1.6) and as blocking with escalation for human review (1.7, 3.5); authority that narrows at once when a required condition fails, a failure that can be specified to include a monitor outage, and widens only by authorization (6.1, 6.2); restoration staged through approvals before a new grant (7.3, 7.5); and AUTHREX-DEFEND's bait files as canaries on one computer, report only (3.5). | Governance Kernel v1.0-QA10 tool gating on loopback, synthetic data; restoration in synthetic consoles (AUTHREX-SAFING: exit only under an authorized re-arm with human approval; AUTHREX-QUARANTINE: read-only probation before a new grant); AUTHREX-DEFEND 0.1.6, read practice by practice on the Product page. | Nothing has run in an SI training or evaluation environment, and nothing in the set shuts down a real agent: the Kernel governs only calls routed through its proxy, and the consoles and the DEFEND workbench act on synthetic subjects. No red-team campaign has been run against any monitor or control (1.9, 4.1), and no result has been independently reproduced (2.4); external anchoring of the records is open and the DEFEND evidence packages carry no independent timestamp (5.3); a program running under the same account can see, change, stop or hide from DEFEND (3.3). |
| DoDI 5000.87, Operation of the Software Acquisition Pathway, Office of the Under Secretary of Defense for Acquisition and Sustainment, 2 October 2020. DoD issuance for programs on the pathway; text read 21 October 2026. Paragraph 1.2.f: software instrumented so that critical monitoring of its health, security and operational effectiveness can be automated to the maximum extent practicable; 3.3.b.(7): automated test scripts and test results made available to the test community; 3.3.b.(8): automated cyber testing and continuous monitoring of operational software designed to support a continuous authority to operate, with all safety critical software standards and guidance applying; 3.3.b.(9)(b): runtime monitoring and logging among the cybersecurity and assurance capabilities; 3.3.b.(4) and (5): a minimum viable product and, for applications programs, a minimum viable capability release deployed to an operational environment within 1 year after funds are first obligated. | Should a program adopt the pathway: governance software delivered in versioned increments, with automated tests and release checks whose scripts and results can be shared with the test community (3.3.b.(7)), and the authority layer's decision records as one form of the runtime monitoring and logging of 3.3.b.(9)(b). | Versioned releases with per-release gates: SAFING, QUARANTINE, DA (Catalog). | No program, no government product owner and no minimum viable capability agreed with a user. |
| DoWI 8430.01, Accelerated Mission Software, Office of the DoW Chief Information Officer, approved 31 August 2026, effective 8 September 2026. DoW issuance binding on DoW Components for software they operate; read 21 October 2026. Section 3.5.a, verifiable assurance as a condition for operation: software operated on DoW networks and systems supported by machine-readable evidence of its component composition, build integrity and application security; Section 3.5.d, integrated and continuous test and evaluation; Section 3.5.f, software safety and operational resilience, including runtime protection, fault tolerance and rollback and recovery mechanisms; Section 3.6, AI in Software Development, paragraph 3.6.e, Reliable AI: for each AI-enabled capability, Components determine use case-specific risk and mitigation requirements, define measurable performance benchmarks, verify them before deployment and ensure they are continuously monitored in operation. | Candidate contribution: runtime protection and rollback or recovery behavior of the kind Section 3.5.f names, with a record of each authority decision, as one mitigation a Component could specify for an AI-enabled capability under 3.6.e(1)(a) and as evidence it could draw on when it monitors that capability in operation under 3.6.e(1)(d). | Versioned test records, release gates and hash-chained records in the artifacts (claim register). | The instruction binds Components, not vendors. AUTHREX has produced no software bill of materials or provenance record to its format, and no Component has operated the layer. |
[ Available for Technical Evaluation ]
Complete catalog →
What a Reviewer Can Open Today
Five items lead; each shows what can be inspected, where it runs and how mature it is, its principal limitation and how it is reached. Figures are copied from each artifact's page and the claim register. Internal tests are not independent validation, synthetic scenarios are not operational demonstrations, publication peer review is not verification of a complete system, and a closed internal QA cycle does not make a release production-ready.
| Artifact and version | What the reviewer can inspect | Environment and maturity | Principal limitation | Evidence and access |
|---|---|---|---|---|
| Governance Kernel v1.0-QA10 (July 2026) | The documented software implementation: MCP-based agent tool governance, authority-tier enforcement, human approval gating with RBAC, signed policy loading, checkpointed audit evidence and reviewer report export; the 53-function test suite; VALIDATION-REPORT.md and the external reviewer packet. | python:3.11-slim container; Docker-verified, synthetic-data MVP; internal QA cycle QA10 closed. Self-assessed readiness is stated in the catalog; no formal TRL determination. | Synthetic data; loopback latency only; not released; no external reproduction; guarantees depend on placement, platform integrity, protected keys and downstream actuation paths. | Source by request for structured external technical review while counsel review is pending (validation status; register C-01). |
| AUTHREX-SAFING v1.5.0 | The released synthetic console and package: safe-state entry, hold, deepen and exit only under an authorized re-arm with human approval; the verification record (1,061 checks, nine modeled properties, 50 of 50 mandatory mutants killed); the SHA-256 hash-chained ledger and replay from seed. | Sealed release package with fixed seed 20260610 and detached signatures; released synthetic console. | Synthetic scenarios; no dynamics, no actuation; recovery is simulated, not physically validated. | Browser console and downloadable release zip with source and evidence (AUTHREX-SAFING; register C-05). |
| AUTHREX-ABORT, SIM-13 Build 0.6 | Two frozen TLA+ modules (AuthorityLapse.tla version 3 across 21 configurations, InterfaceRecord.tla version 1 across 35), the 105-test implementation suite, 34 release checks, the published open gates and the console with its latch behavior. | Author's machine; a 1,000,000-run soak in a separate execution environment; console with two frozen modules. | Scenario program at 23 of a planned 42; two behavioral negative controls open; not integrated with any platform; the soak is not independent verification. | Browser console and catalog record SIM-13 (AUTHREX-ABORT; register C-04). |
| AUTHREX-QUARANTINE 2.2.5 | Twelve scripted containment scenarios over eight governed agents, stepped or run; engine 74 of 74 and console 44 of 44 tests; 11 of 11 non-equivalent mutants killed; the two external review rounds and their twenty corrected findings. | Recorded environment Node v22.22.2, Chromium 141.0.7390.37, Python 3; released synthetic console; externally reviewed. | Synthetic; no enforcement; no hardware; a second reading of the source, not independent reproduction. | Browser console (AUTHREX-QUARANTINE; register C-07). |
| Formal models, 21 TLA+ modules | The faithfulness taxonomy, the published counterexamples, the withdrawals and the open MAIVA quorum defect located in production source. | TLC model checks on the author's machine at stated bounds; two modules faithful to the artifact they model. | Model-relative and bounded; a model proves nothing about a deployed implementation; surrogate results concern mechanism classes. | Formal Coverage Status; register C-02 and C-03. |
Treated separately: AUTHREX-DEFEND
DEFEND is a desktop engineering preview, not a Governance Kernel integration, and keeps its own distribution and access limits.
| Artifact and version | What the reviewer can inspect | Environment and maturity | Principal limitation | Evidence and access |
|---|---|---|---|---|
| AUTHREX-DEFEND 0.1.6, engineering preview | Four report-only host pages (scan computer, check a file, network, protected apps) and a synthetic workbench with a test kit of inert samples; the delivery checks (macOS 42 passed, 0 failed, 4 not run; Linux 32 passed, 0 failed, 2 not run). | Installable software for macOS, Windows and Linux, sealed 5 October 2026 with per-file SHA-256; owner machines. | Report only: it enforces nothing; the Governance Kernel is not connected; a controlled pilot is blocked; no measured detection or false-positive rate. | Offered to departments and agencies of the United States Government, and to personnel they authorize, for evaluation on a test computer that holds nothing private; not offered to commercial buyers, foreign governments or the public; no installer on this site (Product; register C-08). |
Also open today: AUTHREX-DA and the standalone consoles
Two further artifacts a reviewer can run in the browser, in the same columns.
| Artifact and version | What the reviewer can inspect | Environment and maturity | Principal limitation | Evidence and access |
|---|---|---|---|---|
| AUTHREX-DA release 1.8 | Per-record admissibility verdicts (ADMIT, ADMIT_FLAG, QUARANTINE, REJECT); 101 of 101 local tests; 12 release gates; nineteen audit passes on file, five internal and fourteen external. | Core engine 1.0; engineering preview; browser console. | Work package WP-0 blocked; no DA property model checked; one seed, no preregistered campaign; 38 open items. | Browser console (AUTHREX-DA; register C-06). |
| Standalone consoles (22: 21 of the 25 catalogued simulations, plus DEFEND) | The agentic-AI product console, its five federal application profiles, three standalone governors, three hardened prototypes and the swarm containment prototype; the first fourteen carry a hash-chained decision ledger, deterministic replay and an in-browser V&V suite. | Browser consoles in the Simulation Laboratory. | Self-run engineering artifacts on synthetic data; not independent evidence. | Browser consoles (Simulation Laboratory). |
The complete collection, with evidence classes and maturity per item, is the Catalog. Hardware reference designs are designs, none built; no release carries a new TRL from this page.
[ Founder and Technical Background ]
burakoktenli.com →
Burak Oktenli, Founder of AUTHREX SYSTEMS LLC
Burak Oktenli founded AUTHREX SYSTEMS LLC to investigate how autonomous systems and AI agents should retain, lose and recover permission to act. His computer science degree supports the software implementation, formal modeling and testing in the artifacts on this site; his business degree supports project definition, delivery planning and commercialization; his applied intelligence study, still in progress, bears on the evidence and analytic standards the work addresses. His research translates authority-governance concepts into inspectable specifications, prototypes and evaluation artifacts.
A degree shows training, not that a particular system works; the artifacts, tests and publications below are the record to judge, and each carries its own limits.
| Record | Verified detail |
|---|---|
| Education | Bachelor of Science in Computer Science, University of South Florida, December 2020. Master of Business Administration, Lynn University, May 2026. Master of Professional Studies in Applied Intelligence, Georgetown University, in progress (not a held degree). |
| Professional experience | Prior industry experience in production data engineering. The full professional and research history is on burakoktenli.com. |
| Research and engineering artifacts | The Governance Kernel (v1.0-QA10); the standalone releases AUTHREX-SAFING v1.5.0, AUTHREX-ABORT Build 0.6, AUTHREX-DA release 1.8 and AUTHREX-QUARANTINE 2.2.5; the AUTHREX-DEFEND 0.1.6 engineering preview; 21 TLA+ modules categorized by model faithfulness; twelve hardware reference designs, none built. The original work published on this site was produced by the founder. The governance demonstrations and model evaluations use synthetic scenarios; AUTHREX-DEFEND separately reports observations from the test computer on which it runs (taxonomy). |
| Peer-reviewed journal articles | SATA: Sensor Attestation and Trust Anchoring: A Formally Specified, Simulation-Evaluated Continuous-Trust Protocol for Autonomous-Systems Sensor Edges, Journal of Hardware and Systems Security 10, article 17 (2026), published 21 July 2026, 10.1007/s41635-026-00190-4. The authority gap: why meaningful human control fails at the tier where it is signed, Digital War 7, article 6 (2026), published 31 August 2026, 10.1057/s42984-026-00113-1. Bounded AI and a Layered Assured-PNT Architecture for Jamming-Resilient PNT, The ITEA Journal of Test and Evaluation 47(3), published 29 September 2026, 10.61278/itea.47.3.1009. Publisher records checked 21 October 2026. A fourth peer-reviewed article by the founder, on a security-theory subject, lies outside this work. |
| Accepted, not yet published | Trust-Proportional Authority Governance for Uncrewed Autonomous Systems: Formally Verified Runtime Authority Management, AIAA SciTech Forum 2027, session UAS-16 (Certification for Autonomous Systems), Orlando, presentation 15 January 2027; accepted for presentation following peer review, proceedings publication pending (Catalog V6.1 publications table). |
| Recognition | First Prize, 2026 Naval Intelligence Essay Contest, conducted by Naval Intelligence Professionals with the U.S. Naval Institute, for Audit the Machine: The Unarticulated Risk in AI-Era Naval Intelligence; the essay is to be published in Proceedings and is not yet published (News). |
| Government evaluations on record | Two white papers favorably evaluated by the Air Force Research Laboratory and assessed as of interest to the Air Force, neither funded on stated budget grounds: under BAA FA8750-24-S-7003 (CANVAS), memorandum of 24 June 2026, and under BAA FA8750-25-S-7004 (M-FAT), letter of 13 October 2026. Evaluation records, not contracts, funding, validation or endorsement (register C-09). |
| Patent applications | Eight U.S. provisional patent applications are reported as filed; they are unexamined and create no issued patents and no enforceable rights. |
| What is not claimed | No security clearance, government service, institutional sponsorship, staffed engineering organization or government contract is claimed. Work performed before the company was formed on September 17, 2026 belongs to the founder and the AUTHREX research program and is not company contract past performance. |
[ Basis for a Scoped Research and Development Effort ]
Why a Bounded Effort Is Supportable Now
Five reasons, each tied to a record a reviewer can open. The argument rests on these records alone; no claim is made that the approach is first, only, unique or ready for operational use, and favorable government evaluation of a white paper is recorded as an evaluation, not as a contract, an award, a validation or an endorsement.
| Reason | Evidence |
|---|---|
| A defined technical problem | Authority changes under degraded evidence: each required source of evidence carries its own validity state, the system may execute only what every required condition admits, permission narrows at once when a condition fails and widens only by authorization. Stated on the home page and developed in the published articles above. |
| Inspectable software, specifications, models and synthetic demonstrations | Governance Kernel source by request; the released AUTHREX-SAFING package; the ABORT, DA and QUARANTINE consoles; 21 TLA+ modules with their faithfulness categories (taxonomy). |
| Versioned test records and documented limitations | Claim register entries C-01 to C-09 with source identity, environment, result, assumptions and open defects; the MAIVA quorum defect is kept open until a changed implementation and supporting verification establish a repair (register). |
| A research record relevant to the proposed work | Three peer-reviewed journal articles with publisher records checked 21 October 2026, an AIAA SciTech 2027 paper accepted for presentation, and two Air Force Research Laboratory white-paper evaluations, each described exactly as recorded (founder). |
| An evaluation approach adaptable to a sponsor's workflow | A preregistered protocol with named baselines (unguarded autonomy, human-in-the-loop, Simplex-style run-time assurance, AUTHREX), nine adverse scenarios and criteria agreed before any test (scoped evaluation; program answers). |
[ An Actionable Engagement ]
Scoped evaluation →
How a Scoped Evaluation Would Run
The scoped-evaluation process on the Contact page, in sequence. Nothing below has been run with a sponsor; every test is planned, and no completion time, price, success rate, staffing capacity or acceptance threshold is stated, because none has been agreed.
| Step | What happens |
|---|---|
| 1. Define the sponsor's question and one bounded workflow | The sponsor states the question in one sentence; one workflow is chosen: a bounded agent tool workflow through the Governance Kernel, safe-state entry and re-arm-gated exit on the AUTHREX-SAFING console, or a sponsor-defined scenario on one seeded console. |
| 2. Identify permitted actions, evidence dependencies, authority transitions and the enforcement boundary | Written down as an authority-state specification, with the host, keys and downstream enforcement stated as assumptions. |
| 3. Agree scenarios, baselines, metrics and acceptance criteria | Recorded with the seeds and scenarios before any test, including what would count against the architecture. |
| 4. Evaluate the selected artifact or scoped prototype | Against the agreed scenarios, with the adverse cases of the scoped-evaluation protocol: stale or contradictory evidence, lost communications, delayed revocation, replayed approvals, restart, a policy change during approval, interrupted recovery, ledger failure and unavailable human supervision. All planned. |
| 5. Deliver results, limitations and a recommendation for the next technical decision | Reported against the criteria whatever they show; the next decision is whether to proceed to government-defined scenarios, degradation and failure injection, or a software-in-the-loop testbed under the seven gated phases of Catalog V6.1. |
Proposed deliverables, scope agreed with the sponsor
| Deliverable | Content |
|---|---|
| Authority-state and policy specification | Permitted actions, evidence prerequisites, states, transitions, approval points and restoration rules for the chosen workflow, versioned. |
| Interface and enforcement-boundary description | What the governor mediates, what can bypass it, its dependencies, and the host response to a denial. |
| Test scenarios and versioned configurations | Scenario definitions, seeds and the frozen configuration they ran against. |
| Test traces and replay instructions | Records sufficient to replay each decision against the frozen configuration. |
| Findings, counterexamples and integration gaps | What held, what failed, what could not be shown, and what integration work remains. |
| An assurance argument | Claim, assumptions, hazards, controls, evidence and unresolved claims, kept visible throughout. |
What an engagement would need from the sponsor
The workflow and its constraints; an authorized technical contact; agreed evaluation criteria; and an appropriate test environment with synthetic or sponsor-supplied unclassified data. Classified information, controlled unclassified information and controlled technical packages are not accepted through the public channels on this site; a handling environment and the applicable terms would be agreed first.
[ Company and Engagement Information ]
Working with AUTHREX →
Entity, Registration and Routes
The dated facts maintained on the Contact page, restated here without addition. Anything not listed is not asserted.
| Item | Status as of October 2026 |
|---|---|
| Legal contracting entity | AUTHREX SYSTEMS LLC, a Florida limited liability company, document number L26000486948, formed on September 17, 2026; Coconut Creek, Florida. One founder; no standing engineering team, hardware laboratory or independent test authority inside the company. |
| SAM.gov registration | Entity registration submitted; not yet active. Unique Entity ID YZJ9SBVMT6K5. CAGE code not yet assigned. Participation and award eligibility are subject to the applicable opportunity and registration requirements. |
| Business representations | Entity size, nontraditional defense contractor status under 10 U.S.C. 3014 and SBIR or STTR eligibility are separate determinations; none is asserted here. No NAICS code, certification, contract vehicle, clearance or eligibility is claimed. |
| Possible routes | Prototype other transactions (10 U.S.C. 4022), research other transactions (10 U.S.C. 4021), broad agency announcements, commercial solutions openings, research agreements such as a CRADA, and teaming or subcontracting with a platform integrator. Each is subject to the specific opportunity's terms and eligibility requirements; none is an existing contract vehicle, and an innovation hub is not a contract vehicle. A route is a way to engage and does not validate the technology. |
| Evaluation access and licensing | Governance Kernel source by request for structured external technical review while counsel review is pending; AUTHREX-DEFEND 0.1.6 offered to U.S. Government organizations for evaluation under the limits stated on the Product page; AUTHREX-SAFING v1.5.0 released under the license in its package; the browser consoles run without registration. Artifact licenses vary by record; the Technology and Capability Catalog V6.1 is published under CC BY 4.0 (working with AUTHREX). |
| Capability statement | The capability brief, Version 4 of September 7, 2026, remains available as issued and supersedes Version 3 of July 22, 2026. A one-page company capability statement has not been issued; when one is, it will carry its own date and version and prior editions will be kept. |
| Contact | The form and email address on the Contact page, for non-sensitive inquiries only. Mailing address: AUTHREX SYSTEMS LLC, Coconut Creek, FL 33073, United States. |