AUTHREX-AGENT
Authority Lifecycle Governance for Agentic AI

Agentic AI is deployed faster than its guardrails.

Agentic AI systems are already deployed in critical infrastructure and defense sectors with autonomous action privileges. The guardrails around them rely on prompt-level instructions and runtime moderation that can be bypassed, manipulated, or evaded through prompt injection, tool misuse, and unconstrained sub-agent spawning.

The AUTHREX-AGENT thesis: prompt-level safety is not enough for autonomous software. A separate execution-layer gate is required because the highest-risk event is not what the model says; it is what the model is allowed to do through tools, credentials, workflows, files, APIs, and sub-agents. AUTHREX-AGENT does not constrain what the agent thinks; it constrains what the agent does.

The seven-stage authority lifecycle pipeline.

Every agentic action proposed by a wrapped LLM runtime traverses seven sealed gates in order. Input arrives. Trust is established. Deception is screened. Identity is verified. Authority is allocated. Redundant evaluations achieve consensus. A deliberation window opens for high-stakes actions. Recovery paths are pre-armed. Risk is evaluated against thresholds. Only then does the action execute. Failure at any stage halts forward progress and triggers CARA recovery.

↓ ERAM RISK GATING APPLIES ACROSS ALL STAGES ↓

Decision outcome resolves to one of four formal states: EXECUTE, DELAY, HANDOFF, or ABORT. Every outcome is signed into the audit ledger with the pipeline trace, authority tier at decision time, and gate-by-gate results.

Make the architecture understandable in under two minutes.

These public, simplified demonstrations translate AUTHREX-AGENT from theory into observable behavior. They are not production code and they do not execute external actions; they show how thresholds, tool envelopes, and audit evidence combine into a deterministic decision.

Seven gates, formally specified.

Each stage in the pipeline operates as a sealed gate. The agent's proposed action does not advance until the current gate produces a passing decision. The specification below describes each gate's purpose, inputs, outputs, the published requirement it implements, and the algorithmic basis.

Four formal outcomes. No fifth.

Every AUTHREX-AGENT decision resolves to exactly one of four named states. The state and its trace are signed into the audit ledger before any external action takes effect.

Four tiers of agentic authority.

HMAA assigns the agent a tier on every decision cycle. The tier determines how much an action can execute without human ratification. Authority de-escalates monotonically within a single decision; re-escalation requires an explicit operator action.

Downgrade triggers: trust τ below tier threshold · deception probability rising · MAIVA quorum failure · tool authority not previously established · sub-agent spawning depth exceeds configured N · ERAM cost-cascade exceeds ceiling. These triggers operationalize public guidance themes of least privilege, accountability, monitoring, and human oversight without claiming certification by any agency.

Five public guidance risk spaces, mapped to control gates.

The table uses the risk-space language from public joint guidance and shows how AUTHREX-AGENT turns each risk category into an execution-layer control gate. This is a research mapping, not a certification claim.

Mapping controls to the Five Eyes agentic-AI joint guidance.

AUTHREX-AGENT is positioned as a research reference implementation of the five named risk categories in Five Eyes joint guidance Careful Adoption of Agentic AI Services (CISA, NSA, ASD ACSC, Canadian Centre for Cyber Security, NCSC-NZ, NCSC-UK · 1 May 2026), and of the oversight, transparency, and incident-response principles in Principles for the Secure Integration of AI in Operational Technology (CISA, FBI, ASD ACSC and international partners · December 2025). The first table below maps the five named risk categories directly to AUTHREX subsystems. The second table cross-references against NIST AI RMF functions and NIST SP 800-53 control families.

Five named risk categories → AUTHREX subsystem mapping

Detailed crosswalk: AUTHREX controls → NIST AI RMF + SP 800-53

This matrix uses public guidance themes and established control families. It deliberately avoids fabricated section numbers or certification language. Final compliance mapping requires a formal assessor.

Documented government need: autonomous cyber-defense authority

Mapping the autonomous cyber-defense use case (Section 10B) to the public programs and statutes that document the governance gap. AUTHREX governs the action-authority decision only; it performs no vulnerability discovery or offensive function.

This alignment is a research crosswalk. It is not a FedRAMP, CMMC, FISMA, NSA, CISA, DoD, FAA, or other government certification claim. AUTHREX is not a U.S. Government information system and no agency endorsement is implied. Cited guidance documents are publicly available at the linked sources.

