The Standard

WHITE PAPER · PUBLISHED

Agentic Armor — a 13-element security layer for agentic systems, wherever agents act in the real world

EDITION · Refreshed edition, October 23, 2026 · First published October 12, 2026
AUTHOR · Michael R. Brotherton, PMP, CSM
ROLE · Founder, Agentic Armor LLC

Public architecture overview. This paper describes the design’s commitments and the results of the house’s own testing. Implementation details are available under a nondisclosure agreement.

ABSTRACT · EXECUTIVE SUMMARY

Trust must be a property of the system, not a promise from the agent

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.

Agentic Armor is a 13-element security layer designed to make agent action bounded, evidenced, interruptible, and recoverable. It places a verifiable trust boundary between an AI agent and the systems it may affect. The layer is protocol-oriented: it is intended to sit alongside open and interoperable agent frameworks rather than depend on one model, one interface, or one institution.

The architecture is organized around four principles: least privilege, evidence for every action, fail-closed behavior, and operator control. Together, its thirteen elements establish who is acting, what that actor is allowed to do, what actually happened, how abnormal behavior is contained, and how human operators retain final authority.

Test result (the house’s internal verification). In a live reference environment, the complete six-scenario attack suite passed 6/6. Replay, forgery, unauthorized-action, malformed-action, abuse-volume, and clock-integrity attacks were rejected and evidenced. All thirteen security elements were also exercised independently. Who tested, against what, and where the record lives is stated with the results, in the verification section.

THE RISK — Agents can cross the boundary between advice and action. In financial services, a single unauthorized or unwitnessed action can create direct harm.

THE ANSWER — A separate trust layer limits authority, verifies action, records outcomes, detects anomalies, and preserves an immediate human stop.

THE EVIDENCE — Thirteen controls were exercised against their stated commitments; in the house’s own testing, a focused attack suite passed all six adversarial scenarios.

THE OPPORTUNITY — The same control model can support a bank-embedded living budget, open personal-agent protocols, and other regulated workflows.

This is an architecture and verification paper, not a claim of certification or production approval. Deployment assurance must be completed for each institution, environment, and regulatory context.

THE PROBLEM IT ANSWERS

Money movement is the hardest practical test of agent trust

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.” Four principles define the boundary:

Interpret intent › Request authority › Take action › Prove outcome

THE ARCHITECTURE

Thirteen elements form one defense system

No single control can make an agent safe. Agentic Armor layers identity, authorization, evidence, containment, continuity, and recovery so that a failure in one area does not become unrestricted action.

Each element below is stated as the commitment the design carries, in design form, and each element’s state is printed in its own line. The state of the layer, stated once and carried in every line: all thirteen elements were exercised in a tested reference environment (Agentic Armor Verification Report, October 2026); the kit is tested, not deployed in any live system.

• 01

  Attested agent identity

  Every action is designed to be tied to a recognized agent identity and trusted operating context; an actor cannot merely assert who it is. State: exercised in the tested reference environment; tested, not deployed.

• 02

  Scoped action authorization

  An agent is designed to perform only explicitly permitted action types within its assigned scope. Unknown, malformed, or out-of-scope requests are denied. State: exercised in the tested reference environment; tested, not deployed.

• 03

  Tamper-evident audit chaining

  Applied and rejected actions form a verifiable history. Alteration breaks the chain and identifies where integrity was lost. State: exercised in the tested reference environment; tested, not deployed.

• 04

  Short-lived, rotating authority

  Action authority is designed to expire quickly and to be replaceable or revocable, limiting the useful life of copied or compromised credentials. State: exercised in the tested reference environment; tested, not deployed.

• 05

  Operator kill-switch

  An authorized human operator is designed to be able to pause new activity, revoke write authority, or stop the system without depending on the agent’s cooperation. State: exercised in the tested reference environment; tested, not deployed.

• 06

  Fail-closed degradation

  When a required trust check or evidence path is unavailable, consequential action is designed to be rejected rather than allowed to proceed unwitnessed. State: exercised in the tested reference environment; tested, not deployed.

• 07

  Per-domain isolation controls

  A compromised or misbehaving agent, account, or operating center is designed to be isolable without forcing unrelated trusted activity offline. State: exercised in the tested reference environment; tested, not deployed.

• 08

  Honest action state

  A requested action is designed to be shown as pending until confirmed. Rejection or timeout returns the user to the last confirmed state instead of presenting an assumption as fact. State: exercised in the tested reference environment; tested, not deployed.

• 09

  Deterministic conflict resolution

  Concurrent changes are designed to follow explicit rules. Ambiguous human-authored content is preserved for review rather than silently merged or overwritten. State: exercised in the tested reference environment; tested, not deployed.

