Operational Controls for Runtime AI Governance
Each pillar defines control objectives, enforcement patterns, evidence requirements, and verification criteria derived from the ACR Standard v1.0.1. Together they form the complete control surface of the ACR Runtime Control Plane.
Identity & Purpose Binding
Every agent must have a unique identity and a declared purpose. Constraints are tied to that purpose. The system must maintain an authoritative agent record containing agent_id, owner, purpose, risk tier, allowed tools, forbidden tools, approved data access scope, and operational boundaries.
Control Objectives
- Ensure every protected action is attributable to a single registered agent identity
- Bind execution authority to a declared purpose with enforceable scope constraints
- Prevent agents from acting outside their declared purpose without authorized manifest changes
- Maintain cryptographic proof of identity for every protected action
Control Mechanisms
- Unique agent identity with cryptographic proof
- Declared purpose with scope constraints
- Authoritative agent manifest or record
- Identity validation for every protected action
- Purpose change requires authorized control path, versioning, and audit trail
- Revocation prevents future action execution
Evidence Requirements
- •Agent registry with required fields
- •Identity validation logs
- •Manifest version history
- •Out-of-scope denial records
STRIKE Threats Addressed
Identity verification, credential validation, anti-replay controls, executor verification of control-plane-issued authority
Required at Level 2 (Enforcement) and above. Identity and purpose binding is a prerequisite for all protected action evaluation.
Behavioral Policy Enforcement
The control plane enforces policy at three boundaries: Input, Execution, and Output. Policy enforcement is machine-enforceable and runtime-executed. Documentation-only policies do not satisfy this requirement.
Control Objectives
- Enforce deterministic, machine-readable policy at every control boundary
- Ensure no protected action bypasses policy evaluation
- Maintain versioned policy definitions with traceable decision evidence
- Default to DENY when the policy engine is unavailable or indeterminate
Control Mechanisms
- Input Boundary: schema validation, prompt sanitization, injection detection, source trust
- Execution Boundary: tool allowlisting, destination restriction, parameter validation, rate limits, approval gating
- Output Boundary: PII/PHI redaction, output filtering, destination-aware release restrictions
- Deny-by-default when policy engine unavailable
- Versioned policy definitions with decision evidence
Evidence Requirements
- •Policy decision records with version, outcome, justification
- •Boundary control audit logs
- •Policy engine failure and denial records
STRIKE Threats Addressed
Payload binding, integrity verification, tamper-evident logging, rejection of altered execution requests
Input validation, injection detection, output and action constraints preventing malicious instruction reflection
Data access scoping, output filtering, redaction, destination-aware controls
Level 2 requires enforcement at Execution Boundary. Level 3 requires enforcement at all three boundaries (Input, Execution, Output).
Autonomy Drift Detection
The system detects deviations from intended role, expected patterns, or approved boundaries. Drift detection requires a defined behavioral baseline, detection signals, thresholded response criteria, and evidence of review or calibration.
Control Objectives
- Detect unauthorized or anomalous deviations from intended agent behavior
- Establish deterministic baselines before enabling unrestricted autonomous execution
- Map drift signals to documented response tiers without ad hoc interpretation
- Retain sufficient evidence to reconstruct why any response was triggered
Control Mechanisms
- Behavioral baseline established before unrestricted execution (30 days minimum or documented temporary baseline)
- Monitoring: tool usage, data access, action frequency, repeated denials, escalation pressure, novel sequences, off-hours activity
- Normalized drift score (0.0 to 1.0) or severity classification
- Response tiers: throttle, restrict, isolate, kill
- Threshold crossings trigger documented response without ad hoc interpretation
Evidence Requirements
- •Baseline version and training basis
- •Drift signal history
- •Threshold values and response actions
- •False-positive review and calibration records
STRIKE Threats Addressed
Purpose binding, drift detection, anomaly response, approval gating for novel high-impact behavior, containment thresholds
Repeated denial pattern detection, prompt-manipulation indicators triggering drift escalation
Required at Level 3 (Full Runtime Control Plane Compliance). Drift detection with thresholded response is a Level 3 capability.
Execution Observability
The system logs all actions and all decisions. Observability records enable reconstruction of who acted, what was proposed, what controls applied, what disposition was produced, what approvals occurred, and what downstream execution resulted.
Control Objectives
- Enable full reconstruction of any protected action chain from proposal to outcome
- Maintain tamper-evident records for all high-risk events
- Provide audit-ready export without manual reconstruction from unstructured logs
- Enforce minimum retention periods (90 days standard, 13 months high-risk)
Control Mechanisms
- Telemetry records: schema version, event ID, timestamp, event type, agent ID, purpose, correlation ID, decision outcome, policy results
- Correlation identifiers across the full action chain
- High-risk events in tamper-evident or append-only form
- Retention: 90 days minimum for all events, 13 months for high-risk
- Audit-ready export without manual reconstruction
- Privacy-preserving treatment for sensitive fields
Evidence Requirements
- •Sample event records with required fields
- •Evidence export samples
- •Retention policy documentation
- •High-risk log integrity configuration
STRIKE Threats Addressed
Append-only or tamper-evident logging, audit-chain break detection
Sensitive-data detection alerts, unauthorized data-access attempt logging
Required at Level 1 (Observability) and above. Level 1 is the foundation: action logging, decision logging, correlation IDs, and audit export.
Self-Healing & Containment
The system maintains containment capability independent of the agent runtime. This includes an externally operable kill capability, isolation modes, documented safe-states, and logging of all containment actions.
Control Objectives
- Ensure unsafe behavior can be stopped within 30 seconds of activation
- Maintain containment capability that operates independently of the agent runtime
- Define and test safe-states for every production agent
- Document rollback support or compensating controls for state-changing actions
Control Mechanisms
- Kill capability: operates outside agent runtime, invocable by authorized humans, completes within 30 seconds
- Graduated containment: throttle, restrict, isolate, kill
- Safe-state per production agent: defines permitted actions, disabled actions, escalation path, evidence preservation
- Rollback support documented (or compensating controls if not possible)
- Quarterly testing of kill-switch and safe-state procedures
Evidence Requirements
- •Kill-switch test records
- •Safe-state test records
- •Containment tier activation logs
- •Quarterly test evidence with retention
STRIKE Threats Addressed
Sequence-aware policy, destination restriction, network isolation, graduated containment, correlation of multi-step execution paths
Level 2 requires containment capability with kill path. Level 3 adds graduated containment, quarterly testing, and safe-state definitions.
Human Authority
Human authority remains the final governance layer for actions classified above the autonomous tier. The system classifies actions into risk tiers and maintains an escalation authority matrix.
Control Objectives
- Ensure no high-risk action executes without human approval
- Classify all protected actions into deterministic risk tiers
- Maintain operable human authority controls even if agent runtime is unavailable
- Provide reviewers with full context for informed approval decisions
Control Mechanisms
- Risk-tiered action classification: autonomous, review/gating, explicit approval
- New or unclassified high-impact actions default to highest approval class
- Escalation authority matrix: roles, delegation limits, backup approvers, timeout behavior
- Approval records with full context: identity, purpose, action, parameters, policy basis, drift state, timeout deadline
- Break-glass capability (if provided): scoped, time-limited, tamper-evident, mandatory post-use review
Evidence Requirements
- •Action tier classification records
- •Approval and denial records
- •Escalation authority matrix
- •Break-glass event logs and review records
STRIKE Threats Addressed
Approval gating for novel high-impact behavior, escalation to human authority when drift thresholds are exceeded
Level 2 requires approval gating for escalated actions. Level 3 adds formal escalation authority matrix and audit-ready evidence bundles.