How AUTHREX-AGENT wraps your agentic runtime.

AUTHREX-AGENT is a software shim. It does not replace the agent's model, planner, or tool registry. It sits between the agent's intent-to-act and the tool execution layer. Integration is a YAML config plus a wrap call.

1. Initialize with a YAML config

# authrex-agent.yaml
version: "1.0"
domain: "agentic-ai"          # Sixth domain. Same pipeline, agent-specific tunings.
tier_default: "T3"            # Start at full autonomy; downgrade on signal.
audit_ledger:
  signer: "ecdsa-p256"
  storage: "./ledger.jsonl"
stages:
  sata:    { tau_threshold_t3: 0.7, tau_threshold_t2: 0.5 }
  adara:   { pd_threshold: 0.4, injection_corpus: "cisa-2026-05" }
  hmaa:    { downgrade_monotonic: true }
  maiva:   { quorum: 4, evaluators: 5, spawn_max_depth: 2 }
  flame:   { window_ms_t2: 2000, window_ms_t1: 5000, timeout_default: "abort" }
  cara:    { recovery_registry: "./recovery.yaml" }
  eram:    { cost_ceiling_usd: 10.0, cascade_depth_max: 3 }
authorized_envelope:
  tools: ["web.search", "file.read", "git.diff"]
  tool_outside_envelope: "handoff"     # Never silently allow.

2. Wrap a tool call

from authrex_agent import AuthrexAgent, Decision
aa = AuthrexAgent.from_yaml("authrex-agent.yaml")
# Wrap any existing agentic runtime's tool-call surface
def on_tool_call(tool, args, ctx):
    decision: Decision = aa.evaluate(
        action=dict(tool=tool, args=args),
        context=ctx,
    )
    match decision.outcome:
        case "EXECUTE": return tool.call(args)
        case "DELAY":   return aa.await_confirm(decision)
        case "HANDOFF": return aa.escalate(decision)
        case "ABORT":   return aa.recover(decision)

3. Wrap a sub-agent spawn

def on_spawn_subagent(spec, parent_ctx):
    # MAIVA quorum gate fires here; HMAA inherits tier with downgrade rule
    decision = aa.evaluate_spawn(spec=spec, parent=parent_ctx)
    if decision.outcome != "EXECUTE":
        raise SpawnDenied(decision.trace)
    return spawn_with_inherited_tier(spec, decision.tier)

The evaluate() → Decision API is identical across all six domain instantiations. Switching from agentic AI (AUTHREX-AGENT) to autonomous vehicles (BLADE-AV) or directed-energy (BLADE-EDGE) is a YAML config change, not an application code change. View cross-domain example matrix →

ECDSA-signed, append-only, hash-chained.

Every decision the pipeline produces is committed to a per-entry signed, hash-chained ledger before any external action takes effect. The ledger is the auditable evidence base for post-hoc review, red-team analysis, and regulatory inspection.

Entry schema

{
  "ts":           "2026-05-18T08:42:11.482Z",
  "agent_id":     "agent-research-7c1d",
  "action":       { "tool": "git.push", "args": {"branch": "main"} },
  "pipeline": {
    "sata":  { "tau": 0.63, "provenance": ["user", "diff"] },
    "adara": { "pd":  0.12 },
    "iff":   { "authorized": true },
    "hmaa":  { "tier_in": "T3", "tier_out": "T2" },
    "maiva": { "quorum": "5/5" },
    "flame": { "window_ms": 2000, "resolved": "handoff" },
    "eram":  { "risk": "medium", "cost": 0.0 }
  },
  "outcome":      "HANDOFF",
  "prev_hash":    "3f7a9c1d4e...",
  "signature":    "30450221008c..."     # ECDSA P-256
}

The prev_hash field of entry N matches the SHA-256 of entry N-1. Tampering with any prior entry invalidates every subsequent signature. The ledger format is JSONL (one JSON object per line) for tail-friendly streaming and standard logging-pipeline ingest.

Three scenarios traced gate-by-gate.

Each scenario below shows how AUTHREX-AGENT resolves a documented agentic AI risk. The use cases are illustrative reference flows, not field-collected incident data.

Who authorizes an autonomous patch to live critical infrastructure?