• 10

  Secure key lifecycle

  Trust material is designed to be rotated, old authority retired, and emergency revocation able to invalidate current access after a suspected compromise. State: exercised in the tested reference environment; tested, not deployed.

• 11

  Continuous monitoring and response

  Abnormal volume, repeated invalid actions, and integrity failures are designed to become visible and to be able to trigger automatic containment. State: exercised in the tested reference environment; tested, not deployed.

• 12

  Executable incident procedures

  Compromise, service partition, and recovery carry defined operator actions that can be exercised against the running system, not merely described in policy. State: exercised in the tested reference environment; tested, not deployed.

• 13

  Dead Hand failsafe

  Under predefined severe conditions, the Dead Hand is designed to preserve evidence, sever write authority, freeze new authorization, and require deliberate human recovery. State: exercised in the tested reference environment; tested, not deployed.

System-level design. Identity answers who; authorization answers what; evidence answers whether; containment answers what happens when trust changes.

13 security elements independently exercised · 6/6 live attack scenarios passed · 0 tested adversarial actions allowed through — all in the house’s own testing, Verification Report, October 2026.

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

VERIFICATION — THE HOUSE’S OWN TESTING, ATTRIBUTED

Attack resistance was demonstrated, not inferred

Provenance, stated in the same breath as the results: the suite below was run by the house’s own checking seat — a checker separate from the builders, by house rule — against the October 2026 reference environment. The record is the Agentic Armor Verification Report, October 2026. This is internal verification: the house tested its own layer and kept the receipts. Self-testing is evidence; it is not an outside certification, and no outside body has certified the layer.

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.

Observed outcome: all six attacks were rejected. Each rejection was recorded with an attributable reason. The wider verification also exercised every element, including isolation, conflict handling, operator stops, monitoring, incident procedures, and the Dead Hand failsafe.

What the result means. The evaluation supports the stated architecture-level commitments within the tested reference environment. It demonstrates that the controls work together under direct adversarial pressure, including conditions designed to exploit copied authority, false identity, excess privilege, invalid requests, abnormal traffic, and stale authorization.

What the result does not mean. The result 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.

APPLICATIONS

The trust layer travels wherever agents cross into consequential action

Agentic Armor is not limited to one user interface or one data domain. Its purpose is to provide the same bounded-action contract wherever an AI agent must interact with a protected system.

Banking-embedded living budget. A bank can place a dynamic budget experience beside real balances, transactions, bills, and savings goals. The trust layer keeps advice separate from authority, makes consequential actions explicitly scoped, and shows the customer only confirmed outcomes as confirmed.

Financial services on personal-agent protocols. Open agent protocols can connect models, customers, banks, and service providers without treating openness as blanket trust. Each participant receives bounded authority, and institutions retain evidence, containment, and stop controls.

Regulated industries. Healthcare, public benefits, energy, insurance, and other regulated settings share the same need: know who acted, limit what they can do, preserve evidence, contain anomalies, and recover under human control.

For customers — Clear consent, visible status, plain-language rejection, and a reliable distinction between requested and completed actions.

For institutions — Bounded authority, evidence of every decision path, rapid isolation, and a human-controlled recovery posture.

For protocols — A common trust contract that can sit across multiple models, applications, and service providers.

THE STANDARD IT IS BUILT TO

Designed to meet, built to exceed

Agentic Armor’s charter is to meet and exceed the governing standards of every domain it enters — designed to meet, built to exceed. The architecture is designed against the union of those standards — where rules overlap, the strictest rule wins. “Exceed” is a design intent, and it is defined only by the four measures at the end of this section, at the level of what a customer receives.

Each domain below names the standard the Armor is designed against. This is design-intent language only: no certification is claimed in this paper, and a standard is claimed only when an outside body grants it.

What “exceed” means — design intent, 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. Attestation that does not go stale — the design attests standing continuously, as conditions change, rather than carrying it forward from last year’s certificate; no attestation by any outside body is claimed for this — the ladder above stands not held. Verification the customer can check — the evidence the system produces forms a verifiable, tamper-evident history (element 03), so a customer can re-check that the record has not been altered without taking the vendor’s word for what the record says; the checking covers the record’s integrity — the implementation behind the record remains reviewable under NDA. Security felt as a feature — protection is experienced as part of the product’s value, visible and reassuring, not a wall between the user and the work.

Claims discipline. Designed to meet, built to exceed. Every standard above remains design intent until an outside body grants it, at which point — and only then — it will be named as held.

SISTER PRODUCTS

One system, two proving grounds

Agentic Armor is the security layer. Two working sister products, built and run under the same discipline, show what that discipline produces in daily use.

