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 enumerates all permitted action classes.
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 all authorized stakeholders.
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 enforcement.
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 permitted actions.
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 action classes.
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 scope restrictions.
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, supervised, or escalation-required).
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 operational scope.
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 attempts to expand operational scope.
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 defined scope.
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 interaction sequences.
The system SHALL prevent scope expansion through conversational manipulation or multi-turn interaction sequences.
Boundary specifications SHALL include explicit version compatibility requirements with dependent systems.
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 entity, the attempted action, and the enforcement decision.
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 conditions.
Boundary enforcement SHALL function correctly during system degradation and partial failure conditions.
The system SHALL support dynamic boundary adjustment only through authorized, audited configuration changes.
The system SHALL support dynamic boundary adjustment only through authorized, audited configuration changes.
Boundary specifications SHALL be testable through automated validation suites without manual interpretation.
Boundary specifications SHALL be testable through automated validation suites without manual interpretation.
The system SHALL enforce operational boundaries consistently across all input channels and interfaces.
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 certification level.
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-actions.
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 Environment Specification (RES) describing infrastructure, configuration, model version, dependency versions, simulated input distributions, and known deviations from production conditions.
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 production-equivalent behavior for all in-scope ACRs, with documented justification for any identified deviations.
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) SHALL trigger re-evaluation of affected ACRs. The vendor SHALL define and document the threshold for "material change" prior to Platform Certification.
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.