PRD-STD-009: Autonomous & Multi-Agent Governance
Standard ID: PRD-STD-009
Version: 1.0
Status: Active
Compliance Level: Level 2 (Managed)
Effective Date: 2026-02-18
Last Reviewed: 2026-02-18
This page is the normative source of requirements for this control area. Use it to define policy, evidence expectations, and audit/compliance criteria.
For implementation and rollout support:
- Execution plan: Apply-Ready Rollout Kit
- Adoption sequencing: Production Rollout Paths
- Hands-on tutorials: Production Tutorials & Starter Guides
- Runnable repos / apply paths: Reference Implementations
Use the Compliance Level metadata on this page to sequence adoption with other PRD-STDs.
1. Purpose
This standard defines mandatory governance controls for autonomous and multi-agent AI workflows in software engineering. It extends the PRD-STD series from AI-assisted single-session usage to orchestrated agent execution where agents can plan, edit, and propose changes across multiple steps.
Without explicit controls, multi-agent workflows increase risk of architecture drift, policy bypass, hidden decision chains, and weak accountability. PRD-STD-009 ensures autonomous capabilities operate within enforceable boundaries, with clear human ownership and auditable evidence.
2. Scope
This standard applies to:
- Any AI workflow where one or more agents can execute multi-step actions with limited autonomy
- Agent-driven tasks that can modify code, infrastructure, configuration, tests, or delivery workflows
- Orchestrated role-agent handoffs (for example: product -> developer -> QA -> security)
- All environments where agent outputs can affect production-bound artifacts
This standard does not replace existing requirements in PRD-STD-001 through PRD-STD-008. It adds controls specific to autonomous and multi-agent operation.
3. Definitions
| Term | Definition |
|---|---|
| Autonomous Agent | An AI agent that can execute multiple actions without human intervention between each action |
| Role-Agent | An agent profile scoped to one organizational role with a defined contract |
| Agent Contract | A formal specification of allowed inputs, outputs, permissions, and escalation paths |
| Orchestrator | The control layer routing work among role-agents and enforcing policy checkpoints |
| Handoff Artifact | Structured output transferred from one role-agent to another or to a human approver |
| Agent Run Record | Execution log containing agent identity, prompt reference, actions, outputs, and timestamps |
4. Requirements
4.1 Identity, Ownership, and Scope
REQ-009-01: Every autonomous or role-agent execution MUST use a unique agent-id mapped to a named human owner role.
REQ-009-02: Every agent MUST execute under a documented agent contract that defines:
- allowed inputs and data sources
- allowed outputs
- forbidden actions
- required checks
- escalation path and approvers
REQ-009-03: Agents MUST operate under least-privilege access. Agent credentials MUST NOT grant direct protected-branch merge privileges.
REQ-009-04: Agents MUST NOT create, approve, and merge the same change path without human intervention.
4.2 Orchestration and Handoff Controls
REQ-009-05: Multi-agent workflows MUST use an orchestrator that enforces stage order, role boundaries, and stop conditions.
REQ-009-06: Every handoff between agents (or agent to human) MUST include a structured handoff artifact containing:
- source references
- assumptions
- risk annotation
- next owner decision request
REQ-009-07: Autonomous execution loops MUST enforce a maximum iteration threshold and MUST fail closed on threshold breach.
REQ-009-08: Architecture-impacting decisions (patterns, boundaries, major dependencies) MUST be approved by a human reviewer at Tier 2 or higher.
REQ-009-09: Organizations SHOULD maintain reusable handoff schemas to reduce ambiguity and improve traceability.
4.3 Governance, Security, and Human Approval
REQ-009-10: All agent-produced production-bound changes MUST pass PRD-STD-002 human approval requirements.
REQ-009-11: Security and dependency controls in PRD-STD-004 and PRD-STD-008 MUST apply equally to agent-generated outputs.
REQ-009-12: Governance gate evidence for Tier 3 and Tier 4 work MUST include agent run records and handoff artifacts.
REQ-009-13: Agents MUST NOT process Restricted data unless tool deployment and controls satisfy Pillar 2 data classification requirements.
4.4 Traceability and Audit Evidence
REQ-009-14: Each agent run MUST produce an auditable run record including agent identity, model/tool version, prompt reference, action summary, and output references.
REQ-009-15: Pull requests involving agent output MUST include fields for AI-Usage, AI-Prompt-Ref, Agent-IDs, and AI-Risk-Notes.
REQ-009-15A: When governed skills are used by an agent, the agent run record or pull request metadata MUST include skill-id and skill-version in accordance with PRD-STD-017.
REQ-009-16: Agent run records and handoff artifacts MUST be retained according to Retention & Audit Evidence Policy.
4.5 Runtime Safeguards
REQ-009-17: Agent runtimes MUST enforce policy-deny defaults for unapproved actions.
REQ-009-18: Manual override of agent policy controls MUST require an approved waiver with expiration and compensating controls.
REQ-009-19: Any unauthorized action attempt by an agent MUST generate a security event and trigger review by Security and Platform owners.
4.6 Tool Execution Tiers and Elicitation
REQ-009-20: Agent runtimes MUST classify every tool into one of three execution tiers:
| Tier | Behavior | Examples |
|---|---|---|
| Auto-execute | Tool runs without pause or approval | File read, search, lint, test execution |
| Elicit | Agent pauses to ask the user a structured question before proceeding | Ambiguous requirements, design choices, risk trade-offs |
| Approve | Tool is blocked until a designated human approver grants permission | Production deploy, data deletion, refund issuance, branch merge |
REQ-009-21: Tools classified as Approve MUST NOT execute without explicit confirmation from the human owner defined in the agent contract's escalation.approver_role field.
REQ-009-22: Agents MUST be capable of elicitation — presenting structured questions with constrained options to the human operator when execution context is insufficient for a safe decision. Elicitation MUST be used instead of guessing or defaulting when:
- the agent encounters ambiguous requirements
- multiple valid implementation paths exist with materially different risk profiles
- the action would be irreversible or costly to undo
REQ-009-23: Organizations SHOULD document the tier classification for every tool in the agent contract, with a default of Approve for any unclassified tool (deny-by-default).
REQ-009-24: Elicitation interactions SHOULD be recorded in the agent run record alongside tool calls, so that human decisions are auditable.
5. Implementation Guidance
Minimum Control Stack
Teams implementing autonomous/multi-agent workflows SHOULD deploy the following baseline controls:
- Agent Registry — source of truth for
agent-id, role owner, contract version, and status. - Contract Validation — pre-run checks that block execution when contract fields are missing.
- Policy Engine — centralized allow/deny rules for actions and data access.
- Run Ledger — immutable execution records for every agent run.
- Handoff Templates — required format for cross-role output transfer.
- Gate Integration — CI checks that validate traceability fields and governance evidence.
- Skill Registry & Skill Gates — registry-backed checks that validate approved skill usage, role/environment scope, and gate binding before agent execution.
Canonical Schema Pack (Required for New Implementations)
New implementations SHOULD use the canonical schema pack to standardize contract validation and evidence portability across runtimes:
/templates/schemas/agent-contract.schema.json(AgentContract v1)/templates/schemas/hook-contract.schema.json(HookContract v1)/templates/schemas/gate-decision.schema.json(GateDecision v1)/templates/schemas/handoff-artifact.schema.json(HandoffArtifact v1)/templates/schemas/run-ledger-entry.schema.json(RunLedgerEntry v1)
Implementation companion and adaptation program hub:
Example Agent Contract Fields
agent_id: solution-architect-agent
role_owner: solution-architect
contract_version: 1.0.0
allowed_inputs:
- architecture-decision-record
- service-topology-diagram
allowed_outputs:
- architecture-conformance-report
forbidden_actions:
- merge-to-protected-branch
- approve-own-output
required_checks:
- architecture-pattern-validation
- traceability-metadata-check
skill_policy:
registry_required: true
allow_unregistered_skills: false
required_metadata:
- skill-id
- skill-version
escalation:
approver_role: cto
Minimum Operational Metrics
Track at least:
- agent handoff completeness rate
- governance gate first-pass rate for agent-assisted submissions
- unauthorized action attempt count
- architecture conformance pass rate
- waiver count and expiration compliance
6. Exceptions & Waiver Process
Waivers are allowed only for non-security procedural controls and MUST include business justification, compensating controls, and expiration (maximum 90 days).
No waivers are permitted for:
- missing human approval of production-bound changes
- agent processing of Restricted data without approved environment controls
- bypassing security scans for agent-generated outputs
- allowing agents to self-approve and merge into protected branches
7. Related Standards
- PRD-STD-001: Prompt Engineering Standards
- PRD-STD-002: Code Review Standards
- PRD-STD-004: Security Scanning
- PRD-STD-007: Performance & Quality Gates
- PRD-STD-008: Dependency & License Compliance
- PRD-STD-017: Agent Skills Catalog Governance
- Code Provenance & Attribution
- Operating Model Lifecycle
- Skill Registry & Multi-Agent Gate Patterns
- External Standards Adaptation Program
8. Revision History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 2026-02-18 | AEEF Standards Committee | Initial release |