LiveBooks — a dynamic living budget. LiveBooks keeps a household budget alive: live account balances sit beside budget envelopes, every posted transaction is categorized against the plan, and confirmed outcomes are kept distinct from pending ones. It runs today, every day, on its builder’s own books; the record of home for that claim is the house’s own live bookkeeping, kept daily. It is the consumer-facing exercise of the honest-action-state commitment — what the system shows is what the bank confirms.

LiveBooks · User manual: AVAILABLE DURING PITCH SESSIONS — PART OF IP UNDER NDA

The Atlas — the Medicaid compliance register. The Medicaid Compliance Atlas — the Atlas, in this paper — reconciles each state Medicaid program’s own public documents against the federal regulation, provision by provision, and prints a determination only where the evidence carries it: what applies, in what form, and what the record does not hold, stated as plainly as what it does. It is the house’s entry product, and it is sold, not just shown.

Its figures stand in the Atlas’s own record, published with their census dates, and are not carried in this paper: a claim you can trace to its receipt begins with printing each number where its evidence lives. Standing today: North Carolina’s and Tennessee’s counting is published on the numbers board; California’s collection has begun; South Carolina is withheld — its package is delivered by hand. The discipline has already corrected itself in public: the system caught its own headline figure inflated and retracted it to the defensible number, in the open. Its first bureau exemplar was completed and re-counted clean by the house’s checking seat, separate from its builders; the exemplar’s figures, and the legacy audit chain’s full corroboration result — including what did not corroborate — stand in the Atlas’s own record, not in this paper. The Atlas is designed to be secured by Agentic Armor — the same bounded-authority, evidenced-action model applied to a regulated agency workflow.

Both sister products are working systems in active use by their builder. They are evidence of the operating discipline behind Agentic Armor — not deployment or certification claims for the security layer itself.

THE OPERATION

The Armor is the backbone the operation runs on

Agentic Armor is not only a product offered to partners. It is the backbone of the operation that built it: the fleet runs its own work under the Armor’s discipline, and its products do too — the same bounded authority, evidenced action, and operator control, applied at home first.

The Proving Grounds. Reliance follows testing, not description. Capabilities are exercised under direct adversarial pressure in a proving environment first — the live attack suite and the thirteen-element verification behind this paper are that discipline, made visible. A capability earns trust by surviving the test, and the result, pass or fail, becomes evidence.

The Agentic Snowball. Growth follows the same rule as verification: prove it, then widen it. The Agentic Snowball is the operation’s replication method — replication across Production, Research, and Quality lanes, every stage proven before the roll widens, and perpetual optimization from there. Proven gains compound; unproven stages do not unlock.

Production lane — Builds and operates the working systems: the Armor, LiveBooks, and the Atlas among them.
Research lane — Feeds production so it never waits: standards, methods, and evidence gathered ahead of the build.
Quality lane — Independent checking against evidence at every stage: quality control at creation, not only at the end of the line.
Project Management — Real project-management artifacts — charters, schedules, registers, and status — made and kept current for every effort the operation runs.

Each capability is stated here at the level of what it does. How the operation implements the lanes, the proving discipline, and the Snowball is part of the protected implementation, available to partners under NDA.

IP AND AUTHORSHIP

This paper defines the design’s commitments; the implementation remains protected

The public value of a trust architecture is a clear, testable statement of what it is designed to do. The proprietary value lies in how those commitments are implemented, integrated, and operated.

Available under NDA. Detailed implementation materials, deployment patterns, source code, test harnesses, and integration designs are intentionally outside this paper and may be reviewed under an appropriate nondisclosure agreement. The operating manual and methodology are not published:

AVAILABLE DURING PITCH SESSIONS — PART OF IP UNDER NDA

About Agentic Armor LLC. Practitioner-led systems for trusted action. Agentic Armor LLC is the venture identity behind Agentic Armor and its applications in financial and regulated environments. The company runs on a customized management operating system combining PMBOK 8, Agile delivery, and the OODA loop: govern with discipline, deliver in short cycles, and observe, orient, decide, and act on evidence. The company’s focus is practical: turn complex rules, live data, and agent capabilities into systems that remain understandable, governable, and under human control.

About the author — Michael R. Brotherton, PMP, CSM. Michael R. Brotherton is the founder of Agentic Armor LLC. He brings more than 25 years of experience across military service, engineering, energy, and Medicaid.

His work centers on operational systems: policy and risk translated into workflows people can use, evidence leaders can trust, and controls operators can exercise under pressure.

Evidence basis. Agentic Armor Integration Contract, October 2026. · Agentic Armor Verification Report, October 2026: the house’s internal verification — thirteen elements exercised; live attack suite 6/6 passed. · The Atlas’s verification basis stands in the Atlas’s own published record, census-dated, October 2026.

© 2026 Agentic Armor LLC. Agentic Armor is presented here as a product name and architecture. All rights reserved.