Verified trust for agents that act.

THE PROBLEM IT ANSWERS

Money movement is the hardest practical test of agent trust

Personal AI agents are moving from answering questions to taking actions. The closer those actions come to money, identity, regulated records, and operational systems, the less acceptable it becomes to rely on model intent alone. A personal agent may understand a user’s goal and still be unsafe to act. The real test is whether the system can prove that every action stayed inside an explicit grant of authority.

Financial action compresses identity, consent, timing, irreversible consequences, and regulation into one decision path. Viewing a balance does not authorize a transfer; permission to pay one bill does not imply permission to pay another; and a successful request is not yet a confirmed outcome. Open protocols connect more models, applications, institutions, and services — their value depends on a common trust layer that never treats interoperability as blanket trust.

Required shift: from “the agent appears trustworthy” to “the action was authorized, evidenced, contained, and recoverable.” Trust must be a property of the system, not a promise from the agent. Four principles define the boundary:

THE STANDARD IT IS BUILT TO

Designed to meet, built to exceed

Agentic Armor’s charter is to meet and generationally exceed the governing standards of every domain it enters. The architecture is designed against the union of those standards — where rules overlap, the strictest rule wins. Each domain below names the standard the Armor is designed against. This is design-intent language only: no certification is claimed in the paper, and a standard is claimed only when an outside body grants it.

What “exceed” means, at the level of what a customer receives: evidence by construction — proof is a byproduct of operating, produced as the system works, not assembled afterward for an audit; continuous attestation — standing is attested continuously, as conditions change; verification without trust — a customer can verify the result themselves, without trusting the vendor’s word; and security felt as a feature — protection experienced as part of the product’s value, not a wall between the user and the work.

THE ASSURANCE MODEL

Thirteen guarantees form one defense system

No single control can make an agent safe. Agentic Armor is a 13-element security layer that places a verifiable trust boundary between an AI agent and the systems it may affect — bounded, evidenced, interruptible, and recoverable. It layers identity, authorization, evidence, containment, continuity, and recovery so that a failure in one area does not become unrestricted action. Identity answers who; authorization answers what; evidence answers whether; containment answers what happens when trust changes.

• 01

  Attested agent identity

  Every action is tied to a recognized agent identity and trusted operating context; an actor cannot merely assert who it is.

• 02

  Scoped action authorization

  An agent can perform only explicitly permitted action types within its assigned scope. Unknown, malformed, or out-of-scope requests are denied.

• 03

  Tamper-evident audit chaining

  Applied and rejected actions form a verifiable history. Alteration breaks the chain and identifies where integrity was lost.

• 04

  Short-lived, rotating authority

  Action authority expires quickly and can be replaced or revoked, limiting the useful life of copied or compromised credentials.

• 05

  Operator kill-switch

  An authorized human operator can pause new activity, revoke write authority, or stop the system without depending on the agent’s cooperation.

• 06

  Fail-closed degradation

  When a required trust check or evidence path is unavailable, consequential action is rejected rather than allowed to proceed unwitnessed.

• 07

  Per-domain isolation controls

  A compromised or misbehaving agent, account, or operating center can be isolated without forcing unrelated trusted activity offline.

• 08

  Honest action state

  A requested action is shown as pending until confirmed. Rejection or timeout returns the user to the last confirmed state instead of presenting an assumption as fact.

• 09

  Deterministic conflict resolution

  Concurrent changes follow explicit rules. Ambiguous human-authored content is preserved for review rather than silently merged or overwritten.

• 10

  Secure key lifecycle

  Trust material is rotated, old authority is retired, and emergency revocation can invalidate current access after a suspected compromise.

• 11

  Continuous monitoring and response

  Abnormal volume, repeated invalid actions, and integrity failures become visible and can trigger automatic containment.

• 12

  Executable incident procedures

  Compromise, service partition, and recovery have defined operator actions that can be exercised against the running system, not merely described in policy.

• 13

  Dead Hand failsafe

  Under predefined severe conditions, the system preserves evidence, severs write authority, freezes new authorization, and requires deliberate human recovery.

The thirteen elements are intended to operate as one control system. Removing evidence, containment, or recovery weakens the guarantee even if identity and authorization remain strong.

THE VERIFIED RESULTS

Attack resistance was demonstrated, not inferred

The reference environment was tested as a live system. Each scenario attempted to cross a defined trust boundary; success meant the attempt was rejected and the rejection itself became visible evidence. All thirteen security elements were also exercised independently.

Observed outcome: 6/6 — all six attacks were rejected, each recorded with an attributable reason, and 0 tested adversarial actions were allowed through. The wider verification also exercised every element, including isolation, conflict handling, operator stops, monitoring, incident procedures, and the Dead Hand failsafe.

The same discipline, applied to Medicaid oversight in the Medicaid Compliance Atlas, stands as follows — the defensible figures, disclosed in full:

Bureau 1 exemplar complete: 223 L4 provisions and 53 leadership questions, independently re-counted clean. The legacy audit chain was corroborated at 93%, with the full result disclosed, including what did not corroborate. No claim is made in the paper for Bureaus 2–7. The system caught its own headline figure inflated and retracted it to the defensible number, in public.

What the result does not mean: it is not a universal “bulletproof” claim, an external certification, or a substitute for institution-specific security review. Production deployments must be independently assessed against their own threat model, regulatory duties, integrations, and operating environment. This is an architecture and verification paper, not a claim of certification or production approval.