An agent monitoring alert fires. The dashboard turns red. The agent keeps acting.
This is the failure mode that makes monitoring dangerous: you have visibility, but no authority attached to it. The dashboard says something may be wrong. The run continues anyway because nobody defined who owns that signal, when they must decide, or what happens if they do not.
Logs record. Alerts notify. Controls require action.
A log records that something happened: the agent called a deployment interface with specific parameters under a specific identity. Logs are retrospective. They tell you what occurred after the fact.
An alert fires when a signal crosses a threshold: the agent made an unusual number of deployment calls in a short period. Alerts tell you that something worth investigating may be happening now.
A control is different from both. A control requires a decision and enforces a consequence. When the agent's activity crosses a defined threshold, a control pages a named human, gives them a deadline to decide, and pauses the agent if no clearance arrives. The pause is the consequence. Without the deadline and the pause default, the alert is just a loud log.
Start cheap, escalate when it counts
The staged approach matters because running the most expensive check on every event adds cost and latency, while paging people on every broad signal overwhelms the responders. The design has to narrow uncertainty before it demands a human decision.
Stage one: broad, low-cost detectors. These watch signals that are cheap to compute and wide in scope: unexpected tool calls, identity anomalies, unusual data access, network behavior outside the agent's normal profile, output checks, and workflow-state rules. One rule might flag a production deployment call made before a staging approval is complete. At this stage, the system can accept lower precision because later investigation filters hits before paging people.
Stage two: contextual investigation. When a low-cost detector fires, a more expensive check pulls together the tool-call sequence, identity events, accessed data, network calls, and workflow state. This context separates an unusual interface call from an unusual call made with an unexpected service identity after the agent read a configuration file unrelated to its assigned task. The combined pattern gives the responder a reason to act instead of another isolated anomaly to interpret.
Stage three: page, decide, or pause. A contextual hit pages a named person on the security, operations, or engineering team. That person has a defined window to clear the flag as a false positive or confirm the escalation. If the person does not clear it within the window, the agent pauses. When the team cannot confirm that the run is safe, the architecture prevents the run from continuing.
OpenAI published a version of this pattern in its description of frontier-model monitoring. The company says activation classifiers—detectors that inspect a model's internal activity—run at every sampled token, then escalate concerns to higher-compute automated investigators. Those systems examine tool actions, the model's available reasoning record, and the full activity sequence for unauthorized access, data theft, destructive behavior, and attempts to defeat safeguards. These are vendor-reported mechanics, not an externally audited architecture [1].
For likely violations of a critical security boundary, OpenAI says its safety, security, and research teams are paged. OpenAI says that if its teams cannot conclusively clear the flag as a false positive within 30 minutes, they are expected to pause the activity. [1] The deadline turns the signal into a decision path. The standing pause rule gives that path an enforceable outcome.
Normal enterprise teams cannot replicate the activation classifiers because they lack access to the model's internal activity. They do control other useful signals: tool-call policies, identity events, data-access logs, network behavior, output inspection, and workflow state. The copyable part is the staged path from broad detection to contextual investigation to a timed human decision.
One kill switch is not enough
Teams often design agent safety around a kill switch: a button that stops the agent when someone manually presses it. The problem is that a kill switch requires a human to act before the system changes state. A default-to-pause control covers the period when the human has not yet responded.
A real pause mechanism does more than stop the visible agent loop. It prevents new tool calls, removes short-lived credentials or tool authority, and stops queued work from continuing downstream. It also preserves evidence so the team can reconstruct what happened. Finally, it defines safe resume conditions because restarting from a compromised workflow state can repeat the same failure.
OpenAI says it paused Astra activities that did not meet strengthened controls after preliminary internal evaluations meant the company could not rule out a critical level of cyber capability. It also says monitoring across Astra's agentic applications could trigger a security response to review and interrupt high-risk activity. The capability assessment and control mechanics remain vendor claims [2]. Reuters independently confirmed the separate slowdown, the training pause, and the addition of monitoring systems, but not the internal design [3].
Set the deadline by blast radius
An enterprise team should not copy a frontier lab's adjudication window by default. The right deadline depends on who has authority to clear the flag and what the agent can damage while the window remains open.
An agent with read-only access to a ticketing system has a different blast radius than one with write access to an identity provider and deployment pipeline. Set the service-level objective—the maximum time from alert to human decision—according to how much the agent can do before the clock expires. If the agent can create production credentials, modify network rules, or release code during that interval, the pause must happen before those actions can accumulate.
Severity follows the same logic. A flag on read activity from a low-privilege identity deserves less urgency than credential creation from a service account that rarely touches production. Build severity tiers around authority and consequence, not the alerting tool's defaults.
Monitoring belongs in the budget
Monitoring is not free to add after the agent is already in production. Detectors and investigators consume compute. Investigation can add latency because the system may need an answer before allowing the next action. Timed adjudication also requires staffing: someone with the right authority must receive the page and decide. Routing pages, tracking deadlines, recording decisions, and preserving evidence require supporting tools.
Budget these costs before expanding agent authority. OpenAI reported roughly 20% overhead on the inference compute it monitored. The company says the cost varies substantially across training and evaluation workloads, so this vendor estimate is not an enterprise benchmark [1]. Its value is narrower: it shows that serious monitoring consumes resources and should appear beside model, integration, and on-call costs in the architecture plan.
A deployment flag nobody can ignore
Consider an agent connected to a ticketing system, an identity provider, and a deployment pipeline. Its task is to process approved change tickets and promote code to production.
While processing a ticket, the agent tries to create a service account with elevated deployment rights, but the corresponding change ticket is not in the required approval state. A broad detector flags the identity event. A contextual investigator combines the tool sequence, ticket state, and identity logs. The combination crosses the team's escalation threshold, so the on-call engineer receives a page.
That engineer has the defined window to clear the flag. If they clear it, the run can resume. If they do not respond, the agent pauses, the new account is disabled before it can deploy, queued actions stop, and the evidence is preserved. Silence from the responder cannot become permission for the agent.
Before you expand agent authority
Before giving an agent wider production access, add a maximum alert-to-human-decision time to the architecture review and runbook. Set it from the agent's authority and blast radius, not another organization's published practice.
Then add a tested default-to-pause rule. Run the full path in a staging environment. Confirm that new and queued tool calls stop, credentials lose authority, evidence survives, and the workflow can resume from a known-good state. Budget the required compute, latency, on-call staffing, and tooling next to the agent's other operating costs.
Do not expand production authority until an uncleared alert can stop the run.