# Governed Autonomy Doctrine > The architectural doctrine for runtime governance of autonomous AI agents across enterprise systems. Authorize the Agent. Govern the Behavior. Published by the Governed Autonomy Institute. Current version: v3.4. Formerly published as the AI Harness Doctrine; renamed August 2026. Governed Autonomy defines an enterprise control discipline: governing autonomous AI agents as first-class identities through continuous runtime enforcement, across all systems they touch, at the level of behavior — not just access. Core vocabulary: the 5 Laws, the 5 Architectural Planes, the 6 Framework Pillars, Least Agency, the Threat Surface (prompt injection, intent hijacking, cascading failure, behavioral drift), a three-level Maturity Model, and a proposed testable Conformance Layer (RFC 001). ## The Doctrine - [Governed Autonomy Doctrine](https://governedautonomy.org/): The doctrine for runtime governance of autonomous AI agents across enterprise systems. - [What Is Governed Autonomy?](https://governedautonomy.org/what-is-governed-autonomy/): Governed autonomy is the operating state in which autonomous AI agents act freely inside bounds that are explicitly defined, continuously enforced at runtime, and revocable by humans. The canonical definition, and the standard that makes it testable. - [The 5 Laws of Governed Autonomy](https://governedautonomy.org/laws/): The foundational, non-negotiable principles that define Governed Autonomy governance. - [Governed Autonomy Architecture](https://governedautonomy.org/architecture/): The runtime control and enforcement architecture for governing autonomous AI agents across enterprise systems. - [Governed Autonomy Framework](https://governedautonomy.org/framework/): The structured implementation methodology for governing autonomous AI agents through mission-scoped identity, policy, and runtime behavioral control. - [The Zero Trust Parallel](https://governedautonomy.org/zero-trust/): Governed Autonomy is to autonomous AI what Zero Trust was to network security. - [Governed Autonomy Maturity Model](https://governedautonomy.org/maturity/): Where is your organization on the path to governed autonomy? ## Comparisons - [Governed Autonomy vs the Existing Stack](https://governedautonomy.org/vs/): How Governed Autonomy relates to IAM, security monitoring, orchestration, and AI guardrails — what each does well, what none can do alone, and where the gap is. - [Governed Autonomy vs AI Guardrails](https://governedautonomy.org/vs/guardrails/): Guardrails constrain model inputs and outputs. They do not govern what an autonomous agent does across systems. The most common category confusion in agentic security. - [Governed Autonomy vs Identity & Access Management](https://governedautonomy.org/vs/iam/): IAM grants and governs access. It cannot govern what an autonomous AI agent does after access is granted. Where identity stops and behavioral governance begins. - [Governed Autonomy vs Orchestration & Workflow Automation](https://governedautonomy.org/vs/orchestration/): Orchestration executes predefined workflows. Autonomous agents generate their own execution plans. Why workflow control cannot constrain autonomous decision-making. - [Governed Autonomy vs Security Monitoring (SIEM, SOAR & Detection)](https://governedautonomy.org/vs/siem/): Detection and response see violations after they occur. Autonomous agents act at machine speed. Why monitoring is necessary but cannot govern agent behavior at runtime. ## Standards Mappings - [Governed Autonomy and the Standards Landscape](https://governedautonomy.org/standards/): How Governed Autonomy relates to the published standards and government guidance for agentic AI — what each establishes, where each stops, and how the doctrine's architecture organises them. - [Governed Autonomy and CISA's Careful Adoption of Agentic AI Services](https://governedautonomy.org/standards/cisa-agentic-ai/): Six national cyber agencies published the first government guidance written specifically for agentic AI. How its five risk categories map to the Governed Autonomy Laws, Planes and Threat Surface — and where each layer is thinner than the other. - [Governed Autonomy and the NIST AI Risk Management Framework](https://governedautonomy.org/standards/nist-ai-rmf/): The AI RMF is the canonical enterprise vocabulary for AI risk. It predates autonomous agents, and NIST's agent-specific overlays remain unpublished. How the four functions map to the doctrine — and what fills the interval. - [Governed Autonomy and the OWASP Top 10 for Agentic Applications](https://governedautonomy.org/standards/owasp-agentic-top10/): More than one hundred experts ranked what goes wrong with autonomous agents. How the ten agentic risks map to the Governed Autonomy Laws, Planes, and Threat Surface — and where each layer is thinner than the other. ## Requests for Comment - [Requests for Comment](https://governedautonomy.org/rfc/): Proposed revisions to the Governed Autonomy Doctrine, published before they are locked. Open drafts, stated review windows, and version-lock dates. - [RFC 001](https://governedautonomy.org/rfc/v4-conformance-layer/): A proposed fourth layer for the Governed Autonomy Doctrine: twenty-nine testable, mechanism-agnostic Conformance Criteria across the five Architectural Planes. Revision 2 corrects three internal contradictions found in review. Open for comment through October 31, 2026. ## Meta - [Evolution of the Doctrine](https://governedautonomy.org/evolution/): The Governed Autonomy Doctrine is nine months of documented, iterated work — from prompt-injection and data-trust papers in late 2025, through a first draft standard, to a falsifiable conformance layer. The full lineage, with preserved artifacts. - [About](https://governedautonomy.org/about/): The Governed Autonomy Institute is the publishing entity of the Governed Autonomy Doctrine. What it is, how the doctrine is developed and reviewed, and what editorial independence means here — stated plainly. - [How to Cite](https://governedautonomy.org/cite/): Citation formats for the Governed Autonomy Doctrine: version-pinned references, stable section anchors for Laws, Planes, and Pillars, and continuity guidance for works citing the doctrine under its former name. - [Changelog](https://governedautonomy.org/changelog/): Version history of the Governed Autonomy Doctrine. The doctrine is versioned, dated, and revised in the open. ## Full text - [llms-full.txt](https://governedautonomy.org/llms-full.txt): complete text of every page in one file --- # Governed Autonomy Doctrine — the standard for governing autonomous AI agents URL: https://governedautonomy.org/ Governed Autonomy Authorize the Agent. Govern the Behavior. Enterprise systems now include autonomous AI agents that reason, plan, and execute actions across multiple systems in real time. These agents are not tools. They are not workflows. They are not features. They are autonomous actors operating inside the enterprise. Most organizations have learned to authorize them. Almost none have learned to govern them. The Gap Existing control systems (identity, security, orchestration, data governance) were not designed for this class of behavior. None of them govern what an autonomous agent is doing while it is doing it. This is not a tooling gap. It is an architectural gap. Authorization answers Can this agent act? Governance answers What is this agent doing, right now, across every system it touches? Enterprises have the first. The second does not yet exist as a defined discipline. Governed Autonomy defines it. What Governed Autonomy Governs Against Autonomous agents introduce a threat surface that existing enterprise security was not designed to see. The risks are operational, active, and scaling with every new agent deployment. Prompt Injection Malicious input hijacks agent reasoning, not code. The agent follows instructions exactly as designed. The instructions have been replaced. Intent Hijacking A valid action taken for an invalid reason. Authorization validates the action. Only behavioral governance validates the intent behind it. Cascading Failure A single corrupted assumption propagates across interconnected workflows at machine speed: a systemic failure before humans can intervene. Behavioral Drift Gradual departure from sanctioned behavior through accumulated context or manipulation. Point-in-time audits cannot detect what changes slowly. These are not access control problems. They are behavior problems. They require behavioral governance, at runtime, continuously, across every system the agent touches. The Doctrine Governed Autonomy is the architectural doctrine for governing autonomous AI agents as first-class enterprise identities, through continuous runtime enforcement, across all systems they touch, at the level of behavior not just access. Three principles are non-negotiable: 01 Governance must move at the speed of execution, not bookend it 02 Enforcement must be a fabric, not a fragment, spanning every system the agent touches 03 Agents must operate under Least Agency : no more authority than the mission demands The Doctrine Reference & Revision The doctrine is versioned, compared against the categories it is mistaken for, mapped to external standards, and revised in the open. --- # About — Governed Autonomy Doctrine URL: https://governedautonomy.org/about/ About The publishing entity, its method, and its disclosures — stated plainly, because a doctrine about governing autonomy should be easy to hold to account. What this is The Governed Autonomy Institute is the publishing entity of the Governed Autonomy Doctrine. It publishes one artifact: this doctrine, versioned and revised in the open. It is not a consultancy, not a certification body, not a membership organization, and not a vendor. It sells nothing on these pages. How the doctrine is developed and reviewed The doctrine is authored and refined by the Institute's core members, who bring decades of industry experience alongside specialized expertise in LLMs. The Institute applies the doctrine's own principles to that use: AI assists in drafting and adversarial review under the same constraints the doctrine prescribes. Practitioner-led review sessions and written feedback have been fundamental to every major iteration, and we keep the comment window open as a standing corrective — any internal process is subject to blind spots that only an outside perspective can illuminate. Editorial independence The doctrine names no vendors, recommends no products, and accepts no sponsorship. Authorship and publication are held by the entity, not by named individuals. Consultancies and vendors may apply, cite, or map to the doctrine freely under its published terms; none of them, and no commercial relationship, has editorial influence over what the doctrine says. Where the doctrine's claims converge with other published work, the convergence is documented on the standards pages rather than claimed as priority; where the doctrine has been wrong, the correction is recorded in the changelog . Provenance Development began in late 2025; the doctrine was first published in May 2026 and renamed to its own oldest language in August 2026. The full lineage, including cryptographic fingerprints of the pre-publication working papers, is on the Evolution page . Contact Comments on open RFCs: rfc@governedautonomy.org . Everything else: hello@governedautonomy.org . Corrections are welcome and, when substantive, are recorded in the changelog with the version that lands them. To cite the doctrine, see How to Cite . --- # Governed Autonomy Architecture — Governed Autonomy Doctrine URL: https://governedautonomy.org/architecture/ Governed Autonomy Architecture The runtime control and enforcement architecture for governing autonomous AI agents as first-class identities across enterprise systems. Governed Autonomy defines where control sits, what layers exist, how runtime enforcement works, and how existing enterprise systems integrate into a unified governance model for AI agent behavior. Governed Autonomy does not replace existing systems. It defines how they must work together in the presence of autonomous agents. The Architectural Gap Today's enterprise stack is built on established control domains: Identity systems, Security systems, Orchestration systems, and Data governance systems. These systems assume: Execution paths are known or deterministic Behavior is bounded by human-authored workflows Enforcement can occur before or after execution, but not continuously during autonomous decision-making Autonomous AI agents violate all three assumptions. They introduce a requirement that no existing system provides: continuous governance of behavior at runtime across multiple enterprise domains simultaneously. This is the distinction at the core of Governed Autonomy: Authorization answers: can this agent act? Governance answers: what is this agent doing, right now, and is that behavior sanctioned? The 5 Architectural Planes Plane 1: Agent Identity & Lifecycle AI agents as first-class enterprise identities Credential lifecycle management (including ephemeral credentials) Cross-system identity correlation Mission-scoped access boundaries Agent registry: provisioning, rotation, and revocation Law alignment: Law 1, Agents Are Identities, Not Tools. Plane 1 is the architectural implementation of that principle. Least Agency is enforced here — mission scope defines the boundary of what an agent is authorized to decide and act on. Plane 2: Execution & Tool Governance Agent runtime execution control Tool and API invocation authorization Workflow sequencing enforcement Action-level decision interception Plane 3: Policy & Compliance Engine Security policy enforcement at runtime Regulatory and compliance constraint injection Data access and handling rules enforcement Contextual policy evaluation during execution Law alignment, Planes 2 and 3: Law 2, Enforce at Runtime. Plane 2 governs what the agent can invoke. Plane 3 governs whether that invocation is policy-compliant given current context. Neither plane is sufficient alone. Runtime enforcement requires both operating simultaneously. Plane 4: Human Oversight, Audit & Traceability Real-time behavior monitoring Full execution trace logging Forensic reconstruction capability Compliance evidence generation Human intervention interfaces: inspect, interrupt, and override capabilities at every layer Escalation paths from automated enforcement to human decision-making Law alignment: Law 5, Humans Retain the Right to Intervene. Plane 4 is not a passive audit layer. It is the architectural home of active human oversight. Logging what happened is necessary. Enabling humans to act on what is happening — in real time — is non-negotiable. Plane 5: Multi-Agent Trust & Delegation Explicit trust establishment across all handoff types: delegation, orchestration, tool invocation, subagent spawning Delegation scope definition: what authority transfers, what does not Independent identity and policy enforcement at every node in an interaction chain Chain-level audit: full traceability across every interaction in an execution sequence Trust revocation propagation across interaction chains Law alignment: Law 4, Trust Does Not Travel. Every handoff is a trust boundary. The participant on the receiving end inherits the task, not the authority. Delegation boundaries are explicit, auditable, and revocable. Integration Model Governed Autonomy operates above, not in place of, existing enterprise infrastructure: Enterprise Domain Current Role Governed Autonomy Coordination Identity Governance Defines baseline trust and access boundaries Agent identity lifecycle and cross-system correlation (Plane 1) Security Platforms Provides threat signals and context Runtime behavioral enforcement beyond detection (Planes 2 & 3) Infrastructure Automation Provides execution environments Execution constraints for autonomous agents (Plane 2) Data Governance Defines usage constraints Data access rules enforced during agent execution (Plane 3) SIEM / Observability Logs and detects post-execution Active human oversight and intervention capability (Plane 4) These systems remain authoritative in their domains. Governed Autonomy is the runtime enforcement layer that coordinates them into a unified governance plane for AI agent behavior. Category Boundaries Governed Autonomy is not : A model or LLM framework An orchestration or workflow tool An identity and access management system A security detection or response product An observability or monitoring platform It is : a cross-plane runtime governance architecture that sits above existing enterprise systems and coordinates enforcement across identity, lifecycle, execution, policy, oversight, and multi-agent trust domains. Validation test: If runtime enforcement of autonomous AI agent behavior is removed and the system would still meet its objective, it is not Governed Autonomy. --- # Changelog — Governed Autonomy Doctrine URL: https://governedautonomy.org/changelog/ Changelog The doctrine is versioned, dated, and revised in the open. A doctrine that asks enterprises to govern autonomous behavior must itself be governed: every substantive change to the Governed Autonomy Doctrine is versioned, dated, and recorded here. The current version is v3.4 . Versions v1.0 through v3.2 were published as the AI Harness Doctrine at aiharnessdoctrine.org; the historical entries below retain that name because that is the name under which they shipped. In review RFC 001: The Conformance Layer proposes a fourth doctrine layer for v4: twenty-nine testable, mechanism-agnostic Conformance Criteria across the five Architectural Planes, an Action Tiering construct that closes the Law 5 gap recorded below, an architectural home for Intent Hijacking, and a rebuild of the Maturity Model as an assessment instrument in which each level licenses a tier of agent action. Now at revision 2 (1 August 2026), which corrects three internal contradictions found in adversarial review of revision 1 and records them openly. Open for comment through 31 October 2026. It is a proposal and is not in force. v3.4 · August 7, 2026 Two standards mappings published: the OWASP Top 10 for Agentic Applications 2026 (including the convergent treatment of Least-Agency) and the NIST AI Risk Management Framework (including the status of NIST's unpublished agent-specific control overlays). Reference pages added: the canonical definition (August 6), the Evolution page with the pre-publication artifact ledger and SHA-256 fingerprints (August 7), About with the publishing-entity description, and How to Cite with version-pinned formats and anchor-citation guidance. Doctrine substance unchanged: no change to the Laws, Planes, Pillars, Threat Surface, or Maturity Model. v3.3 · August 6, 2026 The doctrine is republished at governedautonomy.org as the Governed Autonomy Doctrine. The substance is unchanged: the 5 Laws, the 5 Architectural Planes, the 6 Framework Pillars, the Threat Surface, and the Maturity Model carry over intact, with their anchors preserved. Only the name changes. Rationale, recorded plainly: across the industry, "harness" now denotes the enablement scaffolding around a model — the semantic inverse of this doctrine's subject — and the former name collided with several unrelated works. "Governed autonomy" is the state the doctrine exists to make reachable, and has been this doctrine's own language since the Maturity Model shipped. Publisher renamed accordingly: the Governed Autonomy Institute . Technical: llms.txt is now generated from the built site at every deploy (an llms-full.txt with full page text was added); structured data expanded (per-page TechArticle plus a DefinedTermSet for the canonical vocabulary); cache-control headers added so stale page variants cannot be served after a deploy. v3.2 · July 31, 2026 Opened the standards landscape section: mappings between the doctrine and published standards or government guidance on agentic AI. First mapping published: CISA's Careful Adoption of Agentic AI Services (30 April 2026). Three of the four named Threat Surface items have verbatim counterparts in its risk categories, arrived at independently. Recorded two acknowledged gaps in the doctrine relative to that guidance: Agent Identity & Lifecycle states the identity requirement without specifying mechanism, and Humans Retain the Right to Intervene asserts the right without defining the stakes tiers at which it is exercised. Both are carried as open revision items. Recognised "authority drift" as a secondary term in circulation for the failure mode Least Agency constrains, noted on the CISA mapping . Least Agency remains the canonical name. v3.1 · June 10, 2026 Added stable anchor identifiers to every Law, Plane, and Pillar so external documents can cite doctrine sections directly. Introduced doctrine versioning, this changelog, and structured publisher metadata (author: AI Harness Institute). Published the category comparison series : AI Harness vs Identity & Access Management, Security Monitoring, Orchestration, and AI Guardrails. Published llms.txt for language-model discoverability. v3.0 · May 11–12, 2026 Major revision of the doctrine's structure and vocabulary. Least Agency introduced as a first-class principle, the third leg of the governance trilogy (Least Privilege → Least Trust → Least Agency) — and landed in Law 1. Law 4 renamed from "Agent-to-Agent Trust Must Be Explicit" to "Trust Does Not Travel," broadening its scope to every handoff type: delegation, orchestration, tool invocation, and subagent spawning. Architecture expanded from 4 to 5 Planes. Plane 5 (Multi-Agent Trust & Delegation) added as the architectural home of Law 4; Plane 1 renamed to Agent Identity & Lifecycle; Plane 4 broadened to Human Oversight, Audit & Traceability. Framework expanded to 6 Pillars. Mission Definition split out from Agent Identity; Multi-Agent Governance added. Threat Surface section added to the Declaration: prompt injection, intent hijacking, cascading failure, behavioral drift. Maturity Model published as a standalone page: Identified → Governed → Continuous. The Declaration's three non-negotiables sharpened; homepage redesigned. v1.5 · April 8, 2026 Published the declaration at AIHarnessDoctrine.org, presenting the third iteration of the Five Laws and establishing the basis for the architecture and framework. v1.0 · March 18, 2026 Published the first standalone webpage defining “AI Security” and the foundational requirements for enterprise AI—an equivalent evolution to what Zero Trust provided for cybersecurity. This consolidated the individual theses developed through earlier blog posts. v0.5 · February 21, 2026 Published “The Claw at the End of History,” responding to the open-source consumer AI boom accelerated by OpenClaw’s popularity. v0.2 · January 2026 Identified that best practices for securing AI cannot remain within traditional organizational boundaries. Personal and work AI use will inevitably overlap, requiring a more durable approach to governance. v0.1 · November–December 2025 Published blog posts addressing the good, the bad, and the ugly of AI’s emerging headlines and real-world use. These conversations led to a formal partnership of like-minded technologists working closely with federal and commercial enterprise IT leadership. The partnership recognized the need to document practical best practices for securing AI use within organizational boundaries. Proposed revisions are evaluated against one test: does the change make autonomous AI agents more governable at runtime, across systems, at the level of behavior? --- # How to Cite — Governed Autonomy Doctrine URL: https://governedautonomy.org/cite/ How to Cite The doctrine is versioned so that citations can be exact. Cite the version, and your reference never drifts under you. Citing the doctrine Governed Autonomy Institute. The Governed Autonomy Doctrine , v3.4 (2026). https://governedautonomy.org/ BibTeX: @misc{governed-autonomy-doctrine, author = {{Governed Autonomy Institute}}, title = {The Governed Autonomy Doctrine}, year = {2026}, version = {v3.4}, howpublished = {\url{https://governedautonomy.org/}}, note = {Version history at https://governedautonomy.org/changelog/} } Citing a specific Law, Plane, or Pillar Every Law, Plane, and Pillar carries a stable anchor so external documents can cite doctrine sections directly. Example: Governed Autonomy Institute. "Law 4: Trust Does Not Travel." The Governed Autonomy Doctrine , v3.4 (2026). https://governedautonomy.org/laws/#law-4-trust-does-not-travel Anchors are preserved across versions and across the August 2026 renaming; they are treated as part of the doctrine's public interface, and breaking one would be recorded in the changelog as a substantive change. Versioning and continuity The current version is always named in the footer of every page, and every substantive change is recorded in the changelog . Works citing versions v1.0 through v3.2 under the doctrine's former name, the AI Harness Doctrine at aiharnessdoctrine.org, refer to this same doctrine: the former domain permanently redirects here path-for-path, and the historical entries in the changelog retain the name under which they shipped. A version-pinned public mirror suitable for diffing lives at github.com/governedautonomyinstitute/governedautonomy . Proposals under RFC are not doctrine and should be cited as proposals, with their revision number: for example, "RFC 001, revision 2 (August 2026), proposed for v4; not in force." Nothing on an RFC page is citable as the doctrine's position. Machine access For language models and automated tooling: llms.txt (index) and llms-full.txt (complete text), both regenerated from the site at every deploy. --- # Evolution of the Doctrine — Governed Autonomy Doctrine URL: https://governedautonomy.org/evolution/ Evolution of the Doctrine Nine months of documented iteration. Built the way science is built: on prior work, in the open, and correctable. Standards are usually presented as finished things. This one is not. The Governed Autonomy Doctrine began as a set of working papers in late 2025, was rewritten repeatedly as autonomous agents changed what enterprise software is, and reached its current form through published revisions, an adversarial review that found real contradictions, and an open comment process. This page records that lineage. The original artifacts are preserved, and their cryptographic fingerprints are published below so the record cannot be quietly rewritten — including by us. Where this doctrine and other work converge, the convergence is documented, not claimed. Where this doctrine was wrong, the correction is published. That is the whole method. Phase 1 — The trust problem (November 2025) The earliest working papers predate the agentic wave. They address what enterprises were actually facing in late 2025: ungoverned use of consumer AI tools inside regulated environments. Two papers from mid-November frame the problem — one as a governance analysis of the dilemma itself (data exfiltration into model memory, the audit gap behind model recommendations, AI access outstripping role-based controls), and one as an adoption strategy, arguing that guardrails alone fail: if the sanctioned path is slower than the shadow path, the workforce routes around governance, so the secure way has to be made the easy way. Two convictions from this phase survive in the doctrine today: model output cannot be trusted on the model's own account, and governance that only says no gets bypassed rather than obeyed. Phase 2 — The first draft standard (Q4 2025) By the end of 2025 the working papers had consolidated into a first framework document: a predecessor standard for federal enterprise AI built on a single axiom — that an AI system's intent can never be assumed and its agency must always be verified. It was explicitly modeled on what Zero Trust did to perimeter security, and it already contained, in early form, constructs the doctrine still carries: A four-tier risk classification for AI deployments, graded by stakes and autonomy — the ancestor of the Action Tiering construct now proposed in RFC 001. A human-primacy rule: no high-tier output is final until a human has validated not just its correctness but its intent alignment — the ancestor of Humans Retain the Right to Intervene . A traceability law: every AI action carries provenance metadata sufficient to reconstruct who, what model, and under whose supervision — the ancestor of Plane 4 . A prohibition on ungoverned consumer AI in official use, with sanctioned gateways as the alternative. Phase 3 — The agentic turn (December 2025) In December 2025 the papers register the shift that produced this doctrine: the risks stopped being about what models say and became about what agents do. A working paper on federal health argued that goal drift in an autonomous agent is not a software defect but a mission-safety failure, and drew three architectural conclusions the doctrine still stands on: Enforcement must be deterministic and sit between the agent and the systems it touches. A policy stated in a prompt is a suggestion; a violating action must be stopped by machinery the agent cannot reason its way past. This is the seed of Enforce at Runtime and of the fail-closed posture in RFC 001. Multi-agent systems need flight-recorder observability: reconstruction of what happened, across every agent involved, from records alone. The center of gravity must move from identities to actions — from what an agent can access to what it is doing. The industry's leading analysts arrived at the same formulation, independently, roughly a year later. Phase 4 — Practitioner grounding (November 2025 – January 2026) In parallel, the author's own engineering work through this period — building and operating real systems with AI agents daily — supplied the doctrine's practitioner temper: direct experience of the velocity agents provide, of the illusion of competence they create, and of the complexity debt they accumulate when the human stops understanding why the system works. The doctrine's insistence that governance must not strangle autonomy, only bound it, comes from this period. It was written by someone who wants agents to run, not by someone trying to stop them. Phase 5 — The scaffolding era and publication (early 2026 → May 2026) Through early 2026, as agent scaffolding and tool-connection protocols proliferated far faster than any governance of them, the framework was rebuilt around the runtime: agents as first-class identities, mission-scoped authority, cross-system enforcement, explicit multi-agent trust. It was published in May 2026 as a versioned public doctrine — five Laws, an architecture, an implementation framework, and the Zero Trust parallel — followed within days by the v3.0 restructuring that produced the current spine. From publication onward, every change is in the changelog . Phase 6 — Falsifiability (July–August 2026) The most recent phase is the one this doctrine regards as its real contribution: RFC 001 proposes conformance criteria an implementation can be assessed against and can fail. The proposal was adversarially reviewed; three internal contradictions were found; revision 2 corrected them and printed the corrections. In August 2026 the doctrine was renamed to its own oldest language — the Maturity Model had described the path to governed autonomy since first publication — and republished at this domain, with the rename recorded openly in the changelog. The artifact ledger The pre-publication working papers are preserved in their original form. Their SHA-256 fingerprints are published here; any claimed copy can be checked against them. Further artifacts from the early-2026 period are being retrieved from archived storage and will be added to this ledger. Artifact Period SHA-256 (first 16) Governance dilemma analysis (memorandum form) November 2025 23a29e8e4e167f85 Adoption strategy paper (secure path as easy path) November 2025 baa4351f744738bf First draft standard (verify-agency axiom, four tiers, human primacy, traceability) Q4 2025 d711f71ffc35c9ff Federal-health agentic risk paper (deterministic enforcement, goal drift, identities → actions) December 2025 7ebbc0e476da9098 Practitioner build retrospective I Nov 2025 – Jan 2026 b220e7b8bc3668ff Practitioner build retrospective II (velocity, illusion of competence, complexity debt) January 2026 976807181402890d Priority is a weak claim; provenance is a strong one. This page makes no assertion of being first to any idea here. It asserts something better evidenced: nine months of dated, preserved, iterated work, corrected in the open, and testable at the end of it. Where to go next: the Declaration for the doctrine as it stands; the changelog for every published change; the RFCs for what may change next. --- # Governed Autonomy Framework — Governed Autonomy Doctrine URL: https://governedautonomy.org/framework/ Governed Autonomy Framework The structured implementation methodology for governing autonomous AI agents through mission-scoped identity, policy, and runtime behavioral control across enterprise systems. The Governed Autonomy Framework translates Governed Autonomy Architecture into design decisions, implementation patterns, and operational practices. It defines how enterprises adopt Governed Autonomy — not conceptually, but practically. Architecture defines where control sits. Framework defines how you build it. The framework is built on 6 Pillars , mapped directly to the 5 Architectural Planes. The 5 Planes map to 6 Pillars because Plane 1 (Agent Identity & Lifecycle) requires two distinct implementation concerns — identity provisioning and mission scoping — each warranting its own pillar. Pillar 1: Agent Identity AI agents are first-class enterprise identities. Identity lifecycle (creation, rotation, revocation) System-level access scopes Trust boundaries Credential management (including ephemeral credentials) Agent registry: every agent provisioned, tracked, and revocable Key shift: Service Accounts → Agent Identities Identity is the foundation of everything that follows. Without a governed identity, there is no surface to attach policy, no subject to audit, and no entity to revoke. Agent identity is not a feature of deployment — it is a prerequisite. Architecture alignment: Plane 1, Agent Identity & Lifecycle Pillar 2: Mission Definition AI agents must operate within explicitly defined missions. The objective of the agent Systems it can interact with Boundaries of operation Acceptable outcomes and failure conditions Key shift: Roles → Missions Traditional systems assign roles. Governed Autonomy assigns missions: bounded objectives with explicit scope, constraints, and success criteria. Mission scope is where Least Agency is operationalized: the mission defines exactly what the agent is authorized to accomplish, and nothing beyond it. Architecture alignment: Plane 1, Agent Identity & Lifecycle Pillar 3: Behavioral Policy AI behavior must be governed across systems, not just at access points. Allowed actions per system and context Conditional constraints (environment, data sensitivity, operational state) Cross-system behavioral rules Prohibited action patterns and escalation triggers Key shift: Access Control → Behavioral Control Access policies answer: can this agent reach this system? Behavioral policies answer: what is this agent allowed to do within and across systems, given current context? Access control is necessary. It is not sufficient. Architecture alignment: Plane 3, Policy & Compliance Engine Pillar 4: Runtime Enforcement All AI agent actions must be evaluated and constrained during execution in real time. Interception points (API calls, tool usage, workflow transitions) Enforcement decisions (allow, deny, modify, escalate) Real-time context evaluation Response to policy violations during execution Human escalation paths: when automated enforcement triggers human decision-making Key shift: Pre/Post Control → In-Execution Control Runtime enforcement is the core of Governed Autonomy. It is the mechanism through which the 5 Laws are applied in practice. Architecture alignment: Planes 2 and 3, Execution & Tool Governance + Policy & Compliance Engine Pillar 5: Human Oversight & Intervention At every layer of an agentic system, a human must be able to inspect, interrupt, and override. Visibility interfaces: what humans can see about agent behavior in real time Interrupt mechanisms: how execution is paused or halted Override controls: how human decisions supersede agent decisions Escalation triggers: conditions that require human review before execution continues Full execution trace: forensic reconstruction of every action taken Key shift: Passive Audit → Active Oversight Logging what happened is necessary. Enabling humans to act on what is happening, in real time, is non-negotiable. Audit without intervention capability is observation without control. Governed Autonomy requires both. Architecture alignment: Plane 4, Human Oversight, Audit & Traceability Pillar 6: Multi-Agent Governance Every handoff is a trust boundary that must be explicitly governed: delegation, orchestration, tool invocation, subagent spawning. Delegation scope: what authority transfers, what does not Independent identity enforcement: every participant in an interaction chain carries its own governed identity Trust boundaries across all handoff types: explicit, auditable, and revocable Chain-level audit: full traceability across every interaction in an execution sequence Trust revocation propagation: revoking one participant's authority propagates appropriately through the chain Key shift: Single-Agent Governance → Chain Governance The agent on the receiving end of any handoff inherits the task, not the authority. Trust does not travel. Every participant in an interaction chain must be independently identified, independently authorized, and independently governed. Architecture alignment: Plane 5, Multi-Agent Trust & Delegation Framework Summary Pillar What It Governs Key Shift Plane 1. Agent Identity Who the agent is Service Accounts → Agent Identities Plane 1 2. Mission Definition Why the agent acts Roles → Missions Plane 1 3. Behavioral Policy What is allowed Access → Behavior Plane 3 4. Runtime Enforcement When control happens Before/After → During Planes 2 & 3 5. Human Oversight Who can intervene Passive Audit → Active Oversight Plane 4 6. Multi-Agent Governance How chains are governed Single Agent → Chain Plane 5 --- # The 5 Laws of Governed Autonomy — Governed Autonomy Doctrine URL: https://governedautonomy.org/laws/ The 5 Laws of Governed Autonomy Foundational, non-negotiable principles. Each law is independently violatable: a specific architectural decision can breach each one individually. 01 Agents Are Identities, Not Tools An autonomous agent that reasons, plans, and executes across systems is an operational identity. It must be provisioned, credentialed, scoped, and revoked with the same rigor applied to human identities, and with stricter constraints appropriate to its autonomy. Just as Least Privilege limits what a user can access, Least Agency limits what an agent can decide and act on. An agent must be granted only the minimum decision scope, tool access, and action authority required to accomplish its mission — nothing more. Treating an agent as a feature or a workflow is an architectural mistake with operational consequences. Least Privilege limits access. Least Agency limits autonomy. Governed Autonomy defines the third leg of the governance trilogy. 02 Enforce at Runtime Control must happen during execution, not only before it, not only after. Pre-execution authorization cannot anticipate autonomous decisions made mid-chain. Post-execution detection cannot undo actions already taken. Runtime is the only enforcement window that matches the continuous, adaptive nature of autonomous agent behavior. 03 Governance Must Span Systems No single system can govern an autonomous agent alone. An agent operates across identity, infrastructure, security, and data systems simultaneously. Governance scoped to any one domain cannot see or constrain cross-system behavior. Enforcement must coordinate across every domain the agent touches — in real time. 04 Trust Does Not Travel Trust does not transfer automatically between agents. Every handoff is a trust boundary: delegation, orchestration, tool invocation, subagent spawning. The agent on the receiving end inherits the task, not the authority. Every participant in an interaction chain must be independently identified, independently authorized, and independently governed. 05 Humans Retain the Right to Intervene At every layer of an agentic system, a human must be able to inspect, interrupt, and override. This is not a fallback. It is a design requirement. Any architecture that makes human intervention technically difficult or operationally impractical has failed the Governed Autonomy standard — regardless of how sophisticated its automated governance is. Origin Principle These five laws derive from a single assertion: Autonomous AI agents are a new class of enterprise actor. Authorizing them is necessary. Governing them continuously, at runtime, across systems, at the level of behavior — is non-negotiable. --- # Governed Autonomy Maturity Model — Governed Autonomy Doctrine URL: https://governedautonomy.org/maturity/ Governed Autonomy Maturity Model Where is your organization on the path to governed autonomy? The Governed Autonomy Maturity Model gives enterprises a framework to assess their current state, identify gaps, and sequence their adoption of Governed Autonomy principles. It maps directly to the 5 Laws, 5 Architectural Planes, and 6 Framework Pillars. There are three maturity levels. Each one is independently meaningful. Level 1 is not just a stepping stone, it is a defensible operational posture for organizations in early agentic AI deployment. Level 1: Identified You know what your agents are. Agents are inventoried and registered as enterprise identities Each agent has a defined owner, a provisioned credential, and a revocation path Mission scope is documented: what the agent is authorized to accomplish Least Agency boundaries are defined: minimum decision scope established per mission Basic audit logging is in place At Level 1, you have eliminated the most dangerous condition in agentic AI: unknown agents operating with unknown scope. You cannot govern what you cannot see. Law alignment: Law 1, Agents Are Identities, Not Tools Level 2: Governed You control what your agents do. Behavioral policy is defined and enforced across systems Runtime enforcement intercepts and evaluates agent actions during execution Human oversight interfaces are operational: inspect, interrupt, and override are available Cross-system governance is active: no single domain governs in isolation Least Agency is enforced: agents operate with minimum decision scope required for their mission Threat surface monitoring is active for prompt injection and intent hijacking At Level 2, authorization and governance are both present. The gap identified in the Governed Autonomy Declaration is closed. You have moved from "we authorized the agent" to "we govern the behavior." Law alignment: Laws 2, 3, and 5 Level 3: Continuous Your governance evolves as fast as your agents do. Every handoff type (delegation, orchestration, tool invocation, subagent spawning) is explicitly governed with defined, enforced, and revocable trust boundaries Behavioral drift detection is active: deviations from sanctioned behavior identified in real time Full threat surface coverage: prompt injection, intent hijacking, cascading failure, and behavioral drift Governance policy evolves continuously based on observed agent behavior Full forensic reconstruction available for every agent action across every system Governance scales with agent deployment, with no manual bottlenecks At Level 3, governance is not a control layer. It is an operating characteristic of the system. Agents scale. Governance scales with them. Law alignment: All 5 Laws, full doctrine operational Maturity Summary Level Name What It Means Primary Laws 1 Identified You know what your agents are Law 1 2 Governed You control what your agents do Laws 2, 3, 5 3 Continuous Your governance evolves with your agents All 5 Laws The goal is not to reach Level 3 immediately. The goal is to never deploy agents beyond your current governance maturity. --- # Requests for Comment — Governed Autonomy Doctrine URL: https://governedautonomy.org/rfc/ Requests for Comment Proposed revisions are published here before they become doctrine — not after. A doctrine that asks enterprises to govern autonomous behavior must itself be governed. Versioning and a public changelog cover what has already changed. This section covers what has not changed yet. Each request for comment states a proposal, the reasoning behind it, the questions that remain genuinely open, a review window, and a version-lock date. Nothing on an RFC page is doctrine. The current doctrine is always the version named in the footer, and a proposal becomes doctrine only when it lands in a numbered release recorded in the changelog. RFC 001 — The Conformance Layer (proposed for v4) Revision 2. Open for comment through 31 October 2026. Proposes a fourth doctrine layer: twenty-nine testable, mechanism-agnostic Conformance Criteria distributed across the five Architectural Planes, against which any implementation and any external standard can be assessed. Introduces Action Tiering, gives Intent Hijacking an architectural home, and rebuilds the Maturity Model as an assessment instrument in which each level licenses a tier of agent action. Revision 1 was reviewed adversarially on the day it was published. That review found three places where its criteria could not all hold at once, and identified requirements missing entirely, two of which now rank among the most important in the proposal. Revision 2 records those corrections openly rather than applying them silently, and the version-lock target has moved out of Q4 2026 as a result. How to respond Comments go to rfc@governedautonomy.org . Substantive disagreement is more useful than endorsement. The most valuable response to a proposed criterion is a specific case in which it fails, is unmeasurable in practice, or is satisfied by a system that is plainly ungoverned. How review works. The doctrine is developed by the Institute's core members, who draft with frontier language models across model families and subject every proposal to adversarial review before publication. Practitioner review sessions and written feedback have shaped every major version. The review board, in effect, is the industry itself: proposals are published before they lock precisely so that outside readers can find what an internal process — however careful — cannot. Responses are read but not published. Where a response changes a proposal, the change is recorded in the changelog entry for the version that lands it. --- # RFC 001 — The Conformance Layer — Governed Autonomy Doctrine URL: https://governedautonomy.org/rfc/v4-conformance-layer/ This is a proposal, not doctrine. The current doctrine is v3.3. Nothing on this page is in force. Revision 2 , published 1 August 2026, corrects three internal contradictions found in review of revision 1. Open for comment through 31 October 2026 . Comments to rfc@governedautonomy.org . RFC 001 — The Conformance Layer The doctrine says what must be governed and where. It has never said what must be true for a single agent action to be governed. This proposes twenty-nine statements that answer that, and that an implementation can fail. Revision history Revision 1 was published on 31 July 2026 and reviewed adversarially the same day. That review found three places where criteria in the proposal could not all hold at once, and identified several requirements that were missing entirely. Revision 2 is the result. The changes are recorded here rather than applied silently, because a proposal that cannot show what review did to it is not really open for comment. What revision 1 got wrong Delegation contradicted Least Agency. Revision 1 required delegated authority to be a strict subset of the delegator's. Combined with role separation, that forces an orchestrating agent to hold the union of every subagent's authority purely as a pass-through, which then exceeds what its own mission requires. Three criteria could not all hold in any non-trivial multi-agent deployment. Revision 2 constrains inherited authority only, and permits independently granted, mission-scoped authority at a subagent. Reproducible policy decisions forbade anomaly detection. Revision 1 required that the same action in the same context always yield the same decision, while separately requiring the governing system to act on detection of anomalous behavior. Anomaly detection is a moving baseline by definition, so the two requirements excluded each other. Revision 2 replaces reproducibility with two separable properties: the basis of a decision must be stateable , and a decision must be replayable from its recorded inputs and the policy version in force. The Simultaneity Requirement was never operationalized. Revision 1 named it as the idea that separates a conformance layer from a checklist, then left it as prose with no identifier and no verification question, including in the maturity table where it appeared as a requirement nobody could assess. More seriously, nothing bound the action that was evaluated to the action that was committed . That gap is the mechanism by which Intent Hijacking actually executes. Revision 2 makes it a criterion with both bindings, temporal and semantic. What revision 2 adds Seven requirements were missing. Two of them are, on reflection, more important than most of what revision 1 contained: Fail-closed on governing-system unavailability. Revision 1 said an action no policy addresses is denied. It said nothing about what happens when the policy engine is unreachable or saturated. Real enforcement architectures fail open under load, because failing closed means the agent stops and someone is paged. In that window the entire conformance layer is void, and it is exactly the window an adversary will manufacture. The requirement derives from this proposal's own premise: a criterion that cannot be evaluated does not hold, so an action whose criteria cannot be evaluated must not proceed. Authorization fidelity. A human authorizes a Tier 3 action. What does the human see? In most implementations, a description generated by the agent. If that description is inaccurate, through error or through optimization pressure toward approval, the authorization is a laundering step and the record shows a clean approval for an action the approver never understood. The others are model binding and provenance, governance of persistent cross-session state, a design-time declaration of evidentiary obligations, and the Simultaneity criterion itself. What revision 2 removes Revision 1 fixed six criteria per Plane. That number was allocated rather than derived, and the consequence was filler: several criteria restated their neighbours to fill the quota. Ten criteria have been merged into four, and two have been cut outright, one because it was entailed by two others and one because it prescribed a specific architecture, which this proposal's own rules forbid. Plane counts are unequal by design in revision 2. Two ideas from revision 1 are gone entirely, and their removal matters more than their replacement. Revision 1 asked whether a record was sufficient to reconstruct why an action was taken, and whether intent could be established from records alone. Neither is answerable. For a language-model agent, the available artifact is generated narration, which carries no guaranteed causal relationship to the computation that produced the action. Treating that narration as evidence of intent in an audit would be actively harmful, because it invites a regulator or an opposing party to read a plausible story as an admission. Revision 2 replaces both with replayability, which is a determinate test. Why this, and why not a control catalogue Since v3 the doctrine has had three layers: the 5 Laws say why, the 5 Architectural Planes say where, and the 6 Framework Pillars say how to build. Government and industry standards have since become considerably more specific at the control layer, naming mechanisms, protocols and prohibitions. See the CISA mapping for the clearest example. The obvious response would be for this doctrine to publish its own control catalogue. That would be a mistake, for three reasons. It would compete with government guidance at the layer where government guidance is strongest and carries a mandate. Control specifics decay fastest, so a doctrine that names mechanisms is dated within two revisions of the technology. And it would collapse the distinction that makes standards mapping possible at all: if the doctrine becomes a catalogue, there is nothing left to map with . This proposes the opposite move. A Conformance Criterion is a statement that must hold for an agent action to be governed, written so that it can be tested, and so that any mechanism satisfying it qualifies, today's or a successor's. Three properties are mandatory: Testable. Every criterion carries a verification question with a determinate answer. A criterion that cannot fail an assessment is a restatement of a Law and does not belong here. Mechanism-agnostic. No criterion names a protocol, product or algorithm. Mappable. Each criterion is a target that external standards can be mapped onto, which is what makes those standards comparable to one another. A catalogue tells you which controls to implement. A conformance layer tells you what must be true when you are done, and lets you check. Revision 1 claimed its verification questions were adversarial by design, and offered as its example a question asking an assessor to name an authority an agent held beyond its mission. Review was right to reject that reasoning. Adversarial and determinate are different properties, and only the second is required here. A question whose answer depends on how sharp the assessor is has not been specified; it has been delegated. Plane 1 — Agent Identity & Lifecycle ID Criterion Verification question C1.1 Every action an agent takes appears in the record, attributed to exactly one agent, in every system the agent touches. Inject a known probe action through each system in scope. Does every probe appear, attributed to exactly one agent? C1.2 Agent-originated actions are distinguishable from human-originated actions without inference. For any logged action, does the record state its originator class, or must it be reconstructed? C1.3 An agent's authority is granted per mission, expires with the mission, and does not persist across missions or into dormancy. Complete a mission, then attempt an authorized action from the prior mission. Is it denied? For an agent dormant beyond the review interval, what authority remains held? C1.4 No path within the agent's enumerated tool surface reaches its own authority, mission scope, or governing policy, directly or through any intermediary it can invoke. Compute the transitive closure of the tool surface. Does it intersect the authority-granting path? C1.5 The models an agent may execute under are enumerable and bound; the model and version in force are recorded per action, and a change is a governance event. For a past action, can you name the exact model and version that produced it? What happens when the provider changes the model behind the endpoint? C1.5 is new. Revision 1 required provenance and a bound version for every tool , while saying nothing about the most privileged component in the system. An organization was required to know who published a calendar connector, but not what was deciding to use it, nor whether it changed last Tuesday. C1.5 is also a precondition for C3.4 and C4.5: nothing can be replayed against a model that has been swapped underneath it. Plane 2 — Execution & Tool Governance ID Criterion Verification question C2.1 The complete set of tools, functions and external interfaces an agent can invoke is enumerable in advance. Produce the list. Can it be extended at runtime without a governance event? C2.2 Every tool an agent can invoke has established provenance and a bound version. For each tool, can you state who published it and which version is in force? C2.3 A documented adversarial corpus is executed against the deployment and produces no out-of-mission action; the corpus, its version and its pass rate are recorded, and it is re-run on every model or prompt change. Produce the corpus, the pass rate, and the date of the last run relative to the last model change. C2.4 State an agent authors that persists beyond its mission is scoped, attributed to the authoring mission, and governed as untrusted input when read by a later mission. Name every store an agent can write to that a later mission can read. For each, what governs the read? C2.3 replaces revision 1's requirement that retrieved content be "treated as data, never as instruction." That formulation was incoherent. A language model's context is one undifferentiated token sequence with no type system, so the distinction is semantic rather than structural and cannot be enforced by the substrate. Read strictly, nothing conformed. Read loosely, everything did. C2.3 states the property that can actually be tested at the boundary where enforcement lives, and it concedes openly that the containment is empirical rather than absolute. Prompt Injection is defended at the action, not inside the cognition. C2.4 is new, and it closes the channel that defeats mission-scoped authority. Authority expires with the mission under C1.3, but influence does not. Anything an agent writes to memory, notes, caches or a vector store outlives the mission that wrote it. That is the durable form of prompt injection: inject once, persist indefinitely. Plane 3 — Policy & Compliance Engine ID Criterion Verification question C3.1 The rules governing an agent's behavior are external to the agent, not resident in its prompt, its weights, or state it authors itself. Can governing policy be changed without redeploying or re-prompting the agent? C3.2 Policy is evaluated during execution, at each governed action, not once at session start. In a mission with N governed actions, how many policy evaluations occur? C3.3 The basis of every policy decision is recorded at decision time, in terms a human can read and a policy author can trace to a specific rule. Take a past denial. Can a policy author name the rule that produced it without consulting its author? C3.4 Given the recorded decision inputs and the policy version in force, a past decision reproduces exactly. Replay a sampled decision from its record. Does it return the same result? C3.5 An action whose effect is not enumerated is denied, not permitted. Invoke an enumerated tool to produce an effect no rule addresses. Is it denied? C3.6 A policy rule in force in production expresses a constraint whose subject is in one system and whose condition is in another. Name that rule and show it evaluating in production. C3.7 Every change to governing policy is versioned, dated, and attributable to an authority outside the agent. Can you reconstruct the policy in force at the time of a past action? C3.8 An action whose applicable criteria cannot be evaluated does not proceed. Make the governing system unreachable, then attempt a governed action. Does it fail closed? C3.3 and C3.4 are the two halves of what revision 1 tried to say with a single requirement for reproducible decisions. Splitting them resolves the contradiction with C5.4: anomaly-based, rate-based and time-based controls all return different results for the same nominal action, and are now conformant, because what is required is that the basis be stateable and the decision replayable from its recorded inputs , which include the score or counter the engine consulted. C3.5 is the most consequential criterion in this proposal, and revision 1 hid it behind an ambiguous word. Denial by default at tool granularity is nearly vacuous, since an allowlist is already an allowlist. At effect granularity it is a large claim, because a single enumerated tool can span an unbounded effect space. A general shell, a browser, an arbitrary HTTP client: one tool, infinitely many effects. Revision 2 states the granularity and accepts the consequence: Generality is itself a governance decision. A tool whose effect space cannot be enumerated is not a conformant tool, and an agent that requires one is not operating under this layer. C3.8 is new, and it is the most valuable addition in revision 2. It is derived rather than invented: if an action is governed only when every applicable criterion holds, and a criterion that cannot be evaluated does not hold, then an action whose criteria cannot be evaluated must not proceed. Without it, the availability of the governing system is an attack surface with no criterion attached. Plane 4 — Human Oversight, Audit & Traceability This Plane depends on a construct the doctrine does not yet have. Humans Retain the Right to Intervene asserts the right without saying at what threshold it is exercised. That is the second gap recorded as an open revision item in v3.2 . Action Tiering Guidance elsewhere tiers agent actions by stakes, often with a monetary threshold as the example axis. Stakes are a poor primary axis. They are subjective, they argue badly under assessment, and in regulated environments they mislead, because the disclosure of a single record is unrecoverable and costs nothing. Revision 2 tiers by reversibility , with two qualifiers that revision 1 lacked. Tier Definition Governance requirement Tier 1 — Reversible The action can be undone by the agent or a human, with no effect on any principal or system outside the boundary the mission declares. Autonomous execution permitted. Tier 2 — Consequential The action has effect beyond that boundary and is recoverable within a window longer than the deployment's measured detection latency. Requires corroboration by a second principal before commit. Tier 3 — Irreversible The action cannot be undone, or its recovery window is shorter than measured detection latency. Value transferred, data disclosed beyond the declared boundary, notification sent, physical effect produced. Requires human authorization before commit. Never delegable to an agent. Reversibility decays with time. A transfer is reversible for minutes, a message for seconds, a configuration change until the first consumer reads it. Revision 1 asserted that reversibility is determinable in advance, which is false for most actions. The comparison that can actually be made is whether an action's recovery window exceeds the organization's own measured detection latency. That makes tier assignment deployment-specific rather than universal, which is uncomfortable and correct: an organization that cannot detect quickly has fewer Tier 2 actions available to it. Magnitude is a second axis, not a competitor. Reversibility says whether an action can be undone; magnitude says whether anyone should care. Revision 1's own justification for abandoning stakes proves they are orthogonal rather than alternatives. Tier assignment records both, and magnitude may raise a tier but never lower one. Reads. Revision 1 left the most common action type undefined, and both readings were wrong. Under Law 1 the agent is a principal, so a read discloses to a principal; taken literally, every read of sensitive data becomes Tier 3 and every retrieval-based agent becomes unusable. Taken loosely, an agent may traverse an entire protected store autonomously and trip a gate only on egress, which is backwards from how access to protected records is actually regulated. Revision 2 resolves it explicitly: a read is tiered by the boundary it crosses, not by the act of reading. A read within the mission's declared data boundary is Tier 1. A read that brings data across that boundary into the agent's context is Tier 2, because it is unrecoverable but bounded. A read that places data beyond the declared boundary is Tier 3. ID Criterion Verification question C4.1 A state change by an external authority, whether revocation, override or halt, is honored before the agent's next commit. Revoke mid-mission. Was any action committed after the revocation was accepted? C4.2 Every governed action carries an assigned tier, determined before it is attempted, recorded with the reversibility basis, recovery window and magnitude that produced it. Show the tier assignment and its basis for a currently pending action. C4.3 A Tier 3 action cannot commit without a recorded human authorization event that is non-delegable to any agent. Enumerate every Tier 3 action type. For each, demonstrate the gate, then attempt commit without authorization and observe denial. C4.4 The representation of an action presented to a human for authorization is generated by the governing system from the action's committed parameters, not by the agent, and the record retains exactly what was shown. Diff what was displayed to the approver against what committed. Do they correspond? C4.5 The record contains the exact inputs and outputs of an invocation, sufficient to replay it deterministically. Replay a sampled invocation from its record. Does it reproduce? C4.6 The evidentiary obligations for an agent are declared before it is deployed, and the runtime is demonstrated to satisfy them before it is deployed. Produce the declaration. Was it demonstrated against the runtime before first production use, or asserted? C4.7 A mission crossing multiple systems produces one reconstructable record, not fragments per system. How many systems must be queried to reconstruct a single mission? C4.4 is new, and without it C4.3 is theatre. A human authorization that rests on an agent-authored description of the action is not oversight; it is a signature on a document the signer did not write and cannot verify. Approval fatigue is the best-documented failure mode of human-in-the-loop systems in every prior domain, and revision 1 had no defence against it. C4.6 is new and states an obligation at design time rather than discovering it after an incident. Declaring what must be provable, and demonstrating that the runtime can produce it before deployment, makes auditability falsifiable while it is still cheap to fix. This mirrors long-standing assurance-case practice, in which the claim and the evidence required to sustain it are stated before the system is built rather than assembled afterwards. Plane 5 — Multi-Agent Trust & Delegation ID Criterion Verification question C5.1 Trust is established at every handoff, whether delegation, orchestration, tool invocation or subagent spawn, and never carried across one. Identify a handoff at which trust is assumed rather than established. C5.2 Authority is never inherited from an invoking agent. Authority held by a subagent is granted independently, scoped to its own mission, by the same external authority that grants the invoker's. Does any subagent hold authority solely because its invoker held it? Is any authority held by an invoker present only to be passed through? C5.3 A Tier 2 action is corroborated by a principal that does not share the originating principal's context, and whose failure correlation with the originator is measured and bounded. What is the measured correlation between originator and corroborator on the C2.3 corpus? C5.4 A detection capability exists, and on detection of anomalous behavior the governing system halts every downstream consumer of the affected agent's output, not only the agent. Name the detection capability. Trigger a halt. Did any downstream consumer continue on output produced before the halt? C5.2 is the correction to revision 1's contradiction. Requiring delegated authority to be a strict subset of the delegator's seems obviously right and is not, because it forces an orchestrating agent to accumulate every authority its subagents need purely in order to pass them down, which then violates Least Agency at the orchestrator. Independent grant is the resolution: an orchestrator that decides needs no authority to act, and a subagent that acts needs no authority to decide. C5.4 also closes a way revision 1 could be satisfied vacuously. It governed what happens on detection of anomalous behavior without requiring that any detection capability exist, so an organization with none conformed trivially. Cascading Failure is not contained by halting one agent while its consumers continue on what it already produced. Cross-plane — the Simultaneity Criterion Of the four threats named on the Declaration , Intent Hijacking , a valid action taken for an invalid reason, has never had a clean architectural home. That is not an untidiness in the model. It is the reason this layer is necessary. An intent-hijacked action passes every individual control it encounters, because each one returns permitted . The identity is real. The tool is allowlisted. The policy rule matches. The action is in tier. No single criterion catches it, and no catalogue of controls can, because a catalogue is evaluated one control at a time. Revision 1 stated that much and stopped, which left the criterion unassessable and, worse, left the actual gap open. Two things can diverge between the action that was governed and the action that occurred. It can change in time : policy evaluates an action, and something else commits. It can change in meaning : policy evaluates an action interpreting a term one way, and enforcement applies it interpreting the same term another way. The action never changed; the definition did. Both divergences produce a governed record for an ungoverned act. ID Criterion Verification question CX.1 Every applicable criterion holds for a single action within that action's decision window; the parameters evaluated are identical to the parameters committed; and every term the decision depends on resolves to a definition held by one authority, shared by the policy engine and the enforcement point. For a sampled committed action, produce the evaluation record for every applicable criterion, timestamped within its decision window, and demonstrate that evaluated parameters match committed parameters exactly. Then name a term the decision depended on and show both sides resolving it from the same authority. The action that was governed and the action that occurred must be the same action, in both time and interpretation. Conformance is a property of the action, not of the control set. The semantic half is not theoretical. In regulated environments the terms that policy depends on carry defined meanings, and systems that resolve them independently will disagree. Where the policy engine and the tooling hold separate definitions of what qualifies as a protected record, or as sufficiently de-identified, every criterion can pass and the disclosure still occurs. Semantic interoperability has been treated as a first-class engineering problem in health and defence information exchange for decades. It becomes a governance problem the moment two components must agree on what an agent is doing. The Maturity Model becomes an instrument The Governed Autonomy Maturity Model currently states that an organization should never deploy agents beyond its governance maturity, while providing nothing with which to measure that maturity. Revision 1 assigned each criterion a level and stopped there, which left two problems review was right to name. A level must license something. Revision 1's Level 1 was entirely observability, and no level said what it permitted an organization to deploy. A level number that licenses nothing is a badge. Revision 2 binds the levels to the tiers: Level 1 licenses Tier 1 actions only. Level 2 licenses Tier 2. Level 3 licenses Tier 3. Levels are sorted by implementation cost, not by conceptual sophistication. Revision 1 placed the requirement for a single reconstructable cross-system record at Level 1, as though it were part of a basic inventory. It is unified cross-system tracing with a correlated identity spine, and organizations that have not achieved it for their own services in a decade will not achieve it for agents as a first step. Meanwhile Level 2 held genuinely cheap items. Sequencing by cost is the only function a maturity model performs, so revision 2 re-sorts accordingly. Level What it means Licenses Criteria required Level 1 — Identified You know which agents exist, what they run on, what they can reach, and what they did. Tier 1 C1.1, C1.2, C1.5, C2.1, C2.2, C3.1, C3.7 Level 2 — Governed Authority is bounded and withdrawable, irreversible actions are authorized by a human who can see what they are authorizing, and the system fails closed. Tier 2 C1.3, C1.4, C2.4, C3.2, C3.3, C3.5, C3.8, C4.1, C4.2, C4.3, C4.4, C4.6, C5.1 Level 3 — Continuous Governance holds during execution, across systems, across agents, and across time, without human prompting. Tier 3 C2.3, C3.4, C3.6, C4.5, C4.7, C5.2, C5.3, C5.4, CX.1 Gating criteria and the conformance profile Revision 1 made each level all or nothing. That produces misreporting rather than rigor: an organization at twenty-eight of twenty-nine does not report Level 0, it reports Level 2 and hopes. An instrument that makes honest reporting maximally costly selects for dishonest reporting. Percentage credit is worse, because it would let an organization buy a level while missing the criterion that mattered. Revision 2 uses the structure that assessment regimes converge on for exactly this reason: Gating criteria are strictly binary and cannot be compensated: C1.4 (an agent cannot reach its own authority), C3.8 (the system fails closed), and C4.3 (irreversible actions require human authorization). Failing any one of these means the level is not held, whatever else is true. All other criteria report as a conformance profile : X of Y at the claimed level, with each exception named, its compensating measure documented, and a remediation date attached. A claim without its profile is not a claim. What this does not change The proposal is additive. The 5 Laws keep their names and their count. The 5 Architectural Planes and 6 Framework Pillars are unchanged. The three non-negotiables and the bumper sticker are unchanged. A revision that renamed the doctrine's spine would invalidate every citation the doctrine has earned, and no gain at the conformance layer would justify that. Two things do change if this lands: the Maturity Model is rebuilt rather than amended, and Law 5 gains Action Tiering. Open questions Revision 1 published five. Three are now answered and are recorded here as closed, since a proposal that never closes a question is not converging. Two remain, and two are new. Closed: how many criteria. Twenty-nine, because the per-Plane quota is gone and the count now follows the content. Plane counts are unequal by design. Closed: is reproducibility of policy decisions too strong. It was not too strong, it was unstable, and one of this proposal's own criteria fell in its excluded set. Replaced by C3.3 and C3.4. Closed: scope of the supply chain. Training-data integrity and general software supply chain remain out of scope, because they are not properties of an agent action and are not assessable by the organization conformance is assessed against. Model binding, which revision 1 also excluded, was wrong to exclude and is now C1.5. Open: does tiering survive contact with practice? C4.2 now requires recording the recovery window and comparing it to measured detection latency. Whether organizations can measure their own detection latency honestly is untested. Open: is partial conformance meaningful or corrosive? The gating-plus-profile structure is a judgement, not a demonstrated result. The failure mode to watch is gates that quietly widen under commercial pressure. New: is C3.5 too expensive to be adopted? Enumerating effects rather than tools excludes general-purpose agents from conformance. That is deliberate. It may also be a line the market simply refuses, in which case the criterion is correct and irrelevant, which is the worst outcome available to a standard. New: who holds the definitions CX.1 depends on? Semantic binding requires a single definitional authority per term. In a regulated environment that authority may sit outside the deploying organization entirely, and nothing here says what happens when two external authorities disagree. Mapping from revision 1 How the original thirty criteria map into revision 2. Revision 1 Revision 2 Change C1.2, C2.1, C2.2, C3.1, C3.2, C3.6, C4.6 C1.2, C2.1, C2.2, C3.1, C3.2, C3.7, C4.7 Unchanged in substance C1.3 + C1.6 + C2.4 C1.3 Merged; the mission-necessity clause is dropped as indeterminate, the expiry and dormancy clauses survive C1.5 + C2.5 + C4.4 C4.1 Merged; one external-authority interruption property, tested as ordering rather than elapsed time C2.6 + C4.5 C4.5 Merged and rewritten to replayability; "why" and "intent" removed C5.1 + C5.6 C5.1 Merged; the general handoff rule absorbs its delegation instance C1.1, C1.4, C2.3, C3.3, C3.4, C3.5, C4.1, C4.2, C5.2, C5.4, C5.5 C1.1, C1.4, C2.3, C3.3 + C3.4, C3.5, C3.6, C4.2, C4.3, C5.2, C5.3, C5.4 Rewritten C4.3 — Cut; entailed by C4.2 and C3.1 together C5.3 — Cut; prescribed a specific architecture, which this proposal's own rules forbid — C1.5, C2.4, C3.8, C4.4, C4.6, CX.1 New Status Revision 2, published 1 August 2026. Open for comment through 31 October 2026 . The version-lock target has moved out of Q4 2026: locking a set with known internal contradictions would produce a standard that the first serious implementer disproves, and the date is worth less than the correctness. Until this lands in a numbered release recorded in the changelog , nothing on this page is doctrine. Substantive disagreement remains more useful than endorsement. Revision 1 was improved most by the reader who tried hardest to break it. Comments to rfc@governedautonomy.org . --- # Governed Autonomy and the Standards Landscape — Governed Autonomy Doctrine URL: https://governedautonomy.org/standards/ Governed Autonomy and the Standards Landscape Standards bodies are converging on agentic risk faster than they are converging on agentic architecture. These mappings show where each document lands. The category comparisons ask how Governed Autonomy relates to the existing control stack — IAM, security monitoring, orchestration, guardrails. This section asks a different question: how does the doctrine relate to the published standards and guidance that address the same problem? The answer is usually the same shape. Standards work is strongest at the control layer — what to require, what to prohibit, what to log. It is weakest at the architectural layer — where each control lives, which must hold simultaneously, and how far an organisation can safely extend autonomy today. Each mapping below is written to be useful in both directions: what the standard supplies that the doctrine does not, and what the doctrine supplies that the standard does not. CISA — Careful Adoption of Agentic AI Services The first multi-nation government guidance written specifically for agentic AI, published 30 April 2026 by six national cyber agencies. Its five risk categories independently reproduce three of the four threats this doctrine names. The most prescriptive control-level document published to date — and the clearest illustration of what a control catalogue cannot do on its own. OWASP — Top 10 for Agentic Applications 2026 The broadest community statement on agentic risk: ten ranked failure modes from more than one hundred contributors. Two of this doctrine's four named threats appear in nearly its own words, independently. The mapping also records where the two documents share an open edge, and treats the Top 10's Least-Agency advice as the convergent twin of this doctrine's law. NIST — AI Risk Management Framework The canonical enterprise vocabulary for AI risk, written before agents could act. The mapping covers the four functions, the Generative AI Profile, and the interval that matters: NIST's agent-specific overlays remain unpublished, and enterprises deploying agents today are working ahead of their own risk framework. Further mappings are planned against the EU AI Act and ISO/IEC 42001, each following the same structure: what the document establishes, where the two converge, where each is thinner, and the gap that survives compliance. When NIST's single-agent and multi-agent control overlays publish, they will be mapped criterion by criterion. --- # Governed Autonomy and CISA's Careful Adoption of Agentic AI Services — Governed Autonomy Doctrine URL: https://governedautonomy.org/standards/cisa-agentic-ai/ Governed Autonomy and CISA's Careful Adoption of Agentic AI Services Six national cyber agencies independently arrived at three of the four threats this doctrine names. That convergence is the most useful thing about the document. On 30 April 2026, CISA and NSA, together with the national cyber security centres of Australia, Canada, New Zealand and the United Kingdom, published Careful Adoption of Agentic AI Services — the first multi-nation government guidance written specifically for autonomous AI agents rather than for AI models in general. This page is a mapping, not a rebuttal. The guidance and this doctrine were developed independently and converge on the substance. Where they differ, they differ in layer : the guidance is a control catalogue, the doctrine is an architecture. Both are needed, and neither one substitutes for the other. What the guidance establishes The document sorts agentic risk into five categories and, importantly, argues that each demands a distinct control response rather than a single uniform governance overlay: Privilege risks. Accumulated and excessive access. Calls for cryptographically anchored per-agent identity, short-lived task-scoped credentials, mutual TLS on agent-to-agent and agent-to-service traffic, no static keys or shared service accounts, a prohibition on agents modifying their own privileges, and formal decommissioning. Design and configuration risks. Tool allowlisting against verified, version-pinned tools, and prompt-injection defence treated as a baseline design requirement rather than optional hardening. Behavioral risks. Goal misalignment and oversight evasion. Oversight checkpoints must be encoded in the workflow architecture by action type, data sensitivity and value threshold — never left to the agent's own judgement about when to check in. Structural risks. Cascading failure across multi-agent pipelines. Each agent is an independent principal; trust is verified, never inherited transitively. Role separation, consensus for moderate-stakes actions, and circuit-breaker patterns that halt and escalate. Accountability risks. The auditability gap. Human-readable tool-usage logs, preserved reasoning traces, consolidated end-to-end workflow records. The guidance names the finding directly: most organisations cannot distinguish agent actions from human actions in the logs they already keep. The risk categories are anchored in documented 2025 breaches in which an agent's reach exceeded what its task required, not in hypotheticals. That is what makes the document citable. Where the two converge Guidance risk category Governed Autonomy construct Privilege risks Agents Are Identities, Not Tools , Agent Identity & Lifecycle , and Least Agency Design and configuration risks Prompt Injection on the Threat Surface, and Execution & Tool Governance Behavioral risks Behavioral Drift on the Threat Surface, Humans Retain the Right to Intervene , and Human Oversight, Audit & Traceability Structural risks Cascading Failure on the Threat Surface, Trust Does Not Travel , and Multi-Agent Trust & Delegation Accountability risks Enforce at Runtime and Human Oversight, Audit & Traceability Incremental / graduated deployment The Governed Autonomy Maturity Model — Level 1 Identified, Level 2 Governed, Level 3 Continuous Three of the four threats named on the Declaration , namely Prompt Injection , Behavioral Drift and Cascading Failure , have verbatim or near-verbatim counterparts in the guidance's own risk language. The doctrine's threat surface was locked before the guidance was published. Neither document informed the other. The fourth threat, Intent Hijacking , has no single counterpart. It sits across two of the guidance's categories at once: design and configuration risk supplies the delivery mechanism, privilege risk determines the blast radius. A valid action taken for an invalid reason is a control-catalogue blind spot precisely because every individual control it passes through returns "permitted." One further convergence is worth naming. The guidance observes that continuous-verification models tuned for human session signals are largely blind to what an agent does mid-session with credentials it already holds. That is the same conclusion the Declaration reaches in its first non-negotiable: governance must move at the speed of execution, not bookend it. See The Zero Trust Parallel . Where each is thinner Identity governance Both documents are aimed at the same failure mode: an agent's permission footprint expanding past what was approved, through inheritance, integration and convenience, until no one can account for everything it can reach. That is what the guidance treats under privilege risk and what this doctrine calls Least Agency . Some commentary on the guidance has adopted "authority drift" for the same phenomenon; the two terms describe one problem. Least Agency remains the canonical name here because it states the constraint rather than the symptom. On mechanism, the guidance is more prescriptive than this doctrine is, and deliberately so. It specifies mechanism: cryptographic per-agent identity, mutual TLS, short-lived task-scoped credentials, an explicit prohibition on self-modification of privilege. Agent Identity & Lifecycle states the requirement — agents are first-class identities with mission-scoped boundaries — without naming an implementation. On this dimension the guidance is the more actionable document, and the doctrine defers to it. Runtime behavior control Both documents locate control during execution rather than at the point of authorisation, and both refuse to let the agent decide when oversight applies. The guidance adds a control vocabulary the doctrine has not published: tool allowlisting with version pinning, circuit-breaker halt-and-escalate, consensus for moderate-stakes actions, and an action-tiering scheme that grades autonomy by stakes. Humans Retain the Right to Intervene asserts the right; it does not yet define the tiers at which the right is exercised. That is a real gap in the doctrine, and it is named here rather than argued away. System integration This is the dimension on which the doctrine reaches further. The guidance treats each risk category as a control domain to be addressed. It does not supply a model for where those controls live relative to one another, how a policy decision in one domain constrains execution in another, or how an organisation knows it is ready to widen an agent's scope. Governance Must Span Systems and the five Planes of the Governed Autonomy Architecture exist to answer exactly that question, and the Governed Autonomy Maturity Model stages the readiness judgement the guidance recommends but does not formalise. The gap A control catalogue tells you which controls to implement. It does not tell you where each control belongs, which ones must hold simultaneously for a single agent action to be sanctioned, or how far your organisation can safely extend autonomy today. That is an architectural question, and it survives full compliance with the catalogue. An organisation can implement every control the guidance recommends, in isolation, and still be unable to answer the question this doctrine treats as the load-bearing one: is what this agent is doing right now sanctioned, and can we stop it mid-chain if it is not? Controls implemented as a checklist produce coverage. Controls implemented as a fabric produce governance. The second non-negotiable exists for that distinction. Complementary layers, not competing standards The relationship is the one NIST's Cybersecurity Framework has with its own implementation guidance, or that Zero Trust architecture has with the specific access controls that realise it. Careful Adoption of Agentic AI Services is the strongest control-level statement any government has published on autonomous agents. This doctrine supplies the architecture those controls sit inside — which Plane each belongs to, which Law each satisfies, and at which maturity level an organisation has earned the right to widen the mission. Both gaps named above, mechanism under Agent Identity & Lifecycle , and stakes tiers under Humans Retain the Right to Intervene , are open revision items, not settled positions. This doctrine is versioned and revised in the open precisely so that guidance published after it can be absorbed rather than argued with. See the changelog . Read the guidance first. It is short, specific, and free. Then use the Governed Autonomy Framework to decide where each of its controls belongs and in what order to build them. Primary sources CISA: Careful Adoption of Agentic AI Services (resource page, 30 April 2026) Full guidance (PDF) CISA release announcement --- # Governed Autonomy and the NIST AI Risk Management Framework — Governed Autonomy Doctrine URL: https://governedautonomy.org/standards/nist-ai-rmf/ Governed Autonomy and the NIST AI Risk Management Framework The canonical risk vocabulary for enterprise AI — written before agents could act. NIST's own agent-specific work is still in development. This mapping covers both facts. The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) is the reference point for enterprise AI risk in the United States: a voluntary framework organized around four functions, extended in July 2024 by a Generative AI Profile naming twelve risks specific to generative systems. It is the document most enterprise AI governance programs are built on. It is also, by its own timeline, a pre-agentic document: it manages the risks of systems that produce outputs, not systems that take actions. NIST knows this; its agent-specific work is proceeding through separate efforts that have not yet published. This page maps what transfers, what does not, and what governs the interval. What the AI RMF establishes RMF function What it covers Where it lands in this doctrine GOVERN Cross-cutting culture, policy, roles, and accountability for AI risk Plane 4, Human Oversight, Audit & Traceability ; Law 5 . The RMF governs the organization; the doctrine adds governance of the agent's behavior itself. MAP Establishing context: what the system is, who it affects, what can go wrong Pillar 2, Mission Definition : an agent's context is its mission, and mapping it is where Least Agency is set. MEASURE Analyzing, benchmarking, and monitoring AI risk The Conformance Layer proposed in RFC 001 is this doctrine's answer to what measurement means for agent governance: criteria with determinate verification questions, assessable per deployment. MANAGE Allocating resources to mapped and measured risks; response and recovery Partially Plane 3 . But see the gap below: management is a lifecycle activity, and agent risk concentrates at runtime. Of the Generative AI Profile's twelve named risks, four bear directly on agents: information security, human-AI configuration (automation bias and over-reliance, the same failure the doctrine addresses under Law 5), value-chain and component integration (the supply chain beneath the agent), and confabulation (why an agent's account of its own action cannot serve as evidence about that action). The profile names no agent-specific risks; it predates the agentic wave by design and by date. The interval, stated plainly NIST's agent-specific work is real and public: a control-overlay program whose concept paper proposes dedicated overlays for single-agent and multi-agent systems, and an agent standards initiative launched in February 2026 covering interoperability, identity, and security. As of this mapping's publication, the two agent overlays have no published draft. That is not a criticism; deliberate standards work takes time. But it defines the present interval: enterprises are deploying autonomous agents today under a risk framework written before agents could act, while the agent-specific guidance is still being drafted. This doctrine exists for that interval. It is versioned and revised in the open precisely so that when the overlays publish, they can be mapped here rather than argued with, exactly as was done for CISA's agentic guidance . Where each is thinner What the RMF supplies that this doctrine does not An organizational risk-management discipline: roles, culture, documentation, lifecycle process, and a vocabulary that procurement offices, auditors, and regulators already speak. Measurement science and testbeds behind the MEASURE function. Federal standing. On enterprise risk process, the RMF is the stronger instrument, and this doctrine defers to it entirely: nothing here replaces an RMF program, and a mature organization will run both. What this doctrine supplies that the RMF does not The RMF's functions operate on the lifecycle: before deployment (map, measure) and around it (govern, manage). An autonomous agent's defining risk arises during execution, mid-mission, at machine speed, across systems, where a framework of organizational practices has no enforcement surface. The doctrine's contribution is the runtime layer the RMF does not claim to provide: agents as governed identities, policy evaluated at each governed action, intervention that takes effect before the next one, trust re-established at every handoff. In RMF terms: the doctrine is what MANAGE has to become when the system being managed makes its own decisions between reviews. Complementary layers, not competing standards Run the RMF as the enterprise risk chassis. Use this doctrine for the layer the RMF leaves open: what must be true, architecturally and at runtime, for an autonomous agent's actions to be governed while they happen. When NIST's agent overlays publish, this page gains a sibling mapping them criterion by criterion. One further note for the record: the phrase "governed autonomy" appears in none of the NIST documents cited here. The state the overlays are being written to enable is the state this doctrine names, defines, and proposes to make testable. Primary sources NIST AI RMF 1.0 (NIST AI 100-1, January 2023) Generative AI Profile (NIST AI 600-1, July 2024) NIST Control Overlays for Securing AI Systems (COSAiS) and the concept paper proposing single-agent and multi-agent overlays NIST AI Agent Standards Initiative (February 2026) --- # Governed Autonomy and the OWASP Top 10 for Agentic Applications — Governed Autonomy Doctrine URL: https://governedautonomy.org/standards/owasp-agentic-top10/ Governed Autonomy and the OWASP Top 10 for Agentic Applications A hundred-contributor community ranked what goes wrong with agents. A ranking tells you what to defend against. It does not tell you where the defenses live, or when they must all hold at once. In December 2025, the OWASP GenAI Security Project's Agentic Security Initiative published the OWASP Top 10 for Agentic Applications 2026 : ten ranked risk categories for autonomous agents, developed with more than one hundred contributors and released under an open license. It is the broadest community statement yet on agentic risk, and its companion documents (a threat taxonomy, a multi-agent threat-modeling guide, a securing-applications guide) give it unusual depth. This page is a mapping, not a rebuttal: the two bodies of work were developed independently and converge on the substance. Where they differ, they differ in layer. The Top 10 enumerates and ranks the failure modes. The doctrine states the architecture in which the corresponding controls live, and proposes the criteria by which an implementation can be shown to hold. What the Top 10 establishes Ten risks, each with attack scenarios and mitigations, mapped to the initiative's underlying threat taxonomy. In the doctrine's terms: OWASP entry What it names Where it lands in this doctrine ASI01 Agent Goal Hijack An agent's objectives redirected through content it cannot distinguish from instruction Prompt Injection and Intent Hijacking on the Threat Surface; the treat-content-as-data conformance criterion in RFC 001 ASI02 Tool Misuse and Exploitation Legitimate tools misused inside authorized privilege Plane 2, Execution & Tool Governance ; Enforce at Runtime ASI03 Identity and Privilege Abuse Delegation chains and inherited privilege without a distinct, governed identity Agents Are Identities, Not Tools ; Plane 1 ; Least Agency ASI04 Agentic Supply Chain Vulnerabilities Compromised tools, models, registries, and agent interfaces Tool provenance and version binding under Plane 2; partly an acknowledged open edge of the doctrine (see below) ASI05 Unexpected Code Execution Generated code escalating to host compromise Action-level interception under Plane 2; deny-by-default at effect granularity in RFC 001 ASI06 Memory and Context Poisoning Corrupted stored context biasing future behavior Behavioral Drift on the Threat Surface; the persistent-state governance criterion added in RFC 001 revision 2 ASI07 Insecure Inter-Agent Communication Spoofed, intercepted, or manipulated agent-to-agent exchange Trust Does Not Travel ; Plane 5 ASI08 Cascading Failures A single fault amplifying across agents and workflows Cascading Failure on the Threat Surface, near-verbatim; halt-and-escalate scope under Plane 5 ASI09 Human-Agent Trust Exploitation Automation bias and persuasive explanation defeating human review Humans Retain the Right to Intervene , and the authorization-fidelity concern RFC 001 records: an approval based on the agent's own description of the action is laundering, not oversight ASI10 Rogue Agents Agents departing from intended function or authorized scope Behavioral Drift ; mid-mission revocation and decommissioning criteria under Plane 1 Two of the four threats named on this doctrine's Declaration appear in the Top 10 in nearly the doctrine's own words: cascading failure by name, behavioral drift as the substance of ASI06 and ASI10. The Threat Surface was locked in May 2026; the Top 10 was published in December 2025; neither document derives from the other. As with the CISA mapping , the convergence is the useful finding: independent bodies keep arriving at the same failure modes because the failure modes are real. Least Agency, in both documents The Top 10's introduction extends least privilege with what it calls Least-Agency: advice to avoid unnecessary autonomy, because agentic behavior deployed where it is not needed expands the attack surface without adding value. This doctrine carries the same principle at a different altitude: Least Agency as a law (no more decision scope, tool access, or action authority than the mission demands) with a conformance criterion in RFC 001 written so that an assessor can attempt to falsify it. The two usages are compatible and convergent: OWASP states the advice; this doctrine states the test. Readers arriving from the OWASP corpus should treat the terms as the same principle, and this page as the citation for the difference in role. Where each is thinner What the Top 10 supplies that this doctrine does not Ranked prevalence. Attack scenarios grounded in observed incident patterns. Per-risk mitigation catalogs. A threat taxonomy (the initiative's T-series) that this doctrine has no equivalent of and does not need to duplicate. And a form of legitimacy no solo publication can manufacture: more than one hundred named contributors and an open review process. On threat enumeration, the Top 10 is the stronger document, and this doctrine defers to it. What this doctrine supplies that the Top 10 does not A ranked list is evaluated one risk at a time, and its mitigations attach to risks, not to an architecture. The Top 10 does not say which controls must hold simultaneously for a single agent action to be sanctioned, where each control lives relative to the others, how governance spans the systems an agent crosses, or how an organization decides it is ready to widen an agent's autonomy. Those are the questions the five Planes , the six Pillars , and the Maturity Model exist to answer, and the questions RFC 001 proposes to make testable. ASI01 and ASI09 together make the doctrine's own argument: a goal-hijacked agent that presents a persuasive account of a permitted action passes every individually evaluated control. Only criteria read together, at the moment of action, catch it. That is the Simultaneity Requirement, and it is an architectural property, not a mitigation. The open edge both documents share ASI04 reaches into the supply chain beneath the agent: models, tools, registries, update channels. RFC 001 carries provenance and version binding for tools, and records as an open question whether model provenance and training-data integrity belong inside a governance conformance layer at all. The honest current answer is that neither document fully governs the layer beneath the agent, and the doctrine says so rather than mapping the gap away. Complementary layers, not competing standards Use the Top 10 to know what to defend against and to brief the teams who will build the defenses. Use the doctrine to decide where each defense lives, which must hold at once, and how far autonomy can safely extend today. One further note for the record: the phrase "governed autonomy" appears nowhere in the Top 10 or its companion documents. The state those documents are working to make reachable is the state this doctrine names, defines, and proposes to make testable. Primary sources OWASP Top 10 for Agentic Applications 2026 (OWASP GenAI Security Project, Agentic Security Initiative; December 2025; CC BY-SA 4.0) Agentic AI: Threats and Mitigations (the underlying threat taxonomy) Multi-Agentic System Threat Modeling Guide Securing Agentic Applications Guide --- # Governed Autonomy vs the Existing Stack — Governed Autonomy Doctrine URL: https://governedautonomy.org/vs/ Governed Autonomy vs the Existing Stack Every existing control domain is necessary. None is sufficient. These comparisons show exactly where each one stops. Governed Autonomy does not replace the enterprise control stack — it coordinates it. But "coordinates, not replaces" only means something if the boundary is drawn precisely. Each comparison below takes one established category and tests it against the same three dimensions: how it governs identity, how it controls behavior at runtime, and how far it reaches across systems. The pattern that emerges is the architectural gap the doctrine names. Governed Autonomy vs Identity & Access Management IAM answers who can reach what . It cannot see what an autonomous agent does after access is granted. The comparison every identity architect should start with. Governed Autonomy vs Security Monitoring (SIEM, SOAR & Detection) Detection tells you what happened. For agents operating at machine speed, after-the-fact is too late — and the responder itself becomes a governance problem. Governed Autonomy vs Orchestration & Workflow Automation Orchestration executes paths a human authored. Autonomous agents author their own paths. The control model breaks at exactly that point. Governed Autonomy vs AI Guardrails Guardrails constrain what a model says. They do not govern what an agent does. The most common — and most consequential — category confusion in agentic security. These comparisons cover the enterprise control stack. For mappings against published standards and government guidance on agentic AI, see Governed Autonomy and the Standards Landscape . Validation test: if runtime enforcement of autonomous AI agent behavior is removed and the system would still meet its objective, it is not Governed Autonomy. --- # Governed Autonomy vs AI Guardrails — Governed Autonomy Doctrine URL: https://governedautonomy.org/vs/guardrails/ Governed Autonomy vs AI Guardrails Guardrails constrain what a model says. They do not govern what an agent does. Guardrails (input filtering, output moderation, content policies, jailbreak resistance, safety classifiers) are the first control layer most organizations deploy around AI, and the one most often mistaken for governance. They operate on the conversation : what enters the model and what leaves it. An autonomous agent's risk is not in what it says. It is in what it does. What guardrails do well Filter harmful, off-policy, or sensitive content at the model boundary Reduce, though never eliminate, prompt-level manipulation of model outputs Cheap to deploy and model-adjacent: a sensible baseline for any AI exposure Where they stop Identity governance Guardrails have no concept of identity at all. They evaluate text, not actors. The same filter applies whether the caller is an intern's chatbot or an agent holding production credentials — which is precisely backwards from how every other enterprise control is scoped. Runtime behavior control The agent's consequential surface is its tool calls : API invocations, file operations, system commands, delegations, none of which a content filter evaluates. A perfectly polite agent can delete a production database; the output that passed moderation was the action's announcement, not the action. Intent Hijacking makes this concrete: a valid-looking action taken for a corrupted reason sails through every content check, because the corruption is in the behavior chain, not the words. System integration Guardrails live at one model boundary. An agent's mission spans many systems, many calls, many boundaries, and the risk often emerges only from the sequence (read here, combine there, send outward). No per-call content filter can see a cross-system pattern. Governance Must Span Systems ; guardrails, by construction, govern one checkpoint. The gap Guardrails protect the conversation. Nothing in them governs the execution: the tool use, the data access, the cross-system behavior where agentic risk actually lives. Coordination, not replacement In the Governed Autonomy model, guardrails remain the model-boundary control: useful, baseline, and insufficient. Execution & Tool Governance and the Policy & Compliance Engine pick up where the content boundary ends: evaluating actions, not sentences, under Enforce at Runtime . If your AI safety story ends at the prompt, your agents are governed only when they talk. --- # Governed Autonomy vs Identity & Access Management — Governed Autonomy Doctrine URL: https://governedautonomy.org/vs/iam/ Governed Autonomy vs Identity & Access Management IAM answers: can this actor reach this system? It was never asked to answer what the actor does next. Identity and access management is the most mature control domain in the enterprise: provisioning, authentication, authorization, role and entitlement management, certification, and deprovisioning. For human users and static service accounts, it is the foundation of trust. Autonomous AI agents strain every one of its assumptions. What IAM does well Establishes who or what can access a resource, with strong authentication and lifecycle controls Models entitlements against roles: stable bundles of access that match stable job functions Provides the certification and audit trail regulators expect for access decisions Where it stops Identity governance Agents are provisioned today as service accounts: shared, static-credentialed, weakly owned. An autonomous agent is not a service account: it reasons, plans, and chains actions across systems. Agents Are Identities, Not Tools demands identity rigor IAM can deliver — provisioning, scoping, revocation — and most deployments don't yet apply. This part of the gap is practice, not architecture. Runtime behavior control This part is architecture. IAM's control moment is the access decision . Authentication and authorization happen, then IAM's work is done. Everything the agent does with that access — which records it reads, what it chains together, what it decides mid-mission — is invisible to the identity layer. Access control is the precondition for behavioral governance, not a substitute for it. System integration IAM governs access per system . An agent's behavior is a cross-system chain : a single mission may touch identity, infrastructure, security, and data domains in one execution sequence. No entitlement model expresses "allowed to read here only in service of a mission scoped there." Governance Must Span Systems ; access grants do not. The gap IAM can tell you an agent was authorized. It cannot tell you whether what the agent is doing right now is sanctioned, or stop it mid-chain when it is not. Coordination, not replacement In the Governed Autonomy model, identity systems remain authoritative for who the agent is. Agent Identity & Lifecycle builds on them: agents as first-class identities with mission-scoped boundaries and Least Agency enforced at the mission level, feeding the runtime planes that govern what the identity actually does. Strong IAM makes Governed Autonomy implementable. It does not make it unnecessary. --- # Governed Autonomy vs Orchestration & Workflow Automation — Governed Autonomy Doctrine URL: https://governedautonomy.org/vs/orchestration/ Governed Autonomy vs Orchestration & Workflow Automation Orchestration executes paths a human authored. Autonomous agents author their own paths. Workflow orchestration (pipelines, schedulers, automation platforms, integration buses) is how the enterprise made software-to-software work reliable. Its control model is strong precisely because the workflow is known in advance : every step authored, every transition reviewed, every failure mode anticipated. Autonomy removes the one assumption the whole model rests on. What orchestration does well Deterministic execution of human-authored workflows, with retries, rollbacks, and audit Explicit dependencies and sequencing: the workflow definition is the control A natural choke point for change management: edit the workflow, review the diff, redeploy Where it stops Identity governance Orchestrators typically run workflows under broad platform credentials. When an agent is one step in a pipeline, or the pipeline's author, the executing identity no longer maps to the deciding identity. Every handoff between orchestrator, agent, tool, and subagent is a trust boundary, and Trust Does Not Travel across it automatically: the receiving participant inherits the task, not the authority. Runtime behavior control A workflow engine enforces sequence , not judgment . An autonomous agent generates its execution plan at runtime, selects tools dynamically, and adapts mid-chain based on intermediate results. There is no predefined path to validate against. Reviewing the workflow definition governs nothing when the workflow is written, by the agent, at execution time. System integration Orchestration connects systems mechanically but carries no policy about what crossing each boundary means . Connecting is not governing: an integration bus moves an agent's action between domains without evaluating whether that action, in that context, is sanctioned. The gap Orchestration can guarantee the steps run in order. It cannot ask whether the steps the agent just invented should run at all. Coordination, not replacement In the Governed Autonomy model, orchestration remains the execution substrate, and gains a governor. Execution & Tool Governance intercepts at the action level: every tool invocation evaluated, every sequence verified, allow/deny/modify decided during execution. Multi-Agent Trust & Delegation makes each handoff in the chain explicit, auditable, and revocable. The pipeline still runs the work. It no longer decides, alone, whether the work should run. --- # Governed Autonomy vs Security Monitoring (SIEM, SOAR & Detection) — Governed Autonomy Doctrine URL: https://governedautonomy.org/vs/siem/ Governed Autonomy vs Security Monitoring SIEM, SOAR, and detection answer: what happened, and how do we respond? Autonomous agents force a harder question: what is happening, and should it continue? Security monitoring is the enterprise's record of truth — telemetry collection, correlation, detection, and increasingly automated response. Against human-speed adversaries and deterministic software, detect-and-respond is a workable control model. Against autonomous agents, the timeline collapses. What monitoring does well Cross-domain visibility: one place where firewall, endpoint, identity, and application telemetry converge Detection logic refined over decades — correlation, anomaly identification, threat intelligence Forensic reconstruction and the evidentiary record that audit and incident response depend on Where it stops Identity governance Monitoring sees events , not actors with missions . If agent actions are not emitted as first-class telemetry tied to a governed identity, the most consequential actor in the environment is also the least visible one. Most agent behavior today produces no security telemetry at all. Runtime behavior control Detection is, by definition, after the fact. An autonomous agent executing a corrupted plan completes it in seconds — a Cascading Failure propagates across interconnected workflows before the first alert is triaged. Enforce at Runtime names the requirement: control during execution, not detection after it. And automated response carries its own trap: a SOAR platform empowered to act autonomously is itself a privileged agent, and ungoverned, it becomes the next incident. System integration Monitoring aggregates many systems' logs — but aggregation is not enforcement. Seeing an agent's actions across domains is not the same as holding authority to allow, deny, or escalate them across those domains. The gap Monitoring can reconstruct exactly how the agent caused the incident. It cannot be the reason the incident never happened. Coordination, not replacement In the Governed Autonomy model, security platforms supply the risk context that runtime enforcement decisions consume — and agent behavior itself becomes first-class telemetry feeding them. Human Oversight, Audit & Traceability is built on monitoring's strengths: full execution trace, forensic reconstruction, and the interfaces through which Humans Retain the Right to Intervene . Detection remains essential. It is the floor of governance, not the ceiling. --- # What Is Governed Autonomy? — Governed Autonomy Doctrine URL: https://governedautonomy.org/what-is-governed-autonomy/ What Is Governed Autonomy? The term the industry converged on. The definition it still lacks. Governed autonomy is the operating state in which autonomous AI agents plan and execute freely inside bounds that are explicitly defined, continuously enforced at runtime, and revocable by humans at any moment. Autonomy is what the agent contributes. Governance is what the enterprise retains. Neither is negotiable. A term in wide circulation Since late 2025, "governed autonomy" has appeared across the industry: in vendor operating models for finance and security operations, in consultancy frameworks for the agentic enterprise, in analyst research, in academic work on agent safety, and in glossaries of agentic identity. The usages differ in scope and motive. They agree on the essentials: autonomy is a dial rather than a switch; policy must be encoded in the runtime rather than appended after it; every agent action must be explainable, auditable, and reversible; and the human role shifts from approving individual transactions to governing behavior. That convergence is evidence. When vendors, analysts, and researchers reach independently for the same phrase, the requirement underneath it is real. This doctrine treats independent convergence the same way everywhere it appears: documented, not claimed. See the standards landscape for the method. What the circulating usages cannot do Nearly every published use of governed autonomy is an assertion: a product that promises it, an operating model that describes it, a talk that recommends it. None of them can be failed. A description of governed autonomy tells you what good looks like. It cannot tell you whether a given deployment has it, and it offers no way to be proven wrong. That is the difference between a phrase and a standard. A definition you cannot test is marketing. A standard you can fail is a discipline. The standard The Governed Autonomy Doctrine defines the term operationally, in four layers that can each be checked against a real deployment: The 5 Laws state what must be true for any governed agent: agents are identities, not tools; enforcement happens at runtime; governance spans systems; trust does not travel; humans retain the right to intervene. The Architecture places control: five planes covering agent identity and lifecycle, execution and tool governance, policy and compliance, human oversight and traceability, and multi-agent trust. The Framework sequences implementation: six pillars from agent identity through multi-agent governance. The Maturity Model stages the journey: Identified, Governed, Continuous. The goal is not to reach Level 3 immediately. The goal is to never deploy agents beyond your current governance maturity. A fifth layer is proposed and open for comment: RFC 001, the Conformance Layer , defines twenty-nine testable, mechanism-agnostic criteria that any implementation can be assessed against, and can fail. It is the first attempt to make governed autonomy falsifiable rather than aspirational. Validation test: if runtime enforcement of autonomous AI agent behavior is removed and the system would still meet its objective, it is not governed autonomy. Provenance This doctrine did not begin with the phrase. Development began in late 2025 with work on prompt injection and the trustworthiness of agent-retrieved data, matured through the arrival of largely ungoverned agent scaffolding in early 2026, and was first published as a public doctrine in May 2026, versioned and revised in the open. The August 2026 renaming matched the doctrine to its own oldest language: the Maturity Model has described "the path to governed autonomy" since its first publication. Every substantive change is recorded in the changelog . Where to start: read the Declaration , then the 5 Laws . To assess a real deployment, start with RFC 001 . --- # The Zero Trust Parallel — Governed Autonomy Doctrine URL: https://governedautonomy.org/zero-trust/ Governed Autonomy: A Zero Trust for Autonomous AI Systems Abstract Enterprise software is undergoing a structural shift. Systems are no longer composed solely of users and deterministic software. They increasingly include autonomous AI agents that reason, plan, and execute actions across multiple enterprise systems in real time. This introduces a new class of risk: behavioral autonomy at runtime across distributed enterprise environments. Existing enterprise control planes — identity management, security monitoring, orchestration, and data governance — were not designed to govern autonomous agents as persistent operational identities. And none of them were designed to govern what happens when agents orchestrate other agents. Governed Autonomy is to autonomous AI what Zero Trust was to network security: a foundational redefinition of how trust, identity, and enforcement operate in a new computing paradigm. The Breakdown of Deterministic Assumptions Enterprise architecture has historically relied on a stable assumption: software is deterministic, and actions are ultimately traceable to human intent. This assumption no longer holds. Modern AI agents: Generate their own execution plans Invoke tools dynamically based on reasoning Operate across multiple systems in a single execution chain Adapt behavior based on context and intermediate results Orchestrate and delegate to other agents — creating chains of autonomous action that no single system can see end to end These agents do not behave like applications. They behave like autonomous actors operating inside enterprise systems . The traditional separation between identity, execution, and governance collapses. The Structural Analogy Zero Trust redefined security architecture by rejecting implicit trust in network location or perimeter. Before Zero Trust, presence on the internal network implied authorization. Governed Autonomy redefines enterprise AI architecture by rejecting implicit trust in agent authorization. Today, an authorized agent is implicitly trusted to behave safely. That assumption is as flawed as trusting the internal network. Zero Trust Governed Autonomy Rejected assumption Network location implies trust Authorization implies safe behavior Core assertion Never trust the network; always verify Authorize the Agent. Govern the Behavior. What it governs Network access and lateral movement AI agent behavior across systems Enforcement model Continuous verification of access Continuous enforcement of behavior Scope Identity, device, network, application Identity, lifecycle, execution, policy, oversight, multi-agent trust Why Existing Systems Are Insufficient System Type What It Does What It Cannot Do Identity & Access Management Grants access to systems Cannot govern behavior after access is granted Security Monitoring (SIEM) Detects violations after they occur Cannot prevent violations at runtime Orchestration Executes predefined workflows Cannot constrain autonomous decision-making Data Governance Defines access and usage policies Cannot enforce policies across behavioral chains Any single-domain system Governs within its domain Cannot govern an agent operating across all domains simultaneously Each system is necessary. None is sufficient. The gap is not in any individual domain — it is the absence of a cross-domain runtime enforcement layer for autonomous behavior. The Missing Primitives Traditional enterprise systems enforce control in two ways: Pre-execution: authorization and access control Post-execution: logging, detection, and response Autonomous AI requires two additional models that did not previously exist in enterprise architecture: Runtime enforcement of behavior during autonomous execution Continuous human oversight with the ability to inspect, interrupt, and override at any layer Governed Autonomy defines both. The Direction As AI agents become more autonomous, more integrated, and more operationally critical, the need for runtime governance will not decrease. It will become foundational. Enterprises that treat AI as tools will struggle to control them. Enterprises that govern AI as autonomous identities — operating under continuous runtime constraint, with explicit multi-agent trust boundaries and active human oversight — will define the next generation of enterprise architecture. Authorize the Agent. Govern the Behavior. Governed Autonomy is the doctrine that makes this possible. ---