Autonomy Scope Definition
Summary#
Operational boundaries, enforcement, and testing of autonomous system scope
Risk Rationale#
Linked ACR Controls#
The following Autonomous Compliance Requirements are assigned to this domain. Each ACR defines a specific, testable control with its own evaluation method, classification, and evidence requirements.
The system SHALL maintain a machine-readable operational boundary specification document that enumer
The system SHALL maintain a machine-readable operational boundary specification document that enumerates all permitted action classes.
The system SHALL maintain a human-readable operational boundary specification document accessible to
The system SHALL maintain a human-readable operational boundary specification document accessible to all authorized stakeholders.
All permitted action classes SHALL be enumerated with specificity sufficient for automated enforceme
All permitted action classes SHALL be enumerated with specificity sufficient for automated enforcement.
All restricted and prohibited action classes SHALL be explicitly defined with equal specificity to p
All restricted and prohibited action classes SHALL be explicitly defined with equal specificity to permitted actions.
The system SHALL reject or escalate any action request that falls outside its defined permitted acti
The system SHALL reject or escalate any action request that falls outside its defined permitted action classes.
Tool, API, and resource access policies SHALL be documented including conditions, rate limits, and s
Tool, API, and resource access policies SHALL be documented including conditions, rate limits, and scope restrictions.
The system's decision authority level SHALL be documented for each action class (autonomous, supervi
The system's decision authority level SHALL be documented for each action class (autonomous, supervised, or escalation-required).
Geographic constraints on system operation SHALL be defined and enforced where applicable.
Geographic constraints on system operation SHALL be defined and enforced where applicable.
Temporal constraints on system operation SHALL be defined and enforced where applicable.
Temporal constraints on system operation SHALL be defined and enforced where applicable.
Contextual constraints on system operation SHALL be defined and enforced where applicable.
Contextual constraints on system operation SHALL be defined and enforced where applicable.
A versioned boundary specification document SHALL be updated with each system change affecting opera
A versioned boundary specification document SHALL be updated with each system change affecting operational scope.
Boundary enforcement SHALL be tested under adversarial conditions including prompt injection attempt
Boundary enforcement SHALL be tested under adversarial conditions including prompt injection attempts to expand operational scope.
Runtime enforcement mechanisms SHALL actively prevent boundary violations, not merely log them.
Runtime enforcement mechanisms SHALL actively prevent boundary violations, not merely log them.
The system SHALL define and document its behavior when it encounters an action request outside its d
The system SHALL define and document its behavior when it encounters an action request outside its defined scope.
Boundary violations SHALL be distinguishable from legitimate escalation requests in system logs.
Boundary violations SHALL be distinguishable from legitimate escalation requests in system logs.
The system SHALL prevent scope expansion through conversational manipulation or multi-turn interacti
The system SHALL prevent scope expansion through conversational manipulation or multi-turn interaction sequences.
Boundary specifications SHALL include explicit version compatibility requirements with dependent sys
Boundary specifications SHALL include explicit version compatibility requirements with dependent systems.
The system SHALL log all boundary violation attempts with full context including the requesting enti
The system SHALL log all boundary violation attempts with full context including the requesting entity, the attempted action, and the enforcement decision.
Boundary enforcement SHALL function correctly during system degradation and partial failure conditio
Boundary enforcement SHALL function correctly during system degradation and partial failure conditions.
The system SHALL support dynamic boundary adjustment only through authorized, audited configuration
The system SHALL support dynamic boundary adjustment only through authorized, audited configuration changes.
Boundary specifications SHALL be testable through automated validation suites without manual interpr
Boundary specifications SHALL be testable through automated validation suites without manual interpretation.
The system SHALL enforce operational boundaries consistently across all input channels and interface
The system SHALL enforce operational boundaries consistently across all input channels and interfaces.
Boundary specification documents SHALL undergo periodic review at intervals defined by the certifica
Boundary specification documents SHALL undergo periodic review at intervals defined by the certification level.
The system SHALL prevent indirect boundary expansion through chained tool calls or delegated sub-act
The system SHALL prevent indirect boundary expansion through chained tool calls or delegated sub-actions.
For systems seeking Platform Certification, the vendor SHALL maintain a documented Reference Environ
For systems seeking Platform Certification, the vendor SHALL maintain a documented Reference Environment Specification (RES) describing infrastructure, configuration, model version, dependency versions, simulated input distributions, and known deviations from production conditions.
The evaluating AVB SHALL attest in writing that the Reference Environment is representative of produ
The evaluating AVB SHALL attest in writing that the Reference Environment is representative of production-equivalent behavior for all in-scope ACRs, with documented justification for any identified deviations.
Material changes to the platform (new model version, architectural change, dependency version change
Material changes to the platform (new model version, architectural change, dependency version change) SHALL trigger re-evaluation of affected ACRs. The vendor SHALL define and document the threshold for "material change" prior to Platform Certification.