The DARPA AI Cyber Challenge (AIxCC), a two-year, $29.5M DARPA and ARPA-H program concluded at DEF CON 33 in August 2025, produced autonomous cyber-reasoning systems (CRS) that find and patch vulnerabilities in critical-infrastructure open-source software at machine speed. Four of the seven systems were released open source for cyber defenders. AIxCC solved the detection-and-patch problem. It did not create the authority layer that decides whether an autonomous CRS may apply a patch to a live water-treatment or power-grid controller, with what evidence, at what authority tier, and with what rollback. A bad autonomous patch to a live SCADA controller can be as damaging as the flaw it closes. AUTHREX-AGENT governs that decision.

Governance scope only. AUTHREX-AGENT treats the CRS as a black box that emits a finding and a proposed action. It governs whether the action is authorized; it performs no vulnerability discovery, no exploit generation, and no offensive function of any kind. The CRS finding is an input to the pipeline.

All four flows are runnable in the simulator above under the "Cyber-defense authority (autonomous CRS)" scenario group. This is a governance reference architecture at TRL 3-4. It is illustrative, not field-collected incident data, and contains no offensive cyber capability. The May 2026 Dragos report on a municipal water utility describes an AI-assisted intrusion in the IT environment with an attempted but unsuccessful pivot to the OT layer; it is referenced here only as context for why autonomous action-authority on OT requires governance.

What must be true before anyone trusts the architecture.

A serious defense or intelligence reviewer will not be convinced by diagrams alone. The page now states the safety claims, the evidence expected for each claim, and the residual risk that remains at TRL 3-4.

Claims, evidence, and current validation status.

Every operational claim made on this page maps to a specific evidence path. The status column distinguishes "demonstrated in browser reference" from "specified, requires independent validation" so reviewers can calibrate trust per claim, not per page.

The Evidence Register is the single source of truth for what AUTHREX-AGENT has demonstrated versus what it specifies. Every "Demonstrated" entry is a reference simulation; every "Specified" entry requires independent validation before any operational use.

Reference V&V protocol.

The reference architecture is accompanied by a formal specification and a published evaluation protocol. The same protocol governs the AUTHREX hardware platforms.

TRL 3-4. Analytical and experimental critical-function proof-of-concept. Production deployment requires red-team certification per the published protocol and a target-specific System Safety Program Plan.

National security instantiation, beyond the baseline.

The baseline AUTHREX-AGENT is designed for commercial critical infrastructure. The architecture is designed to support High-Assurance instantiations for defense and intelligence workloads, which require bridging the software pipeline to physical and post-quantum realities. The five enhancements below are research extensions, not part of the baseline TRL 3-4 reference.

These five extensions move the architecture from a commercial governance reference toward a defense / intelligence reference. None is required by the baseline, none is implemented in the public demo, and none is offered as a certification claim. They are stated here to identify the architectural surface that bridges software governance to nation-state operating assumptions.

The hardware root of trust: BLADE-AGENT-HSM.

AUTHREX-AGENT is one half of a two-piece program. The software shim on this page runs the authority lifecycle so any agent can adopt it immediately. BLADE-AGENT-HSM is the hardware half: an attachable, tamper-evident root of trust that makes that lifecycle non-forgeable by moving the signing keys, the authority-tier state, and the audit ledger out of general-purpose memory and into dedicated secure silicon. It is the seventh platform in the BLADE family and the first hardware root of trust in that family.

BLADE-AGENT-HSM is a research demonstrator. No certified hardware exists; no FIPS, Common Criteria, EAL, NSA, or DoD endorsement, validation, or certification of any kind is claimed. Full specification, interface control document, and reproducible artifacts are published open-access on Zenodo (DOI 10.5281/zenodo.20299821, CC BY 4.0).

What AUTHREX-AGENT does not do.

Reference materials.

@misc{authrex_agent_2026,
  author  = {Oktenli, Burak},
  title   = {AUTHREX-AGENT: Authority
            Lifecycle Governance for
            Agentic AI},
  year    = {2026},
  note    = {Reference architecture},
  url     = {https://authrex.systems/
            authrex-agent.html}
}

Sixth instantiation of the AUTHREX framework.

AUTHREX-AGENT extends the same authority lifecycle pipeline that runs in the five BLADE hardware platforms. Cross-domain portability is the thesis: a YAML config change moves the pipeline from agentic AI to autonomous vehicles, directed energy, infrastructure, maritime, or orbital operations.