# 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.6. 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 AARM (Autonomous Action Runtime Management)](https://governedautonomy.org/standards/aarm/): A Cloud Security Alliance working group published nine RFC 2119 requirements for intercepting every agent action before it executes. How AARM v1.0 maps to the Governed Autonomy Laws, Planes and Threat Surface — and the one question a control plane cannot answer about itself. - [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 DEMM-Bench (Governance-Evidence Sufficiency)](https://governedautonomy.org/standards/demm-bench/): A benchmark that measures whether agent-runtime records are sufficient to reconstruct a decision, not merely present. How DEMM-Bench maps to Plane 4 and the Human Oversight Law, and why retrospective evidence sufficiency is not the same thing as a conformance verdict. - [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. - [Governed Autonomy and the IETF SCIM Agent Governance Extension](https://governedautonomy.org/standards/scim-agent-governance/): An IETF Internet-Draft gives provisioned agent identities a lifecycle state model and an autonomy classification — then rules authorization out of scope and defers delegated authority entirely. How it maps to the Governed Autonomy Planes, and why its exclusions matter more than its inclusions. ## 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 - [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. ## Other - [Agentic AI vs Generative AI](https://governedautonomy.org/agentic-ai-vs-generative-ai/): Agentic AI autonomously manages multi-step workflows; generative AI produces content on demand. The differences in autonomy, workflows, infrastructure, and governance — and why the governance requirements diverge sharply. - [Glossary](https://governedautonomy.org/glossary/): Canonical definitions for the vocabulary of governed autonomy and the agentic AI field — agents, identity, runtime enforcement, threat surface, and the doctrine's own terms. - [Standards Observatory](https://governedautonomy.org/observatory/): A dated, sourced survey of every published specification, standard, benchmark and government guidance document for governing autonomous AI agents: what each establishes, what it leaves open, and where the field currently agrees. - [Doctrine Status: What Is Settled and What Is Moving](https://governedautonomy.org/status/): A dated status map of the Governed Autonomy Doctrine's core constructs, from those unchanged since first publication to a proposal still under review. Every placement cites the changelog entry, standards page or RFC that justifies it. ## 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 primitives for the second exist; the model that applies them to an agent's behavior — against its mission, across every system it touches, at runtime — is not yet practised as a discipline. Governed Autonomy defines that model. 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. Every published change since first publication is recorded in the changelog . 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 . --- # Agentic AI vs Generative AI — Governed Autonomy Doctrine URL: https://governedautonomy.org/agentic-ai-vs-generative-ai/ Agentic AI vs Generative AI One produces; the other acts. The governance consequences are not symmetrical. Generative AI produces content reactively in response to prompts. Agentic AI autonomously manages multi-step workflows, maintains memory across steps, and calls external tools to complete tasks. They are most powerful in combination — and their governance requirements diverge sharply: generative AI poses informational risk, while agentic AI introduces operational risk through autonomous action on live systems. Definitions Agentic AI is the paradigm in which autonomous systems perceive their environment, plan multi-step action sequences, and execute those plans with minimal human intervention. Generative AI produces new content — text, images, code, synthetic data — by learning statistical patterns from training data and generating outputs in response to prompts. Generative AI answers "what should I create?" Agentic AI answers "what should I do next, and how do I get there?" AI agents are the execution units of agentic systems: software that perceives inputs, maintains state, reasons about goals, and calls tools to act. Unlike a classification or prediction engine responding to a single input, an agentic system is proactive — it operates toward objectives, maintains context across steps, and adapts its plan as conditions change. How agentic AI works Agentic AI operates through a perceive–plan–act cycle: it perceives through data sources and memory , plans by decomposing a goal into subtasks, and acts by calling tools, spawning sub-agents , or writing to downstream systems. Because it maintains state over time, it adapts as conditions shift — the capability that separates it most sharply from the prompt-response model. Agents act between human prompts. A supervisor agent receives a goal, then orchestrates specialized sub-agents that complete tasks in their domains and pass results forward without a user triggering each handoff — evaluating outputs, checking conditions, and adjusting approach at every step. How generative AI works Generative AI is built on large language models trained on massive corpora. The interaction model is reactive: content is produced only when prompted, which makes these systems excel at bounded, single-turn work — drafting, summarization, code suggestions — where the full task fits within one inference call. Retrieval-augmented generation (RAG) extends the pattern by querying external knowledge at inference time, grounding outputs in current facts rather than frozen training knowledge . Working together The two are most powerful combined. Generative models serve as the cognitive engine of agentic systems: the model reasons and produces output at each step, while the agentic layer handles execution, memory, and coordination across systems. A market-intelligence agent asked to "summarize competitor activity this week" decomposes the goal, queries sources, invokes a generative model for each summarization step, and routes results downstream — generation quality from one paradigm, orchestration and autonomy from the other. Direct comparison Dimension Agentic AI Generative AI Core function Autonomously manages multi-step workflows toward goals Produces content in response to prompts Interaction model Proactive — makes decisions without user triggers Reactive — produces content only when prompted Tool use Calls external tools and APIs to execute actions Generates output for a human to act upon Memory Maintains state across steps and sessions Stateless per inference unless augmented (e.g. RAG) Human oversight Configurable — and therefore a design decision Human evaluates each output by default Infrastructure Repeated inference loops, orchestration, durable memory Single inference per request Primary risk Operational — unintended autonomous actions Informational — inaccuracy or bias in content Choosing between them The choice is a question of task structure. Multi-step objectives spanning multiple systems with autonomous execution — supply-chain optimization, financial risk management, incident response, multi-stage onboarding — call for agentic AI. Bounded, creative, single-turn work — content at scale, code review, report drafting, synthetic data — calls for generative tools without the orchestration overhead. Hybrid patterns are increasingly the norm: an agentic layer managing a review cycle while generative models produce the artifacts at each step. The governance divergence Agentic AI introduces governance challenges generative AI alone does not create. When systems decide autonomously and act on live systems, controls must be designed in from the start, not retrofitted. Three are foundational: human-in-the-loop thresholds defining which decision classes require approval before execution; provenance logging that records every autonomous action — model invoked, calls made, data touched; and strict control of the tools an agent can invoke, limiting the blast radius of unintended behavior. Regulation is formalizing the same requirements, with the EU AI Act and NIST guidance both emphasizing auditability and documentation for autonomous systems. The asymmetry deserves the last word. A generative model that is wrong produces a wrong artifact, and a human decides what happens next. An agentic system that is wrong does something — which is why the governance of autonomous agents is not an extension of content-quality review but a discipline of its own. That discipline is what the Governed Autonomy Doctrine defines: laws the deployment must not violate, an architecture that places the controls, and a maturity model for how much autonomy an organization has earned. Frequently asked questions What is the core difference between agentic AI and generative AI? Generative AI produces content in response to prompts — reactive and bounded by a single inference call. Agentic AI autonomously manages multi-step workflows, makes decisions, and calls external tools to complete tasks with minimal human intervention. Generative AI produces output for a human to act upon; agentic AI takes the actions itself. When should organizations choose agentic AI instead of generative AI? Agentic AI is the right choice when a process requires sequential decision making, integration across multiple systems, and autonomous execution — financial risk management, supply chain automation, IT incident response. Generative AI is better suited to bounded, creative, single-turn tasks such as content creation, code generation, or summarization. Can agentic AI and generative AI work together? Yes — the two are most effective in combination. Agentic AI provides the orchestration layer, managing workflow state and decision sequencing; generative AI serves as the cognitive engine, producing text, code, or analysis at specific workflow steps. Most enterprise AI systems today combine both. How does governance differ for agentic AI versus generative AI? Generative AI governance centers on output quality — hallucinations and bias. Agentic AI governance is operationally harder because these systems act on live environments autonomously: organizations must define human-in-the-loop thresholds, maintain provenance logging for every autonomous action, and strictly control the tools an agent can invoke. Terms used here are defined canonically in the glossary . --- # 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. In Zero Trust terms, Plane 3 is the policy decision point and Plane 2 the policy enforcement point (NIST SP 800-207 §2). Governed Autonomy adds three inputs to that decision — the agent's mission, its cross-system action history, and its delegated authority — and places the enforcement point in the agent's execution path, where the agent cannot bypass or disable it. Plane 4: Human Oversight, Audit & Traceability Real-time behavior monitoring Reconstructable transaction record: for any governed action, who requested it, under what authority, which policy decided, what was executed, and what resulted — reconstruction does not require re-execution Record integrity: the record is tamper-evident and its integrity is independently verifiable Record governance: metadata by default; raw prompts, retrieved content and outputs captured only where policy requires them; the record is itself a governed data asset under the access, retention and minimization rules of the systems it records 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 is independently granted at the receiving node, and what is 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.6 . 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.6 · September 2026 (pending Institute ratification) Text revisions following the external critical assessment of v3.5 (September 2026), the Institute's response plan, and a review of both by a council of independent model reviewers on four vendors. Doctrine substance: no change to the names or count of the Laws, Planes or Pillars. Structural changes arising from the same review are carried in RFC 001 revision 3. Maturity Model : a level describes organizational capability and does not license any deployment; every deployment, at every level, satisfies all five Laws for the actions it takes. The sentence declaring the Declaration's gap closed at Level 2 is replaced. The Zero Trust Parallel , the Declaration and the Architecture page now state which existing primitives the doctrine builds on (attribute-based access control per NIST SP 800-162; policy decision and enforcement points per NIST SP 800-207) and what it adds. The claim that runtime enforcement "did not previously exist" is withdrawn. Planes 2 and 3 are stated in policy-decision and policy-enforcement terms. The comparison pages share one closing test for any control: does it mediate consequential actions, and can the governed actor bypass it. Plane 4 requires a reconstructable, tamper-evident transaction record governed as a data asset, in place of full execution trace logging. Delegation wording on the Architecture and Framework pages now matches Law 4 and RFC 001 C5.2: authority is independently granted at the receiving node, not transferred. The definition page no longer implies every governed action is reversible. Glossary : entries added for plane and for the doctrine's use of harness . Published the Status page (September 15): a dated map of eight constructs placed from most settled to least settled, with the changelog entry, standards page or RFC revision that justifies each placement. Reference page; no doctrine substance. v3.5 · August 30, 2026 Published the Glossary : canonical definitions in three tiers — doctrine vocabulary, the agentic field, and model & context mechanics — with stable per-term anchors and a machine-readable term set. Published Agentic AI vs Generative AI : a definitional comparison of the two paradigms and the asymmetry of their governance requirements. Removed the Evolution page. Its lineage function is served by this changelog, which has recorded every published change since first publication; the page's pre-publication narrative added no citable substance to the standard. The path redirects here. Doctrine substance unchanged: no change to the Laws, Planes, Pillars, Threat Surface, or Maturity Model. 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.6 (2026). https://governedautonomy.org/ BibTeX: @misc{governed-autonomy-doctrine, author = {{Governed Autonomy Institute}}, title = {The Governed Autonomy Doctrine}, year = {2026}, version = {v3.6}, 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.6 (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. For readers who need the complete text in one file, to diff a passage or to check what a page said, llms-full.txt carries the full text of every page and is regenerated from the built site at every deploy, so it is never behind the pages it covers. 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. --- # 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 is independently granted at the receiving node, and what is 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 --- # Glossary — Governed Autonomy Doctrine URL: https://governedautonomy.org/glossary/ Glossary The vocabulary of governed autonomy, defined canonically. Three kinds of entries. Doctrine vocabulary is defined here authoritatively — these terms mean what the doctrine says they mean, and each links to its canonical page. The agentic field entries define the wider terrain neutrally, as working definitions a practitioner can rely on. Model & context mechanics defines the machinery underneath agent behavior — models, tokens, context, tools, and sessions. Definitions are versioned with the doctrine (v3.6) and cite-able by anchor. Doctrine vocabulary Governed Autonomy 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. Canonical: What Is Governed Autonomy? The 5 Laws The doctrine’s invariants — what must be true for any governed agent: Agents Are Identities, Not Tools; Enforce at Runtime; Governance Must Span Systems; Trust Does Not Travel; Humans Retain the Right to Intervene. Each law can be violated by a specific architectural decision, which is what makes them laws rather than aspirations. Canonical: The 5 Laws Governed Autonomy Architecture The reference design: five architectural planes — Agent Identity & Lifecycle; Execution & Tool Governance; Policy & Compliance Engine; Human Oversight, Audit & Traceability; and Multi-Agent Trust & Delegation — that together place every control a governed deployment needs. Canonical: The Architecture Plane One of the five Architectural Planes — Agent Identity & Lifecycle; Execution & Tool Governance; Policy & Compliance Engine; Human Oversight, Audit & Traceability; Multi-Agent Trust & Delegation — and, in this doctrine, nothing else. Where Institute or practice text uses the word in another sense (control plane, data plane, service plane), it is qualified. Canonical: The Architecture Governed Autonomy Framework The implementation methodology: six pillars — Agent Identity, Mission Definition, Behavioral Policy, Runtime Enforcement, Human Oversight & Intervention, and Multi-Agent Governance — sequencing how an organization builds toward governed autonomy. Canonical: The Framework Least Agency An agent must be granted only the minimum decision scope, tool access, and action authority its mission requires — no more authority than the mission demands. The third leg of the trilogy after Least Privilege and Least Trust; converging industry usage is codified in the OWASP Top 10 for Agentic Applications. Canonical: The 5 Laws The Trilogy Three successive minimization disciplines: Least Privilege constrains access, Least Trust (the Zero Trust contribution) constrains assumptions, and Least Agency constrains autonomy. Each generation of enterprise security added one leg; autonomous agents demand the third. Canonical: Zero Trust lineage Threat Surface The doctrine’s named failure modes for autonomous agents: Prompt Injection, Intent Hijacking, Cascading Failure, and Behavioral Drift. Each names a class of failure that governance must be architected against, not patched after. Intent Hijacking A threat-surface entry: an agent taking a valid action for an invalid reason — its mission subverted while its permissions remain intact. Access control cannot see it; only behavior-level governance can. Cascading Failure A threat-surface entry: one agent’s error propagating at machine speed through the systems and agents downstream of it, outrunning periodic review. The failure mode that makes governance tempo a first-class design constraint. Behavioral Drift A threat-surface entry: the gradual divergence of an agent’s operating behavior from its authorized mission — through model updates, context accumulation, or changing tool surfaces — without any single detectable violation. Maturity Model Three levels — Level 1 Identified, Level 2 Governed, Level 3 Continuous. The operative rule: the goal is not to reach Level 3 immediately; the goal is to never deploy agents beyond your current governance maturity. Canonical: The Maturity Model Conformance Layer Proposed (RFC 001): testable, mechanism-agnostic criteria an implementation can be assessed against — and can fail. The layer that makes governed autonomy falsifiable rather than aspirational. Canonical: RFC 001 The agentic field AI Agent (Agentic AI) A software system that uses a model to plan and execute multi-step tasks toward a goal — calling tools, acting on other systems, and adapting to results — rather than returning a single response. Agentic AI names the class; an agent is an instance with a mission. Agent Harness Industry term for the software scaffolding around a model that makes it an agent: the execution loop, tool interfaces, memory, and control logic. The harness is where an agent’s capabilities are assembled — and therefore one of the places its governance must attach. In this doctrine, harness always means this runtime component — the Plane 2 execution layer that turns model proposals into governed actions — and never a category. The doctrine was published as the AI Harness Doctrine through v3.2; that name is retired and survives only in the changelog. Agent Identity A distinct, verifiable identity provisioned for a specific agent — owned, scoped, credentialed, and revocable like a human identity, with constraints appropriate to its autonomy. Contrast with shared service accounts, which government guidance now explicitly rejects for agents. Non-Human Identity (NHI) Any machine identity — service accounts, tokens, bots, AI agents. NHIs outnumber human identities in most enterprises by an order of magnitude and are consistently the least-governed identity class; agentic AI accelerates both facts. Runtime Enforcement Evaluating and constraining an agent’s actions during execution, in the execution path, where controls cannot be switched off for convenience — as opposed to review before deployment or audit after the fact. Governance that moves slower than execution is forensics. Guardrails Model- or application-level filters that shape what a system will say or attempt. Guardrails are configuration — they can be disabled, bypassed, or updated away. The distinction between guardrails and governance is whether the control survives the actor it constrains. See also: Doctrine vs. guardrails Human-in-the-Loop An oversight pattern in which defined agent actions require human review or approval before proceeding. Governance-grade oversight encodes the checkpoints in the workflow architecture — by action type, data sensitivity, and stakes — rather than leaving the agent to decide when to ask. Least Privilege The classical access-control discipline: every principal receives the minimum permissions its function requires. Necessary but not sufficient for agents — an agent can hold minimal permissions and still misuse them, which is the gap Least Agency addresses. Zero Trust The security architecture in which no access is granted on the basis of network location or prior trust: every request is evaluated continuously against policy (NIST SP 800-207). Governed autonomy extends the same never-trust-always-verify posture from access requests to agent behavior. See also: Zero Trust and the doctrine Multi-Agent Delegation One agent handing work to another — spawning sub-agents, invoking peers, chaining tools. Each handoff is an independent trust boundary: the receiving agent inherits the task, never the authority. Ungoverned delegation is how single-agent risk becomes systemic risk. Tool Allowlisting Restricting an agent to an explicit, verified, version-pinned set of tools rather than an open-ended surface. The design-level control government guidance treats as baseline for agent deployments. Prompt Injection An attack in which instructions embedded in content an agent processes — a web page, a document, a tool result — hijack the agent’s behavior. For tool-wielding agents the blast radius is the agent’s authority, not the conversation, which is why defense belongs in the execution path rather than the prompt. Model Context Protocol (MCP) An open protocol standardizing how AI applications connect models to tools and data sources. Protocols like MCP expand what agents can reach — which is precisely why tool governance and identity must attach at the same layer. Model & context mechanics How the machinery actually works. Agent governance keeps returning to these mechanics — an agent’s behavior is downstream of its model, its context, and its tools, and several doctrine arguments (runtime enforcement in the tool-call gap, delegation boundaries at subagent spawns, memory as a governed asset) are only legible with this vocabulary in hand. Model The parameters. A model is stateless — it does next-token prediction and nothing else, and cannot do anything agentic on its own. Everything agentic comes from the harness around it. Parameters The numbers inside a model — often billions — set during training. Everything the model knows from training lives in them. Also called weights. Training The process that sets a model’s parameters by exposing it to vast amounts of data and adjusting to improve next-token prediction. After training, the parameters are fixed. Inference Running a trained model to generate output. Parameters stay fixed; only the context varies. Every agent action begins with an inference call. Model Provider Whatever serves a model for inference — a hosted API or local serving infrastructure. The harness sends context to the provider; the provider returns one response. Token The atomic unit a model reads and writes — roughly word-sized, but not exactly. Context-window size, cost, and latency are all counted in tokens. Next-Token Prediction What a model actually does: sample one next token from the context, append it, and run again. Every capability layered on top — reasoning, tool use, agency — is built from this single operation. Non-determinism The same input can produce different output — a property of how models generate text and how providers serve requests. A governance-relevant fact: identical conditions do not guarantee identical agent behavior. Context The information an agent has access to right now — what it knows that is pertinent to the task, as distinct from what its model learned in training. Context Window Everything the model sees on a single inference request. Finite and model-specific — the only surface through which the model perceives anything. System Prompt The instructions the harness prepends to every model request — the agent’s standing brief, usually stable across a session. A policy stated only here is a suggestion, not enforcement. Turn One user message plus everything the agent does in response, until it yields back to the user. A single turn can contain many inference requests and tool calls. Session One bounded run of interaction with an agent. Starts empty, accumulates context, and ends when cleared, closed, or compacted into a fresh session. Stateless and Stateful Stateless: carries no information forward — the model across requests, an agent across sessions by default. Stateful: carries information forward — a session across turns, or an agent given a memory system. Compaction Summarizing a session’s history to seed a fresh session when the context window fills. Lossy by design: detail is traded for headroom, and whatever the summary omits is gone from context. Handoff Transferring agent context from one session to another with no return path — via a written artifact, a compaction summary, or another carry mechanism. Every handoff loses something; governance records must not depend on what survives one. Memory System A mechanism that makes an agent stateful across sessions by persisting information to the environment and reloading it at session start. Agent memory is an asset to govern: it shapes future behavior and can be poisoned. Knowledge Cutoff The date past which a model has no training knowledge. Anything newer must arrive through context — or the model may fabricate it. Parametric Knowledge What a model knows from training, stored in its parameters and frozen at training time. Counterpart to contextual knowledge. Contextual Knowledge Facts an agent can read directly from its context right now — loaded documents, tool results, instructions. Counterpart to parametric knowledge, and the half an enterprise actually controls. Tool A function the harness exposes for the agent to call — read a file, run a command, query an API. Tools are how an agent perceives and acts on its environment, which is why tool governance is a control plane and not a feature. Tool Call and Tool Result A tool call is the model’s output naming a tool and its arguments — structured text the harness must execute. The tool result is what comes back. The gap between the two is where runtime enforcement lives: the call can be inspected, authorized, or refused before anything happens. Subagent An agent spawned by another agent to perform a scoped piece of work in its own session, reporting back a single result. Every spawn is a delegation boundary — the subagent inherits the task, not the authority. Sandbox An isolated environment an agent runs inside — container, VM, or restricted shell — limiting the blast radius of its actions. A sandbox bounds where an agent acts; it does not govern what the agent does within it. Environment The world an agent acts on — everything outside the harness that it perceives through tool results and changes through tool calls. Hallucination Confidently wrong model output. Two flavors: factuality (invented facts) and faithfulness (drift from what the loaded context actually says). In agentic systems, a hallucination can become an action. Sycophancy Confidently agreeable model output — a bias toward telling the user what they want to hear, produced by training on human preferences. A governance concern wherever an agent’s own report is the basis for approving its actions. Reasoning Effort A setting for how much reasoning a model does before answering — more effort spends more output tokens for a better chance at hard problems. One of the dials that make identical agents behave differently. To cite a definition, link its anchor — every term on this page has a stable URL. For citing the doctrine itself, see How to cite . Terms are added and revised through the doctrine's changelog . --- # 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 in the organization's capability. A level describes how much governed deployment an organization can carry. It does not license any particular deployment. Every deployment, at every level, satisfies all five Laws for the actions it is permitted to take; a deployment that involves handoffs satisfies Law 4 whether or not the organization has reached Level 3. The gap identified in the Governed Autonomy Declaration closes per deployment, when that deployment's governance is complete for the actions it takes. 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: a level licenses only those deployments whose actions satisfy all five Laws with the capability that level demonstrates. Which actions a given deployment may take is set per deployment, by its assurance profile ( RFC 001 ), not by the level. The "Law alignment" line under each level names the capability the level demonstrates. It does not name Laws a deployment at that level may skip. --- # Standards Observatory — Agent Governance Landscape — Governed Autonomy Doctrine URL: https://governedautonomy.org/observatory/ Standards Observatory A running survey of published work on governing autonomous AI agents. What each artifact establishes, what it leaves open, and what the field has converged on without coordinating. Last updated 2 September 2026. This page is maintained continuously and dated on every revision. Entries are added when an artifact is published, verified against its primary source, and assessed for what it covers. Nothing is listed here that has not been read. What this page is for. Anyone trying to govern autonomous agents today faces a dozen documents published in eighteen months by standards bodies, government agencies, vendors and researchers, with no map between them. This is the map. It is deliberately written to be useful whether or not you adopt this doctrine, and every entry links to its primary source so the assessment can be checked. Citation convention. Artifacts are cited by publishing body and document identifier, never by individual author. Where a document has a DOI, the DOI is given. What the field agrees on Read together, the artifacts below show more convergence than their variety suggests. Four points are now effectively settled across independent documents that do not cite one another: Governance has to run at execution time. Pre-deployment review and retrospective audit are both necessary and neither is sufficient. Every runtime specification published since early 2026 assumes an interception point before an action takes effect. Agents need durable identities. Treating an agent as a feature of an application, rather than as an identity with a lifecycle, breaks attribution, revocation and audit simultaneously. Enforcement must span systems. A control that governs one framework, one vendor or one tool surface is bypassable by construction. Evidence has to be more than present. The newest work has moved from requiring logs to asking whether the logs can answer a question. And one point is consistently not settled. Every artifact surveyed here governs what a single agent may do at the moment it acts. None specifies what authority survives when one agent delegates work to another. Several name cross-agent propagation as a threat; at least one mediates agent-to-agent messages through a policy engine; one standards-track document states explicitly that a binding for delegated scope must wait until cross-protocol semantics exist. The gap has now survived six independent attempts from four different kinds of organisation, which suggests it is a research problem rather than an oversight. Standards bodies and government guidance AARM v1.0 — Autonomous Action Runtime Management Cloud Security Alliance Technical Working Group, February 2026. CC BY 4.0, with a DOI. A system category specification defining a control plane that intercepts, evaluates, decides on and records every agent-initiated action before execution, independent of model, framework or environment. Nine requirements in RFC 2119 language, six MUST and three SHOULD, against a threat model of eleven named classes, with formal conformance levels. Covers: pre-execution interception, context accumulation, intent-alignment evaluation, five authorization decision types, tamper-evident receipts, cryptographic identity binding. Leaves open: what would make a particular decision correct; identity lifecycle before and after the action; maturity staging. Its requirements describe interception at one agent's control plane. v2.0 is stated to introduce multi-agent coordination requirements. Primary sources: aarm.dev/spec · arXiv:2602.09433 . Full mapping: Governed Autonomy and AARM . SCIM Agent Governance Extension IETF individual Internet-Draft, Informational, July 2026. Expires 27 January 2027. Extends the SCIM Agent resource type with a lifecycle state model grounded in ISO/IEC 24760-1, an autonomy classification, a validity window and credential discovery. The only document surveyed here that is still open for comment. Covers: provisioning, lifecycle state, autonomy class, credential discovery for agent identities. Leaves open, explicitly: action-level authorization is ruled out of provisioning on the grounds that fine-grained agent authorization belongs in the authorization layer; tenant and delegation scope are deferred entirely, with the draft stating that a binding can follow once cross-protocol semantics exist. Primary source: datatracker.ietf.org . Full mapping: Governed Autonomy and SCIM Agent Governance . Careful Adoption of Agentic AI Services Six national cyber agencies, April 2026. The first multi-nation government guidance written specifically for agentic AI. Sorts risk into five categories and is the most prescriptive control-level document published to date. Covers: procurement and adoption controls for organisations buying agentic services. Leaves open: architecture. It is a control catalogue, and states which controls to apply rather than where each lives or which must hold simultaneously. Full mapping: Governed Autonomy and CISA guidance . OWASP Top 10 for Agentic Applications 2026 OWASP, 2026. Ten ranked failure modes drawn from more than one hundred contributors. The broadest community statement on agentic risk, and the most widely read document in this list. Covers: ranked, named failure modes with practitioner framing. Leaves open: conformance. A ranked risk list is a checklist, not a testable requirement set. Full mapping: Governed Autonomy and the OWASP Agentic Top 10 . NIST AI Risk Management Framework NIST. The canonical enterprise vocabulary for AI risk, written before agents could act, plus the Generative AI Profile. A NIST AI Agent Standards Initiative was launched in February 2026 naming agent security and identity as core pillars. Covers: organisational risk governance vocabulary and process. Leaves open: agent-specific control overlays remain unpublished, so enterprises deploying agents today are working ahead of their own risk framework. Full mapping: Governed Autonomy and the NIST AI RMF . Open specifications and reference implementations Agent Control Standard Open standard, MIT licensed, announced May 2026. Standardised middleware hooks, runtime policy interfaces and interoperability mechanisms for governing agents across frameworks. Hooks fire when an agent receives input, calls a tool, transitions from planning to execution, stores a memory, executes code or invokes a sub-agent; policy evaluation returns allow, deny or modify before the action reaches production systems. Covers: cross-framework interception points and an inline verdict model, with reference implementations. Leaves open: what policy should say, and the delegation question at sub-agent invocation, which it hooks but does not govern. Open Agent Governance Specification Vendor-published open specification, 2026. Five primitives: deterministic identity, declarative policy, runtime enforcement, structured audit evidence, and cryptographic verification. Covers: a primitive set that maps closely onto identity, policy, enforcement and audit. Leaves open: multi-agent delegation, maturity staging, and standing intervention rights. Agent Governance Toolkit MIT licensed, 2026. Ten formal RFC 2119 specifications with a published conformance test suite, addressing runtime enforcement against the OWASP agentic risk set. Covers: testable specifications with executable conformance tests, which is rare in this field and worth noting. Leaves open: the same delegation boundary; the specifications govern enforcement within a deployment. Research artifacts DEMM-Bench — governance-evidence sufficiency Preprint, June 2026. arXiv:2606.20634 , DOI 10.48550/arXiv.2606.20634 . A cross-regime benchmark measuring whether agent-runtime records are sufficient to reconstruct a decision rather than merely present. Eight evidence regimes, eight decision properties, eight degradation conditions, 64 published cases. Finds that trace-present and schema-present baselines overclaim on 75% of cases, and names the failure mode the container fallacy. Covers: a measurable, falsifiable test of audit adequacy. The first of its kind. Leaves open: whether a decision was correct, as distinct from reconstructable; runtime enforcement; delegation legitimacy. Full mapping: Governed Autonomy and DEMM-Bench . Deontic policies for runtime governance Preprint, June 2026. arXiv:2606.19464 , DOI 10.48550/arXiv.2606.19464 . Stated for a 2026 IEEE symposium. A deontic policy language expressed in OWL and evaluated at runtime by a logic engine outside the model. Argues that permit and prohibit engines cover only a subset of governance, and that obligations, obligation lifecycle, dispensations, and meta-policy conflict resolution are missing from current approaches. Covers: obligations and waivers as first-class policy constructs, and states that one pipeline governs both tool invocations and agent-to-agent messages. Leaves open: mediating messages through a single engine governs traffic within one control plane; what authority survives a handoff between separately governed agents is not addressed. Hardware-rooted runtime enforcement Preprint, May 2026. arXiv:2605.17909 . A runtime enforcement architecture combining grammar-constrained decoding, CRDT-based policy synchronisation, hardware-attested execution in trusted execution environments, and machine-readable audit logging, with bounded formal verification. Relocates the policy enforcement point into the inference pipeline. Covers: the deepest enforcement mechanism published, and formalises governance latency , the interval between deciding a policy and enforcing it, putting it at 14 to 30 days for retrospective management-system regimes. Leaves open: delegation breadth. A single control plane inside one inference stack, with a hardware trust envelope narrower than most deployments. Behavioral governance via composed authorities Preprint, June 2026. arXiv:2606.30970 . A runtime governance framework evaluating each proposed action against three independent authorities, delegated authorization, owner-signed behavioral constitutions, and site action contracts, composed conservatively into a permit, review or deny verdict before execution. Covers: composition of multiple independent authority sources, which is the closest published treatment of conflicting policy sources. Leaves open: the composition is evaluated for one acting agent. Runtime governance over execution paths Preprint, 2026. arXiv:2603.16586 . Governance policies expressed and enforced over agent execution paths rather than isolated actions, addressing sequences whose individual steps are each permissible. Covers: multi-step sequence risk, which single-action interception misses. Leaves open: paths are traced within one agent's execution. Governance-first architecture for authorized autonomous operations Peer-reviewed, 2026. DOI 10.3389/frai.2026.1800407 . An architectural rather than control-catalogue treatment of authorized autonomous AI operations. Notable as one of the few peer-reviewed, DOI-bearing artifacts working at the architectural layer. Covers: architecture-level structuring of authorized autonomy. Leaves open: assessed against the delegation boundary, the same edge remains. Method and corrections Entries are added only after the primary source has been read and its URL verified. Assessments state what a document covers and what it leaves open, and are written so that a reader who disagrees can check the claim against the source in one click. Where a document is revised, the entry is re-checked against the revision rather than defended. Two standing constraints on this page. Artifacts are cited by publishing body and document identifier only, never by individual author. And a document's status is stated accurately: a preprint is called a preprint, a working-group specification is called one, and neither is upgraded to the other for rhetorical convenience. Corrections are welcome and are recorded in the changelog rather than made silently. If an entry mischaracterises your work, the assessment is wrong and should be fixed. This survey is maintained by the Governed Autonomy Institute alongside the Governed Autonomy Doctrine . The doctrine's own positions are set out separately; this page is intended to be usable independently of them, and the per-artifact mappings under Standards are where the two are explicitly related. --- # 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.6. 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 has been weakest at the architectural layer — where each control lives, which must hold simultaneously, and how far an organisation can safely extend autonomy today. That is changing: the AARM and SCIM mappings below both draw architectural boundaries, and this section records where they now reach further than a control catalogue. 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. AARM — Autonomous Action Runtime Management v1.0 A Cloud Security Alliance working group specification with a DOI: nine RFC 2119 requirements for a control plane that intercepts every agent action before it executes, against a threat model of eleven classes. The most rigorous runtime specification published to date, and the closest convergence with this doctrine's Threat Surface — all four threats appear. The mapping records what a conformant control plane still cannot answer: what would make a particular decision correct. IETF — SCIM Agent Governance Extension An early individual Internet-Draft giving provisioned agent identities a lifecycle state model grounded in ISO/IEC 24760-1 and an autonomy classification. The only document mapped here that is still open for comment. Its exclusions carry the finding: it rules action-level authorization out of provisioning, and defers delegated authority entirely on the grounds that the cross-protocol semantics for it do not yet exist. DEMM-Bench — Governance-Evidence Sufficiency A benchmark that asks whether agent-runtime records are sufficient to reconstruct a decision, rather than whether they exist. It finds that trace-present and schema-present baselines overclaim on 75% of cases, and names the failure mode the container fallacy. The mapping records the distinction that matters most here: retrospective evidence sufficiency is not a conformance verdict, and a system can score perfectly while making consistently wrong decisions, perfectly recorded. For a survey of the wider landscape, including artifacts that do not yet have a full mapping page, see the Standards Observatory . 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 AARM (Autonomous Action Runtime Management) — Governed Autonomy Doctrine URL: https://governedautonomy.org/standards/aarm/ Governed Autonomy and AARM AARM specifies where the control point goes and what it must be capable of. It does not specify what a correct decision at that control point would be. That is the difference between a mechanism and a verdict, and both are load-bearing. In February 2026 the Cloud Security Alliance Technical Working Group published Autonomous Action Runtime Management (AARM) v1.0, a system category specification under CC BY 4.0 with a DOI. It defines a control plane that intercepts, evaluates, decides on, and records every agent-initiated action before execution, independent of model, framework or environment. Nine requirements are stated in RFC 2119 language — six MUST (Core), three SHOULD (Extended) — against a threat model of eleven named classes. This page is a mapping, not a rebuttal. AARM is the most rigorous runtime-governance specification published to date, it is openly licensed, and it is testable in the way this doctrine has argued governance must be testable. On mechanism, this doctrine defers to it. Read AARM first. Where this page and the specification disagree about AARM, the specification is right. It is short, free, and precise, and it is doing something this doctrine deliberately does not: naming the implementation. What AARM establishes Six MUST requirements define the Core conformance level: Requirement What it requires Where it lands in this doctrine R1 Pre-execution interception Every agent-initiated action is intercepted before it executes; no action bypasses the control plane Enforce at Runtime , stated as a MUST. This doctrine's second Law expressed as a conformance requirement, by an independent body. R2 Context accumulation Stated intent, prior actions and task thread are maintained and available to policy evaluation at decision time Plane 3, Policy & Compliance Engine ; the mission-scoping input the Mission Definition pillar produces R3 Policy evaluation with intent alignment Each action is evaluated against both the action and its alignment with stated intent; isolated evaluation does not conform The closest published analogue to this doctrine's Intent Hijacking threat: a valid action taken for an invalid reason. R3 is the requirement that makes it detectable at all. R4 Five authorization decisions The engine must be capable of ALLOW, DENY, MODIFY, STEP_UP, DEFER Plane 2 for the effect, Plane 4 for STEP_UP. Note that STEP_UP encodes Humans Retain the Right to Intervene as a decision type rather than an escape hatch. R5 Tamper-evident receipts Every evaluated action produces a verifiable record of action, decision, timestamp and policy context Plane 4, Human Oversight, Audit & Traceability . More specific than anything this doctrine publishes on evidence form. R6 Identity binding Each receipt is cryptographically bound to a uniquely identified agent, supporting non-repudiation Agents Are Identities, Not Tools ; Plane 1 . The Law asserts it; R6 makes it verifiable per action. Three SHOULD requirements define Extended conformance: R7 semantic distance tracking between proposed actions and original intent over long horizons — the closest operational treatment of Behavioral Drift in any published specification; R8 telemetry export in an interoperable format; R9 least-privilege credential scoping at action time, which is Least Agency applied to credentials rather than to authority. Where the two converge AARM's eleven threat classes reproduce all four threats on this doctrine's Declaration , not three: prompt injection (T1) by name, goal hijacking (T4) as the substance of Intent Hijacking, cross-agent propagation (T7) as Cascading Failure, and intent drift (T6) as Behavioral Drift — and T6 carries its own SHOULD requirement. This is the closest convergence with any external document mapped on this site. The Threat Surface was locked in May 2026 and AARM published in February 2026; neither derives from the other. The deeper convergence is temporal. AARM's definition of runtime management insists that governance operate during execution, not in preprocessing or planning, because only then can an action be halted before its consequence is incurred. That is this doctrine's first Non-Negotiable in a specification's voice: governance must move at the speed of execution, not bookend it. Where each is thinner What AARM supplies that this doctrine does not A conformance target an implementation can be tested against and can fail, with an evidence package and a review process behind it. Named decision types. Receipt content requirements. Four implementation architectures with their trust trade-offs stated — protocol gateway, SDK instrumentation, kernel eBPF, vendor integration — which is a level of mechanism this doctrine does not publish and does not intend to. On how to build the control point , AARM is the stronger document. What this doctrine supplies that AARM does not R3 requires that policy evaluate an action against intent alignment. It does not say what alignment consists of, or what would make a particular ALLOW correct. That is deliberate and appropriate for a system category specification — and it leaves the verdict criterion open. A control plane can satisfy every one of R1–R9, return wrong decisions consistently, and remain fully conformant. RFC 001 is proposed against exactly that gap: criteria for what a correct decision would have to satisfy, stated so that an assessor can attempt to falsify a claim. Three further surfaces AARM's scope excludes by design. It governs action execution, so the identity lifecycle before and after the action — provisioning, autonomy classification, suspension, decommissioning — is out of frame; that is Plane 1 , and the live IETF work mapped at SCIM Agent Governance is addressing it from the other end. There is no maturity staging : AARM states what conformance requires, not how far an organisation can safely extend autonomy today, which is what the Maturity Model exists to answer. And intervention rights appear as STEP_UP, a decision the engine may produce, rather than as a standing human right the architecture must preserve. Multi-agent delegation: an open edge, and a closing one AARM v1.0's requirements govern what a single agent may do at the moment it acts. Cross-agent propagation appears in the threat model as T7 and a conformant implementation must address it, but the nine requirements describe interception at one agent's control plane; they do not specify what authority survives a handoff, or how trust is evaluated when one agent delegates to another. That is Trust Does Not Travel and Plane 5 . This should be stated with an expiry date on it. The specification says v2.0 will introduce multi-agent coordination requirements and add guidance for stateful long-horizon task governance. When it does, part of what this doctrine currently supplies at Plane 5 will exist as testable requirements published by a working group with a DOI, and this page will need rewriting rather than defending. That is the correct outcome. A doctrine that needs its neighbours to stay incomplete is not a doctrine. Complementary layers, not competing standards Use AARM to build and certify the control plane. Use this doctrine to decide which planes that control plane sits between, what a correct verdict at it would be, and how far autonomy can safely extend before the next requirement is met. The relationship is the one an architecture has with a component specification: the component can be conformant and the system still wrong, and no amount of component rigour closes that. Primary sources AARM v1.0 — Autonomous Action Runtime Management (Cloud Security Alliance Technical Working Group, February 2026, CC BY 4.0) arXiv:2602.09433 — the specification paper CSA AARM Technical Working Group aarm-dev/aarm — errata and contributions --- # 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 DEMM-Bench (Governance-Evidence Sufficiency) — Governed Autonomy Doctrine URL: https://governedautonomy.org/standards/demm-bench/ Governed Autonomy and DEMM-Bench Most audit requirements ask whether a record exists. DEMM-Bench asks whether the records that exist can answer a governance question about a specific decision. Those are different tests, and the second is much harder to pass. In June 2026 a benchmark paper, DEMM-Bench: A Cross-Regime Benchmark for Agent-Runtime Governance-Evidence Sufficiency , was published as a preprint ( arXiv:2606.20634 , DOI 10.48550/arXiv.2606.20634 ). Grounded in a Decision Evidence Maturity Model, it evaluates whether records emitted across eight evidence regimes are sufficient to reconstruct decision-level properties , rather than simply present. This page is a mapping, not a rebuttal. DEMM-Bench is the first published instrument to make audit adequacy falsifiable, and it lands squarely on the plane this doctrine names Human Oversight, Audit & Traceability . On how to measure whether your evidence is any good , this doctrine defers to it. A note on scope. This is a preprint benchmark, not a standards-body specification, and it should not be cited as one. Its contribution is a method and a dataset. What makes it load-bearing here is not its status but its finding. What DEMM-Bench establishes The benchmark normalises eight evidence regimes through adapters — traces, ledgers, provenance graphs, policy logs, delegation tokens, cache events, tool-firewall records, and schemas — then asks property questions over eight dimensions of a decision: actor, authority, action, policy, decision basis, resource touch, lifecycle context, and verification strength . Eight deterministic degradation conditions are applied, and performance is scored across 64 published cases. Two metrics carry the argument. Property Sufficiency Accuracy measures how often an evidence substrate genuinely answers the property question. Overclaim Rate measures how often it appears to answer and does not, and it is the primary diagnostic and the more useful of the two. The headline result is the reason this page exists. Trace-present and schema-present baselines overclaim on 75% of cases ; ledger-present overclaims on 50%. Three quarters of the time, having the trace is mistaken for being able to answer the question. The paper names this failure mode the container fallacy : treating the presence of an evidence container as an answer to a governance question. Where the two converge The container fallacy is this doctrine's own argument, arrived at independently and applied to the audit plane. This site has held from its Declaration onward that a definition you cannot test is marketing and a standard you can fail is a discipline. DEMM-Bench makes the same move one layer down: a log you cannot fail is not evidence, it is furniture. The convergence is not vocabulary. It is the same epistemic standard applied to a surface this doctrine had asserted rather than measured. The eight properties also map cleanly onto the architecture, which is worth stating because it is not a coincidence. Both documents are decomposing the same object. DEMM property Where it lands in this doctrine Actor Agents Are Identities, Not Tools ; Plane 1 . Reconstructing which agent acted presupposes the agent was an identity when it acted. Authority Plane 1 for the grant, Plane 5 for what survives a handoff. See the open edge below. Action and resource touch Plane 2, Execution & Tool Governance Policy and decision basis Plane 3, Policy & Compliance Engine . Decision basis is the harder of the two and the one substrates most often fail. Lifecycle context Plane 1 ; the provisioning and decommissioning states the SCIM extension is specifying from the identity end. Verification strength Plane 4 , and the closest published treatment of what this doctrine means by traceability that can be relied on. Where each is thinner What DEMM-Bench supplies that this doctrine does not A measurable test. This doctrine requires that agent behaviour be auditable and that oversight be exercisable; it does not say how an organisation would discover that its audit trail cannot actually support either. DEMM-Bench does, with a dataset, construction-oracle labels, baselines, adapters, and a reproducible score. It also supplies the more uncomfortable half: a number for how often practitioners believe they have evidence and do not. That is a contribution this doctrine should adopt rather than restate. What this doctrine supplies that DEMM-Bench does not The distinction here is precise and it matters more than it first appears, so it is stated plainly rather than left to inference. DEMM-Bench scores retrospective evidence sufficiency. It does not issue a conformance verdict. It asks: given what was recorded, can an investigator reconstruct who acted, under what authority, on what basis? That is a forensic question, asked after the fact, about one decision. It does not ask whether the decision was correct , whether the governing policy was adequate, or whether the implementation that produced it conforms to any standard. A system can achieve a perfect Property Sufficiency Accuracy score while making consistently wrong decisions, perfectly recorded. RFC 001 is proposed against the other question: criteria for what a correct decision would have to satisfy, stated so an assessor can attempt to falsify a claim. Reconstructability is a precondition for that assessment, not a substitute for it. Both are needed, they are not the same instrument, and a reader who meets DEMM-Bench first will reasonably assume the ground is already covered. Two further surfaces sit outside the benchmark's frame by design. There is no maturity staging : DEMM-Bench measures the evidence a system produces today, not how far autonomy can safely be extended given that evidence, which is what the Maturity Model exists to answer. And it is an evaluation instrument, not a control . It scores substrates after they exist and specifies nothing about enforcing anything at runtime, which is Law 2 . Multi-agent delegation: still open The benchmark's authority property is retrospective attribution, establishing from the record under what authority an actor acted. It is not a treatment of what authority survives when one agent delegates to another at runtime, and the benchmark does not claim it is. Delegation tokens appear as one of the eight evidence regimes, so DEMM-Bench can score whether a delegation was recorded legibly . Whether the delegation was legitimate , and what scope should have travelled with it, remains outside the frame. That is Trust Does Not Travel and Plane 5 . It is now one of six independent published artifacts that govern single-agent runtime behaviour and leave cross-agent delegated authority open. At some point a gap that survives six independent attempts stops being an oversight and starts being a research problem. The Standards Observatory tracks which artifacts have reached it. Complementary instruments, not competing ones Use DEMM-Bench to find out whether your agent-runtime evidence can answer a governance question at all. Use this doctrine to decide which questions must be answerable, at which plane, and how far autonomy may extend before the next one must be. An evidence substrate can be sufficient and the governance it evidences still wrong. Measuring the record does not adjudicate the decision. Primary sources arXiv:2606.20634 , DEMM-Bench: A Cross-Regime Benchmark for Agent-Runtime Governance-Evidence Sufficiency (preprint, June 2026) DOI 10.48550/arXiv.2606.20634 Mapped 2 September 2026 against the June 2026 preprint. If the benchmark is revised or published at a venue, this page is re-checked against the revision rather than defended. --- # 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 . No floor: 212 actions carry no tier The timing gap above is not the Generative AI Profile's only structural property worth naming. The profile's 212 suggested actions carry no minimum viable subset, no tiering by organizational size or risk exposure, and no companion Playbook of the kind the base AI RMF has. A public comment on the June 2024 draft , from UC Berkeley's Center for Long-Term Cybersecurity, recommended NIST designate a prioritized minimum tier; the final document did not adopt the recommendation. An organization deploying its first generative AI system receives the same 212-item, unranked list as one operating at frontier scale. That gap has a direct answer in this doctrine. The Maturity Model exists precisely to replace a flat, one-size list with a sequence: what an organization must require now, at its current governance maturity, versus what it defers, rather than treating every control as equally load-bearing from day one. Where the RMF's four functions supply the enterprise risk vocabulary and this doctrine supplies the runtime layer (below), the Maturity Model supplies what a 212-item undifferentiated list cannot: an order of operations. 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) UC Berkeley Center for Long-Term Cybersecurity, public comment on the AI 600-1 draft (June 2024) --- # 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 and the IETF SCIM Agent Governance Extension — Governed Autonomy Doctrine URL: https://governedautonomy.org/standards/scim-agent-governance/ Governed Autonomy and the IETF SCIM Agent Governance Extension Most documents mapped on this site are strongest in what they require. This one is most useful in what it declines to require — and in saying plainly that the semantics for it do not yet exist. In July 2026 an individual Internet-Draft, SCIM Agent Governance Extension , was submitted to the IETF. It extends the SCIM Agent resource type with governance metadata for provisioned agent identities: a lifecycle state model, an autonomy classification, an operational validity window, and a reference to credential discovery information. The lifecycle state values are grounded in the identity information lifecycle of ISO/IEC 24760-1, with one agent-specific addition. It is an early-stage individual submission, not an adopted working group document or a published RFC, and it may never become one. It is mapped here anyway, for a reason the other pages in this section cannot claim: it is open . Every other document mapped on this site is finished. This one is a live draft in a standards venue that accepts comment. Status. draft-kushwaha-scim-agent-governance-00 , Informational, dated 26 July 2026, expires 27 January 2027. Individual submission. Nothing on this page should be read as implying IETF consensus, working group adoption, or endorsement of this doctrine. What the draft establishes Three of its provisions matter to this doctrine directly: Provision What it does Where it lands in this doctrine Lifecycle state model Replaces a boolean active flag with a state set grounded in ISO/IEC 24760-1: distinguishing reversible suspension from terminal decommissioning, freezing an agent during investigation while preserving evidence, and recording permitted transitions Plane 1, Agent Identity & Lifecycle , almost exactly. Plane 1 was renamed from "Identity & Access Control" precisely because lifecycle, not access, is the governed property. Autonomy classification An attribute recording how autonomous a provisioned agent is, carried on the identity record itself Agents Are Identities, Not Tools , and the graded reading of autonomy the Maturity Model depends on. Autonomy as an attribute of a registered identity is the doctrine's first Law in schema form. Operational validity window A bounded period over which the agent identity is valid Least Agency in the time dimension — authority that expires rather than persisting until revoked The convergence worth naming is not any single attribute. It is that a standards venue is now treating an autonomous agent as a provisioned identity with a governed lifecycle rather than as a configured tool. That is this doctrine's first Law, and this is the first time it has appeared in a standards-track document rather than a vendor specification or a preprint. The exclusions are the substance The draft is unusually explicit about what it refuses to carry, and each refusal draws a boundary this doctrine also draws. Action-level authorization is out of scope Attributes enumerating permitted or denied actions per tool are ruled out as authorization policy rather than provisioning metadata; the draft states that fine-grained agent authorization belongs in the authorization layer, and notes that deny-list constructions in particular create false assurance through incomplete enumeration. That is the provisioning/runtime boundary this doctrine draws between Plane 1 and Planes 2 and 3 , arrived at independently and for the same reason. It is also the clearest external statement of the argument the doctrine makes against identity systems as a governance substitute (see the IAM comparison ): the identity layer knowing an agent is authorized is not the same as anything knowing that what the agent is doing right now is sanctioned. The draft agrees, and declines to pretend otherwise. Delegated authority is deferred, and the reason is stated This is the finding. Attributes describing where an agent may operate and under whose delegated authority are acknowledged as real enterprise concerns, and then explicitly deferred: they are not local to SCIM, because to be useful they must be legible across provisioning, federation and authorization protocols at once. The draft points at OAuth 2.0 Token Exchange (RFC 8693) for delegation at token time, and at the IETF WIMSE working group for cross-system workload identity context, and concludes that a SCIM binding can follow once cross-protocol semantics exist . Read that last clause carefully. A standards document is stating, in the venue where such semantics would be defined, that the semantics for cross-system delegated authority between agents do not yet exist . That is Trust Does Not Travel and Plane 5, Multi-Agent Trust & Delegation — described here not as this doctrine's assertion but as an acknowledged open problem, by a party with no interest in this doctrine's position. Plane 5 exists because authority granted to one agent does not automatically remain valid when that agent hands work to another. The draft reaches the same conclusion from the opposite direction: it cannot record delegation scope on an identity, because there is nothing coherent across protocols to record. Where each is thinner What the draft supplies that this doctrine does not Schema. Plane 1 states that agents are first-class identities with governed lifecycles; it does not define attribute names, value sets, or permitted state transitions, and does not intend to. The draft supplies exactly that, anchored to an existing ISO identity lifecycle standard and to a provisioning protocol enterprises already run. If Plane 1 is ever implemented in a real identity platform, it will be through work of this kind, and this doctrine defers to it on schema. What this doctrine supplies that the draft does not Everything after provisioning. The draft governs the identity record; it explicitly does not govern the action, the verdict, the audit evidence, or the human's right to intervene mid-mission. It has no view on which controls must hold simultaneously for a single agent action to be sanctioned, and no maturity model. Those are the other four Planes , and the runtime half is where specifications such as AARM are working. A provisioned agent with a correct lifecycle state and an accurate autonomy classification can still take an unsanctioned action one second later. What this suggests about the shape of the problem Four independent efforts now specify how a single agent's runtime actions are controlled. This draft specifies how a single agent's identity is provisioned and retired. Between them they cover Planes 1 through 4 with increasing rigour. All of them stop at the same place, and this draft is the only one that says so explicitly: what happens to authority when one agent hands work to another is unspecified, and the primitives to specify it are not agreed. That is a convergent finding, not a competitive one. It suggests Plane 5 is not an artifact of this doctrine's architecture but a genuine gap in the field, and that the venues most likely to close it are WIMSE and the OAuth delegation work the draft names. Primary sources draft-kushwaha-scim-agent-governance-00 — SCIM Agent Governance Extension (IETF Internet-Draft, Informational, 26 July 2026) RFC 8693 — OAuth 2.0 Token Exchange , cited by the draft for delegation at token time RFC 7643 — SCIM Core Schema IETF WIMSE working group — cross-system workload identity context --- # Doctrine Status: What Is Settled and What Is Moving — Governed Autonomy Doctrine URL: https://governedautonomy.org/status/ What Is Settled and What Is Moving A status map of the doctrine's core constructs, from those that have not changed since first publication to a proposal that is still being tested. Last updated 15 September 2026, against doctrine v3.6. Placements move only when a changelog entry, a standards mapping or an RFC revision gives a reason for them to move. Why this page exists. A standard that never records what is unsettled asks to be trusted rather than checked. This page does the opposite. It takes eight constructs of the doctrine and places each one by how much it has moved, with the evidence for the placement written into the figure. A reader who disagrees with a placement can point at the evidence line and say why. What it is not. This is a statement about the text of the doctrine and its published revisions. It is not a claim about adoption, and it is not a ranking of importance. Law 1 sits in the vexed column because its mechanism is unspecified, not because the principle is in doubt. AAAWgmp1bWIAAAAeanVtZGMycGEAEQAQgAAAqgA4m3EDYzJwYQAAABZcanVtYgAAAEdqdW1kYzJtYQARABCAAACqADibcQN1cm46YzJwYTpkZGNlM2JhZC0wZjMzLTRiNzAtYTFkYi02Mjk1YTlkNTRiMDQAAAADl2p1bWIAAAApanVtZGMyYXMAEQAQgAAAqgA4m3EDYzJwYS5hc3NlcnRpb25zAAAAALxqdW1iAAAARGp1bWRjYm9yABEAEIAAAKoAOJtxE2MycGEuaW5ncmVkaWVudC52MwAAAAAYYzJzaCan0XzyAPlN7QknAutKagsAAABwY2JvcqNpZGM6Zm9ybWF0bWltYWdlL3N2Zyt4bWxqaW5zdGFuY2VJRHgseG1wOmlpZDpkMTFlMzAyOC1jYzEzLTQyYjEtOThlNS05NGQ5YjZkMzAwMjNscmVsYXRpb25zaGlwaHBhcmVudE9mAAAB4mp1bWIAAABBanVtZGNib3IAEQAQgAAAqgA4m3ETYzJwYS5hY3Rpb25zLnYyAAAAABhjMnNovWplPMPHXMt2hHzNkpedUgAAAZljYm9yomdhY3Rpb25zgqJmYWN0aW9ua2MycGEub3BlbmVkanBhcmFtZXRlcnOha2luZ3JlZGllbnRzgaJjdXJseC1zZWxmI2p1bWJmPWMycGEuYXNzZXJ0aW9ucy9jMnBhLmluZ3JlZGllbnQudjNkaGFzaFgg/lu2V8nl3LuDTl0JlwhFqFvuw3oUtCZwHdY7MmYTARGkZmFjdGlvbngdY29tLmFudGhyb3BpYy5jbGF1ZGUucHJvdmlkZWRqcGFyYW1ldGVyc6F4H2NvbS5hbnRocm9waWMub3JpZ2luLWNvbmZpZGVuY2VndW5rbm93bmtkZXNjcmlwdGlvbnhmQ2xhdWRlIHByb3ZpZGVkIHRoaXMgZmlsZSBhdCB0aGUgcmVxdWVzdCBvZiBhIHVzZXIgYW5kIG1heSBoYXZlIGNyZWF0ZWQgb3IgbW9kaWZpZWQgdGhlIGZpbGUgY29udGVudHMubXNvZnR3YXJlQWdlbnShZG5hbWVmQ2xhdWRlcmFsbEFjdGlvbnNJbmNsdWRlZPUAAADIanVtYgAAAEBqdW1kY2JvcgARABCAAACqADibcRNjMnBhLmhhc2guZGF0YQAAAAAYYzJzaM/ZdxCjjX9fBx+gnLciCUkAAACAY2JvcqVjYWxnZnNoYTI1NmNwYWRMAAAAAAAAAAAAAAAAZGhhc2hYIOvCyCiZI+53+8MZH2/N4GahGG/3ptqcUU8h/58Ik/xWZG5hbWVuanVtYmYgbWFuaWZlc3RqZXhjbHVzaW9uc4GiZXN0YXJ0GQEQZmxlbmd0aBkeBAAAAj5qdW1iAAAAJ2p1bWRjMmNsABEAEIAAAKoAOJtxA2MycGEuY2xhaW0udjIAAAACD2Nib3KlY2FsZ2ZzaGEyNTZpc2lnbmF0dXJleE1zZWxmI2p1bWJmPS9jMnBhL3VybjpjMnBhOmRkY2UzYmFkLTBmMzMtNGI3MC1hMWRiLTYyOTVhOWQ1NGIwNC9jMnBhLnNpZ25hdHVyZWppbnN0YW5jZUlEeCx4bXA6aWlkOjI3YmQ2ZWYxLThkOTAtNDE5Ni1iYzRiLTc0ZTdiZDY0ZTViMHJjcmVhdGVkX2Fzc2VydGlvbnODomN1cmx4LXNlbGYjanVtYmY9YzJwYS5hc3NlcnRpb25zL2MycGEuaW5ncmVkaWVudC52M2RoYXNoWCD+W7ZXyeXcu4NOXQmXCEWoW+7DehS0JnAd1jsyZhMBEaJjdXJseCpzZWxmI2p1bWJmPWMycGEuYXNzZXJ0aW9ucy9jMnBhLmFjdGlvbnMudjJkaGFzaFggx4+f2jMv6CED3Bd57Q3zMu9Uy+6ltLMOLOvE/YHIdnqiY3VybHgpc2VsZiNqdW1iZj1jMnBhLmFzc2VydGlvbnMvYzJwYS5oYXNoLmRhdGFkaGFzaFggKxjiiFGsaKnSThmsmKW8Dm1Q9uumpwJzSLMFedbFhOt0Y2xhaW1fZ2VuZXJhdG9yX2luZm+jZG5hbWVvQW50aHJvcGljIEZpbGVzZ3ZlcnNpb25lMS4wLjBrc3BlY1ZlcnNpb25lMi40LjAAABA4anVtYgAAAChqdW1kYzJjcwARABCAAACqADibcQNjMnBhLnNpZ25hdHVyZQAAABAIY2JvctKEWQISogEmGCFZAgowggIGMIIBjaADAgECAhRA5aAK7sI50L64g/oGQgU9Z1UTADAKBggqhkjOPQQDAzBJMRcwFQYDVQQKEw5BbnRocm9waWMsIFBCQzEuMCwGA1UEAxMlQW50aHJvcGljIENvbnRlbnQgQ3JlZGVudGlhbHMgUm9vdCBDQTAeFw0yNjA4MDcxODQzNTZaFw0yODA4MDYxOTQzNTZaMEQxFzAVBgNVBAoTDkFudGhyb3BpYywgUEJDMSkwJwYDVQQDEyBBbnRocm9waWMgQ2xhdWRlIENvbnRlbnQgU2lnbmluZzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJh6CmvLUBgFFNU0vUKlOVtE6djd17L5SuwX0LemFisBM3dkd/3cyjxFA3Qo5S46fX0/ihY0VZ7mfb9KF703t5OjWDBWMA4GA1UdDwEB/wQEAwIHgDAVBgNVHSUEDjAMBgorBgEEAYPoXgIBMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUzlHiBIFOZFsj+OPEz5o+nMHXXMIwCgYIKoZIzj0EAwMDZwAwZAIwMXMdFJ4BetLLVY7ORuE9noqbbAZOZn/aArXyTwFAZfKrPzxF2vPoJNf1+UCdg1XGAjBwX1zd9WGqYkqmL5SFqw1QySjr1zJfpJM9+1rdDwSPLMOPOjKuiXjoU/pUUeG9RwmhY3BhZFkNngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPZYQMnbRwUo153anxByfFooADdq0LzesxddjARYXiSUsD0TZ9FIVsfmWigGZNpeji5+tFNI7aWMIf26PNh2Cy58o4I= Governed Autonomy Doctrine stability map Eight constructs of the doctrine arranged from most settled on the left to least settled on the right, with evidence for each placement. A table with the same content follows the figure. Which points are set in stone, and which are still moving The doctrine's core constructs, arranged from most settled to least settled, with the evidence for each placement drawn from the changelog, the Standards pages and RFC 001. 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. SETTLED Unchanged since first published. STABLE Agreed in principle; one detail still being specified. VEXED The principle is held; how to do it is an open question. EVOLVING Rewritten at least once; likely again. UNSTABLE Proposed, not yet doctrine; still being tested. implementation friction LAW 2 Enforce at Runtime Controls act while the agent is working, not only before it starts. Approval given up front cannot foresee choices an agent makes mid-task. Unchanged since v1.5 (Apr 2026). v3.6 names the primitives it builds on: NIST SP 800-207 policy decision and enforcement points. LAW 3 Governance Must Span Systems One agent touches identity, infrastructure, security and data systems at the same time. Oversight has to cover all of them together. Unchanged since v1.5 (Apr 2026). Cross-mapped to CISA, OWASP and NIST on the Standards pages. LAW 5 Humans Retain the Right to Intervene People must be able to inspect and stop an agent at every layer. A design requirement, not a fallback for when things go wrong. Principle unchanged. Gap logged in v3.2: the stakes tiers at which intervention is mandatory. RFC 001 proposes Action Tiering to close it. NON-NEGOTIABLE 3 Least Agency An agent gets no more authority than its mission demands: limits on what it may decide and do, not only on what it may access. Shared vocabulary. OWASP used the term publicly in Dec 2025; the Standards pages document it as convergence, not coinage. LAW 1 Agents Are Identities, Not Tools Treat every agent like a person on the payroll: provisioned, credentialed, accountable, and governed with the same rigor as a human user. Field convergence on durable identities is recorded on the Observatory. Gap logged in v3.2: the identity and lifecycle mechanism is unspecified. principle held, mechanism open THE OPEN QUESTION provisioned how? bound to whom? revoked when? LAW 4 RENAMED v3.0 · v3.6 Trust Does Not Travel When one agent hands work to another, its authority does not go with it. Every handoff needs its own authorization. Renamed and widened in v3.0 (May 2026). Delegation wording aligned with RFC 001 C5.2 in v3.6: authority is granted at the receiving node, not transferred. ARCHITECTURE REVISED v3.0 · v3.6 The Five Planes Where the controls live: agent identity and lifecycle, execution and tools, policy, human oversight and audit, multi-agent trust. 4 to 5 planes in v3.0; Plane 1 renamed. v3.6 restated Planes 2 and 3 in policy-decision terms and revised Plane 4's evidence requirement. RFC 001 · PROPOSED FOR v4 The Conformance Layer Twenty-nine testable criteria for checking whether a real system actually follows the doctrine, not just claims to. Not yet doctrine. Rev 1 review found criteria that could not all hold at once. Rev 2 open to 31 Oct 2026. MOST SETTLED LEAST SETTLED HOW TO READ Solid fill settled, not open for revision Firm outline stable, agreed in principle Dashed outline vexed: principle held, mechanism open Divergent arrows the open questions Ghosted layers revised over time, prior versions shown Fracture lines broke under review; being repaired Hatched ground friction where the idea meets practice Bronze signals movement; navy and ink mean stable Height above the ground line and tilt increase with instability. Sources: this site's changelog, Laws, Architecture, Standards and RFC pages, doctrine v3.6, as of 15 September 2026. Eight constructs placed from most settled (left) to least settled (right). Height above the ground line and tilt increase with instability. Open the map at full size . The five labels What each status label means and how a construct earns it. Label Meaning How a construct earns it Settled Unchanged since first published. No changelog entry has altered its name, count or substance since the release that introduced it. Stable Agreed in principle; one detail still being specified. The principle is unchanged, and the changelog records an acknowledged gap or an open specification against it. Vexed The principle is held; how to do it is an open question. The principle has independent support on the Observatory , and the doctrine has recorded that it states the requirement without specifying the mechanism. Evolving Rewritten at least once; likely again. The changelog records a rename, a change in count, or a substantive rewording in more than one release. Unstable Proposed, not yet doctrine; still being tested. Published as an RFC, open for comment, and revised after review found internal contradictions. The placements The eight constructs on the map, with the evidence for each placement. Construct Status Evidence Law 2, Enforce at Runtime Settled Unchanged since v1.5 (April 2026). In v3.6 the doctrine states the primitives it builds on: policy decision and enforcement points per NIST SP 800-207. Law 3, Governance Must Span Systems Settled Unchanged since v1.5 (April 2026). Cross-mapped to CISA, OWASP and NIST guidance on the Standards pages. Law 5, Humans Retain the Right to Intervene Stable Principle unchanged. v3.2 recorded that the law asserts the right without defining the stakes tiers at which intervention is mandatory. RFC 001 proposes Action Tiering to close the gap. Least Agency (third non-negotiable) Stable Shared vocabulary. The OWASP Top 10 for Agentic Applications 2026 used the term publicly in December 2025; the OWASP mapping documents this as convergence, not coinage. Law 1, Agents Are Identities, Not Tools Vexed Field convergence on durable agent identities is recorded on the Observatory . v3.2 recorded that Plane 1 states the identity requirement without specifying mechanism: how an identity is provisioned, bound to an accountable principal, and revoked. Law 4, Trust Does Not Travel Evolving Renamed and widened in v3.0 (May 2026), when it also received its own architectural plane. In v3.6 the delegation wording on the Architecture and Framework pages was aligned with the law and with RFC 001 C5.2: authority is independently granted at the receiving node, not transferred. The Architecture, five planes Evolving Grew from four planes to five in v3.0, with Plane 1 renamed; the companion Framework grew from five pillars to six. In v3.6, Planes 2 and 3 were restated in policy-decision and policy-enforcement terms, and Plane 4's evidence requirement was revised to a reconstructable, tamper-evident transaction record. The Conformance Layer, RFC 001 Unstable Not yet doctrine. Adversarial review of revision 1 found three places where its criteria could not all hold at once. Revision 2 is open for comment through 31 October 2026, and the v3.6 changelog records that a revision 3 will carry the structural changes from the September 2026 assessment. What the map does not show Three things are deliberately left off. The Maturity Model was revised in v3.6 and would sit in the evolving column; it is a companion instrument rather than a construct of the doctrine, and RFC 001 proposes rebuilding it. The Threat Surface has not changed since v3.0 and would sit in the settled column; it is mapped entry by entry on the OWASP page . The 6 Framework Pillars track the planes they map to and would duplicate the Architecture row. How this page is maintained The map is regenerated on each doctrine release and dated. A construct moves left when a release closes the gap that held it in place, and moves right when a release records a rename, a change in count, or a contradiction found in review. The source of every placement is a page on this site, so the map can be checked against the changelog by anyone, at any time. --- # 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. The test for any control Whatever its vendor calls it: does the control mediate consequential actions, and can the governed actor bypass or disable it? A product sold as a guardrail that intercepts actions before they execute is a Plane 2 mechanism regardless of its label. A control the agent can update away, or that sits in only one system, is not governance, whatever it is called. What makes a control part of Governed Autonomy is that it is external to the agent, cannot be modified by the agent, and spans the systems the agent touches ( Law 2 , Law 3 ). --- # 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 . Attribute-based access control can evaluate a requested operation (NIST SP 800-162) and Zero Trust makes that evaluation continuous (NIST SP 800-207); what neither carries into the decision is the agent's mission, its action history across other systems, or the authority it was delegated. 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. The test for any control Whatever its vendor calls it: does the control mediate consequential actions, and can the governed actor bypass or disable it? A product sold as a guardrail that intercepts actions before they execute is a Plane 2 mechanism regardless of its label. A control the agent can update away, or that sits in only one system, is not governance, whatever it is called. What makes a control part of Governed Autonomy is that it is external to the agent, cannot be modified by the agent, and spans the systems the agent touches ( Law 2 , Law 3 ). --- # 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. The test for any control Whatever its vendor calls it: does the control mediate consequential actions, and can the governed actor bypass or disable it? A product sold as a guardrail that intercepts actions before they execute is a Plane 2 mechanism regardless of its label. A control the agent can update away, or that sits in only one system, is not governance, whatever it is called. What makes a control part of Governed Autonomy is that it is external to the agent, cannot be modified by the agent, and spans the systems the agent touches ( Law 2 , Law 3 ). --- # 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 and auditable, and reversible where reversibility is possible; and the human role shifts from approving individual transactions to governing behavior. The doctrine's own position is that irreversible actions exist and require authorization before they commit (see RFC 001 , Action Tiering). 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 Per-action policy evaluation already exists as a primitive: attribute-based access control evaluates a requested operation against subject, object and environment (NIST SP 800-162), and Zero Trust requires that every authorization be dynamic and strictly enforced at a policy decision point (NIST SP 800-207). What the enterprise stack does not deploy is: A policy decision that evaluates an agent's action against its mission, its cross-system history and its delegated authority, enforced at a point the agent cannot bypass A continuous human oversight interface able to inspect, interrupt and override at any layer Governed Autonomy specifies that decision and the point at which it must be enforced. 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. ---