OpenAI Shipped GPT-6 Astra With a Monitoring Layer Your Agent Does Not Have

OpenAI released GPT-6 Astra on 3 September 2026, its most capable model to date, with agentic scores of 74.1% on DeepSWE v1.1 and 72.6% on OSWorld 2.0. The model is the first to reach OpenAI's 'Critical' cybersecurity capability level, prompting the company to deploy misalignment monitoring and blocking evaluations around tool-using inference. OpenAI staged the rollout to cybersecurity defenders first, with wider access planned in coming days.

Name the tool call your agent made yesterday that wrote to the database twice. A few hundred went out. You cannot point at that one. You have the provider dashboard, so you know how many tokens went out. You have request logs, so you know a session opened at 09:14 and closed at 09:21. You have Sentry, so you know nothing threw. What you do not have is the ordered list of what the model asked for and what came back. That gap was survivable while agents mostly summarised text. The model OpenAI released on 3 September 2026 is a reasonable argument for why it is less survivable now, and the reason sits in everything OpenAI bolted on around the model before letting anyone touch it rather than in the benchmark table. GPT-6 Astra landed on 3 September 2026, described by OpenAI as the most capable model it has broadly deployed. The agentic scores it reported at launch https://venturebeat.com/technology/welcome-to-the-agi-era-openai-launches-gpt-6-astra are 74.1% on DeepSWE v1.1 and 72.6% on the OSWorld 2.0 offline subset. Vendor figures, and they say the thing is meant to be pointed at tools. The part worth your attention is in the system card https://deploymentsafety.openai.com/gpt-6-astra , and none of it is a property of the weights. OpenAI deployed misalignment monitoring across tool-using inference in external deployment, using the same monitoring structure it runs internally, and added alignment evaluations that block a response rather than write it up afterwards. The card describes a layer of watching and gating built around the model, not only the model itself. OpenAI did that work at its own boundary, which is the inference call. Your boundary is one hop further down, where a string in a response becomes a DELETE or an outbound email. Nothing OpenAI monitors can see that hop, because it never leaves your process. Astra is also OpenAI's first model to reach the Critical level of cybersecurity capability under its own Preparedness Framework, and the card is specific about what it is describing: "with the right tools and access, GPT-6 Astra can find previously unknown security flaws and develop new ways to exploit them across many well-protected systems without a person guiding each step." That grade is OpenAI's own, against a bar OpenAI wrote. The monitoring and the blocking evaluations are what the company did about it. Here is the line from the system card that should bother you most, and it is not a scary one. In a simulation using more than 54,000 internal Codex tasks, Astra received roughly half as many flags for higher-severity misaligned behaviour as Sol system card https://deploymentsafety.openai.com/gpt-6-astra . Only the ratio is published, and the whole thing is OpenAI's simulation, OpenAI's flag definition, OpenAI's count. Take it as a vendor statistic. But look at what has to exist before anyone can write that sentence at all: Now try the equivalent sentence about the agent you deployed last quarter. How many runs tripped a rule this month, against how many runs total? For most teams the honest answer is that the ratio is undefined, because nothing counts the numerator and nothing counts the denominator. That is not the same as zero. An agent with no flags and an agent with no flag detector produce identical dashboards. The rollout carries the same message as the monitoring. Astra went first to organisations in OpenAI's Daybreak program for cybersecurity defenders https://www.nbcnews.com/tech/tech-news/openai-debuts-gpt-6-astra-security-measures-rcna595940 , with wider access for enterprise and consumer accounts announced as planned for the coming days. Staging a launch by who the customer is, rather than by region or by load, is an unusual order to pick. On the announced schedule, the head start the defenders got is measured in days. After that the capability sits behind an API key, wired into whatever agent anyone felt like building, including yours. That is not an argument that the model is unsafe to hand you. The argument is narrower: the visibility gap around your own tool calls stops being cheap to ignore. Nine fields. Each one exists because a question gets asked later and this is the field that answers it. The other four need less explaining. Cost per call, so a run carries a running total instead of a monthly surprise. Latency, which is the first signal that a tool is being called in a loop. A timestamp in UTC, ISO 8601, so sort does the right thing. And who approved, because for anything with a human in the loop, an approval nobody can point at is not an approval. The two that teams skip are decision and approvedBy , because a gate that blocks a call feels like it has done its job. It has not. Everything here runs on Node 24 with no build step and no dependencies. Save the files, run node main.ts , and Node strips the types on the way in. Start with the row and where it goes. JSON Lines, one object per line, appended. js // audit.ts import { appendFile, mkdir } from "node:fs/promises"; import { dirname } from "node:path"; export type ToolCall = { runId: string; callId: string; tool: string; input: unknown; output: unknown; decision: "allowed" | "blocked"; approvedBy: string | null; costCents: number; latencyMs: number; startedAt: string; }; const FILE = process.env.AUDIT LOG ?? ".audit/tool-calls.jsonl"; export async function record e: ToolCall : Promise<void { await mkdir dirname FILE , { recursive: true } ; await appendFile FILE, JSON.stringify e + "\n", "utf8" ; } A file is the version you can read with tail while you are still deciding what the fields should be. In production this becomes a table or a log pipeline, and the shape of the row does not change. If you add a human-approval step, widen the decision union with "needs approval" and fill approvedBy when the human comes back. Inputs and outputs are the interesting part of the row and also the dangerous part. The moment you start writing them down, your log holds every argument the model ever passed, which includes the ones you would not put in a screenshot. js // audit.ts, continued const SECRETS = /token|secret|password|key|auth/i; export function redact v: unknown : unknown { if Array.isArray v return v.map redact ; if v && typeof v === "object" { const out: Record<string, unknown = {}; for const k, val of Object.entries v { out k = SECRETS.test k ? " redacted " : redact val ; } return out; } return v; } Key-name matching is the cheap version, and it catches the common shapes. It does not catch a bearer token pasted into a free-text field, so treat this as the floor rather than the design. Decide the retention window at the same time you decide the fields, because an audit log of everything your agent ever did is a thing other people would like to read. A permission gate answers one question about one call: may this happen. It is a good thing to have and it is blind by construction, because the third identical call looks exactly like the first. Cross-call questions need the log. The two cheapest ones catch most of the runaway behaviour that actually shows up: the same tool firing over and over, and spend crossing a line. python // rules.ts import type { ToolCall } from "./audit.ts"; export type Anomaly = { rule: string; detail: string }; export type Budget = { maxCallsPerTool: number; maxSpendCents: number; }; export function check history: ToolCall , next: ToolCall, b: Budget, : Anomaly { const flags: Anomaly = ; const repeats = history.filter c = c.tool === next.tool .length + 1; if repeats b.maxCallsPerTool { flags.push { rule: "repeat tool", detail: ${next.tool} x${repeats} , } ; } repeat tool is a count, not a similarity check. Counting is enough, because a model stuck on a tool calls it with slightly different arguments each time, which is exactly what defeats a naive duplicate check. js // rules.ts, continued — still inside check const spend = history.reduce n, c = n + c.costCents, 0 + next.costCents; if spend b.maxSpendCents { flags.push { rule: "spend ceiling", detail: ${spend}c over ${b.maxSpendCents}c , } ; } return flags; } The spend rule is checked before the call, on the estimated cost, because a ceiling enforced after the money is spent is a report. Estimate high when you are unsure. The wrapper is the whole design. Every tool is called through it, so there is no path where a call happens and no row appears. js // guard.ts import { randomUUID } from "node:crypto"; import { record, redact, type ToolCall } from "./audit.ts"; import { check, type Budget } from "./rules.ts"; export type Tool = { name: string; run: input: unknown = Promise<unknown ; costCents: input: unknown = number; }; export class Blocked extends Error {} export function caller runId: string, budget: Budget { const history: ToolCall = ; return async function call tool: Tool, input: unknown { const entry: ToolCall = { runId, callId: randomUUID , tool: tool.name, input: redact input , output: null, decision: "allowed", approvedBy: null, costCents: tool.costCents input , latencyMs: 0, startedAt: new Date .toISOString , }; The row is built before the call, not after. That ordering is what makes a blocked call recordable at all, and it is why input is captured even when run never executes. js // guard.ts, continued — still inside call const flags = check history, entry, budget ; if flags.length 0 { entry.decision = "blocked"; entry.output = flags; history.push entry ; await record entry ; throw new Blocked flags.map f = f.rule .join "," ; } const t0 = performance.now ; try { const out = await tool.run input ; entry.output = redact out ; return out; } catch err { entry.output = { error: String err }; throw err; } finally { entry.latencyMs = Math.round performance.now - t0 ; history.push entry ; await record entry ; } }; } The finally is doing the load-bearing work. A tool that throws still produces a row, with the error in output and a real latency on it. Put the record call in the success path instead and your log quietly becomes a record of the calls that went well, which is the one population you never need to investigate. Blocked is its own error class so the agent loop can tell a policy stop from a tool failure. They mean different things and the model should be told different things about them. A tool that does nothing, called five times, with a ceiling of three: js // main.ts import { Blocked, caller, type Tool } from "./guard.ts"; const search: Tool = { name: "search docs", run: async = { await new Promise r = setTimeout r, 40 ; return { hits: 3 }; }, costCents: = 2, }; const call = caller "run-42", { maxCallsPerTool: 3, maxSpendCents: 100, } ; for let i = 0; i < 5; i++ { try { await call search, { q: "refunds", apiKey: "sk-live-1" } ; console.log call ${i}: ok ; } catch err { if err instanceof Blocked throw err; console.log call ${i}: blocked ${err.message} ; } } bash $ node main.ts call 0: ok call 1: ok call 2: ok call 3: blocked repeat tool call 4: blocked repeat tool And the first row on disk, which is the actual deliverable: { "runId": "run-42", "callId": "6988d7e4-522c-4969-ba7d-1b67712877a2", "tool": "search docs", "input": { "q": "refunds", "apiKey": " redacted " }, "output": { "hits": 3 }, "decision": "allowed", "approvedBy": null, "costCents": 2, "latencyMs": 41, "startedAt": "2026-09-03T21:32:06.473Z" } The API key went in as a literal and came out redacted. The latency is measured. The blocked rows further down the file carry the rule that stopped them. Once the rows exist, the denominator is a query. Over the five calls from that run: bash $ jq -rs '{runs: map .runId | unique | length , flagged: map select .decision == "blocked" .runId | unique | length , calls: length}' .audit/tool-calls.jsonl { "runs": 1, "flagged": 1, "calls": 5 } One run out of one is not a statistic. Run that query against a week of production traffic and it is the number you did not have before, in the same shape as the sentence OpenAI wrote about its 54,000 tasks. Be precise about the size of what you just built, because the failure mode here is believing you are covered. Logging is detection, not prevention. The row for a successful call is written after the call returned. The write happened, the email went out, the row is a description of it. Only the two rules block anything, and they block the shapes you predicted in advance. Two rules catch two behaviours. A repeat counter and a spend ceiling do not notice a single, quiet, wrong call. That is the case that costs the most and the one this catches least. It is not what OpenAI built. Theirs runs across tool-using inference in external deployment, mirrors the structure they use internally, and has a flag definition and a 54,000-task simulation behind the numbers they publish. This is arithmetic over an array. Both are worth having, and they are not the same instrument, so do not describe yours internally as though it is. The log is now an asset somebody wants. It holds inputs and outputs from every tool your agent touched. Redaction, access control and a retention window are part of shipping it, not a follow-up ticket. Find every place your code calls a tool. If there is more than one, that is the bug, and collapsing them into a single wrapper is the whole afternoon. Then give the wrapper a row per call, a repeat counter, and a spend ceiling. Run it for a week. Then answer the question OpenAI can answer about its own model and you currently cannot: out of every run your agent did, how many tripped a rule? Whatever that number turns out to be, it beats not having one. Tool-call audit logs, cost ceilings and the evals that turn a log into a signal are the working parts of my book AI That Ships . It covers the same layer this post builds by hand: what to record, what to alert on, and what to refuse to ship without. It is book 5 of AI in TypeScript , a five-book series that runs from your first LLM call through to agents you can leave running in production.