AATA — zero-trust controls for autonomous fleets.

An autonomous machine can cross a boundary that ordinary software cannot: it can turn a model output into a physical or operational action. Once agents can move equipment, change configurations, call privileged tools, or coordinate as a fleet, a prompt-level guardrail is not a control plane. The system needs a way to decide who the agent is, what it may do now, how much authority remains under threat, whether the runtime has drifted, and whether the action can be reconstructed later.

AATA-2026-001 — the Autonomous Agent Trust Architecture — is Protime Labs' reference architecture for that problem. It is a zero-trust overlay designed to wrap an existing autonomous estate without requiring its underlying agents, robots, or vehicles to be rewritten. Twelve components surround the estate, gating or observing every governed action across five planes: governance, trust, control, observability and evidence, and data-plane interception.

This is intentionally a falsifiable architecture, not a diagram-only framework. The repository includes a dependency-free Python 3.10+ prototype, invariant tests, adversarial drills, a mixed-fleet simulation, and an evidence console generated from live prototype output.

The governed action is the unit of control

AATA treats a proposed action as a transaction that must collect enough authority and evidence to proceed. The hot path begins with workload identity, narrows that identity through a capability token, evaluates policy and risk, checks runtime state, and records the decision before an actuator or tool receives the call. If required evidence cannot be produced, the action does not happen.

That sequence supports four reference workflows:

1. Gated action: a tool or actuator call passes through deterministic identity, capability, policy, runtime, and evidence checks.
2. Agent birth: a newly started workload is attested, registered, and issued only the capabilities appropriate to its role and current risk posture.
3. Compromise response: threat signals progressively reduce authority and trigger graduated hygiene instead of depending on a single binary quarantine switch.
4. Disconnected operation: a fleet enters a denied, disrupted, intermittent, or limited-connectivity mode, continues only within a locally authorized envelope, preserves evidence, and reconciles after the link returns.

The important property is monotonicity: a threat signal may narrow an agent's capabilities, but it cannot silently expand them. Kinetic actions fail closed when required controls are unavailable; informational work can fail degraded inside an explicitly bounded policy. This is a more useful safety boundary than asking a general-purpose model to make the final enforcement decision.

Disconnection is part of the architecture

Most centralized agent-control designs look strongest while the network is healthy. Autonomous fleets are interesting precisely where that assumption fails: a factory segment is isolated, a rover loses backhaul, an emergency vehicle crosses a dead zone, or an adversary targets the control channel itself.

AATA makes disconnected operation a named workflow rather than an exception path. Local leases and policy snapshots define what may continue. Kinetic thresholds tighten as uncertainty rises. Evidence is buffered locally without breaking its chain, then reconciled when connectivity returns. The prototype's blackout drill creates an agent, removes backhaul, runs fourteen governed ticks, injects adversarial conditions, restores the link, and checks continuity, containment, and evidence integrity.

The result is not a claim that offline autonomy is universally safe. It is a testable contract for which actions remain authorized, which controls must still be present, and what proof must survive the outage.

What runs today

The reference prototype uses only the Python standard library for its core path. Running python run_all.py exercises the component tests, the four workflows, the blackout drill, and the generated evidence console. The repository's continuous integration matrix covers Python 3.10 through 3.13.

The included fleet demonstration registers and operates 200 heterogeneous agents: factory workers, humanoids, rovers, and autonomous vehicles. It aligns controls by risk, detects fleet-level conditions, classifies failed tasks, and reports coverage gaps. Its browser console is generated from actual run artifacts rather than mock dashboard data, so architecture claims can be traced to emitted decisions and evidence records.

The prototype deliberately uses labeled standard-library stand-ins where production systems require stronger primitives. HMAC and BLAKE2 demonstrations, for example, establish interfaces and invariants; they do not pretend to replace hardware-rooted identity, public-key signing, or a production evidence store.

Deterministic enforcement, optional semantic assistance

The repository includes optional Anthropic integrations for a governed workload, an advisory semantic judge, red-team scenarios, and a read-only evidence-console copilot. The boundary is explicit: Claude is not placed on the deterministic enforcement path.

That separation matters. A model can add semantic context, investigate an incident, or help an operator navigate evidence. Identity validation, capability attenuation, policy decisions, containment, and evidence continuity must still behave predictably when a model is unavailable, uncertain, or under attack. The architecture uses AI where interpretation helps and conventional controls where repeatability is non-negotiable.

From reference components to production controls

AATA documents a disposition for each of its twelve components rather than implying they all need to be built from scratch. Identity sidecars, runtime sensing and sandboxing, and the telemetry bus are primarily adoption problems. Other components extend existing technology. A smaller set — including the policy-enforcement gateway, evidence ledger, threat scorer, and hygiene orchestrator — carries architecture-specific behavior that needs purpose-built implementation.

The production swap map names concrete targets: SPIRE or Keylime for attestation, Biscuit for capabilities, cosign for signed artifacts, Cedar or OPA for policy, gVisor or Kata for isolation, Tetragon or Falco for runtime sensing, immudb or S3 Object Lock for durable evidence, and NATS JetStream for store-and-forward messaging. OpenTelemetry, WORM storage, NATS, and eBPF adapters are represented as optional integrations around the pure-Python core.

The limits are part of the result

The prototype records failure boundaries that a credible production design must keep visible:

• A syntactically valid action can still carry malicious intent; deterministic gates do not close the semantic gap by themselves.
• Workload attestation establishes identity and measured state, not whether the agent's objective is safe.
• Continuous controls can execute reflexes, but richer decisions still require deliberative systems and accountable operators.
• Revocation speed depends on connectivity and lease design.
• Tamper-evident evidence proves a record's integrity, not the correctness of the judgment made from it.
• A fleet-wide hygiene orchestrator is itself a high-consequence control surface; if hijacked, it could behave like fleet-wide ransomware.

Those are not footnotes. They define the next engineering work: semantic risk controls, hardware-backed identity, production policy and signing systems, operational key management, independent control-plane assurance, and a testable taxonomy of action irreversibility.

Status, use, and contribution

AATA v0.1.0 is a reference prototype and architecture model, not a production cryptographic implementation or a finished product. The code is source-available under the Business Source License 1.1. Non-production evaluation, testing, and research are permitted under the repository terms; production or commercial use requires an authorized beta, pilot, or commercial license. The v0.1.0 change date is July 15, 2030, when its license converts to Apache 2.0.

Start with the repository overview, run the prototype quickstart, or follow the agent onboarding guide to trace an agent from birth through a governed action and evidence verification.