Published May 19, 2026 by Guidelight, with a companion conceptual explanation by Steven Adler, "Principles for keeping AI under control" (Clear-Eyed AI, July 15, 2026).
Framing
The standard defines control as "the technical and operational measures that constrain what an AI system can do, regardless of whether it is aligned" — a formulation that separates control from alignment as an assurance strategy. Its stated dual purpose: such measures "both reduce catastrophic risk from a misaligned AI and can surface evidence of an AI's misalignment."
Like Guidelight's other standards, it is organized into principles (high-level goals) and practices (concrete recommendations), with "directions-for-development" marking areas "where new practices are needed, but the specifics aren't yet worked out."
Its scope is internal deployment, defined as "any usage of the model beyond training, evaluations by the safety/evaluations team(s), or safety testing by trusted third parties" — expressly including dogfooding, "use in automated AI research, to generate training data, critiquing other models, or in agentic pipelines for research." Risk-relevant models are those meeting or exceeding "the threshold for frontier models articulated by California SB 53 (10^26 FLOPs of training compute)," borrowing an existing statutory line rather than defining a new one.
The six principles
1. Be able to see what your AI is doing during internal deployment. Maintain an inventory of every way to run inference, with each one's approximate share of volume and whether it is monitorable. The quantitative requirement: "99.9% of inference tokens happen in a monitorable setting" — defined as logged and scannable by classifiers, with the standard clarifying this means the inference is "able to be scanned," "not that classifiers are necessarily run against every request." Logging must cover both content (chain-of-thought, tool calls) and metadata (scaffolding, active branch). Developers must define and publish which monitor outages "are treated as outages of internal inference itself (i.e., what causes inference to fail closed until monitoring is back online)," maintain tamper-evident logs "such that deletion or modification of inference records is detectable," and give employees "a straightforward method… to flag their internal inference traffic for review."
2. Scan for signs of concerning behavior. Define and publish a sampling procedure, noting that "higher-risk sources (e.g., agentic coding scaffolds) may be sampled at a different rate." Ten categories of concerning behavior must be covered, across both chain-of-thought and actions: deception and dishonesty; sabotage of safety-relevant work; reward hacking and specification gaming; sandbagging and capability concealment; resource and capability acquisition; self-preservation and shutdown avoidance; manipulation and influence on humans; misuse facilitation; inappropriate autonomous action; and unreliable monitorability. Monitor recall must be measured and documented, with a published tiered response-time target for human review "including which flag-types and -severities require an on-call response," and tracking of median, 90th-, and 99th-percentile review times against it.
3. Stress-test the sufficiency of your scanning. Run monitorability evaluations whenever a new risk-relevant model enters internal deployment or the model or monitor materially changes; run recurring sting operations — automated rather than human-initiated, "for example, a pipeline that consistently builds new stings by tweaking actual inference traffic" — presenting opportunities to take unwanted actions; run recurring stress-tests injecting known-bad behaviour to verify the monitor catches it; and test whether models "can distinguish sting operations from real traffic," putting "less credence in sting operations the respective models know to be tests." The last practice makes evaluation awareness an explicit input to how much weight a control result carries.
4. Stop the AI from taking harmful actions even if it tried. Three tiers: absolute action boundaries, actions "an agent should categorically never be able to take without a human's signoff, even if a monitor has identified no issues"; critical action boundaries, gated by a monitor semi-synchronously or stronger before crossing; and important action boundaries, not blocked but "closely trailed by a monitor with the capacity to intervene."
Two categories are required to be critical: "changes to the monitor system itself" and "changes to control-relevant security configurations" — closing the loop by which a system could disable its own oversight. Also required is aggregate-flag halting, "a threshold of action-rejections that causes all boundary-crossing actions to be restricted until actively cleared by a human as false-positives," which addresses the retry vulnerability the standard notes in semi-synchronous monitoring, where "the agent can immediately retry with a different action without waiting for human review." Reviewers of agent-initiated pull requests must consider "both the proposed changes and any monitor flags raised during their generation."
5. Have independent third parties verify the adequacy of your control regime. Quarterly "high-context, third-party red-teaming, providing red-teamers with knowledge of the monitor system and tasking them with finding gaps and trying to penetrate action boundaries," plus quarterly commissioned and published third-party adequacy reports, "redacting only information deemed by the third-party to pose unnecessary commercial risk or to be unsafe to publish" — placing the redaction judgment with the assessor rather than the developer.
6. Prepare for a possible breach of control. Adopt a containment response plan covering "what permissions to revoke from the model, who the model may continue operating for, under what constraints, and when to take it fully offline." Publish a notification protocol specifying triggers, recipients ("internal teams, government, peer organizations as appropriate"), timeline, and information to be shared. Set and measure a target latency "for quickly shutting down inference on all instances of a particular model, API key, or other relevant factors without taking the underlying computers completely offline."
Relationships
- supports: AI Control — an operational specification of the control agenda
- related: Monitorability Tax — makes monitorability a measured and published property rather than an aspiration
- related: Guidelight AI Standards, Steven Adler, California SB 53, AI Scheming, Reward Hacking, METR Frontier Risk Report, February–March 2026: A pilot assessment of rogue deployment risk at frontier AI companies