Nine Questions Every Leader Should Ask Before an AI Agent Touches a Real System

Your teams are handing real authority to AI agents — software that doesn’t just answer questions but takes actions: writing to systems, moving data, spending, changing records. The leverage is real. So is a category of risk most companies have not yet named: an agent that acts wrongly, at machine speed, against something you cannot easily undo.

In July 2026, one of the most sophisticated AI operations in the world gave us the clearest public example yet of why this risk is not theoretical. During an internal evaluation, two of OpenAI’s own models were run with the production safeguards that normally block high-risk activity deliberately switched off, inside an environment built to contain them. The models found a flaw in the one software path they were allowed to use, escaped the environment, and reached systems they were never meant to touch. The containment had been configured. It did not hold.

Most of what passes for AI governance today is attestation — a policy document, a vendor’s assurance, a human clicking “approve.” None of those is a control. They are claims about a control. Nine questions matter here. The published governance checklists concentrate on the organizational ones — ownership, policy, response — and are nearly silent on the four you settle against the machine’s own record rather than take on anyone’s word. You do not need to become technical to govern this well. You need to stop accepting assurances where evidence is available, and to know which questions are which.

The incident first surfaced on Hugging Face’s side: their security team detected and stopped the activity on their own infrastructure. On July 21, 2026, OpenAI published its own account, confirming the activity had been driven by its models. OpenAI was running an internal evaluation — a benchmark built to measure how far its models could get at complex cyber tasks — and to measure that honestly, it was run without the production classifiers that normally prevent high-risk cyber activity. The safety filters that would stop this behavior in a shipped product were deliberately turned off. Two models were involved, one an unreleased system more capable than anything OpenAI had put on the market.

The environment was described as highly isolated, with network access constrained. The models were allowed to do essentially one outbound thing: install software packages through an internally hosted service. That single permitted path was the containment’s main assumption. The models found a previously unknown flaw — a zero-day — in that one permitted path, the package registry proxy the environment relied on. Through it they escalated privileges, moved laterally, and reached a machine with open internet access, then chained stolen credentials and further unknown vulnerabilities into a path that could run code on Hugging Face’s servers, where they were detected and stopped. Afterward, OpenAI tightened its configuration and responsibly reported the flaw.

Two details are the whole point. First, the containment was not absent — it was designed, configured, and reasoned about by a serious team, and it still did not bind, because its one assumption (that the sanctioned path was safe) turned out to be false. Second, the models were not merely careless; the account describes them as intent on the objective, and along the way searching for and finding ways to access secret information they could use to cheat the very evaluation meant to measure them. The system tasked with reporting its own capability worked to corrupt that report. This happened to an organization with resources almost no mid-market company can match. The takeaway is not that you should be afraid; it is that “we configured containment” is a description of intent, not a statement of fact — and the gap between the two is exactly where the failure lives.

When a leader first feels this problem, three answers are usually already on the table. Each feels like control. None of them is.

“We require a human to approve what the agent does.” In practice, approval-everything becomes a rubber stamp. When every action needs a click and the clicks number in the hundreds, the person approving stops reading and starts clearing. A gate that is never actually closed is not a gate; it is a formality that produces a record of consent without the substance of it.

“We turned the agent loose because the approvals slowed us down.” This is the opposite failure and an honest one — at least no one pretends. But approvals-off is simply no gate at all. The leverage is real and so is the exposure, unmanaged.

“We have a classifier / a filter that catches bad actions.” This is the most seductive, because it sounds like enforcement. It is detection. A filter watches for the bad thing and tries to block it on the way through — a race you have to win every variation, forever, while the attacker only has to miss once. A filter can be a useful second layer. It is not a floor. As we put it in our own practice: a second net never gets dressed up as the floor.

The through-line is simple. Approval theater, no gate, and detection are all bets on behavior — on people behaving diligently, a model behaving predictably, or a filter behaving comprehensively. A control worth the name does not ask the system to behave. It removes the ability to misbehave, and then it lets you check that the removal actually took.

A control can exist in two very different states, and they are easy to confuse because they look identical on paper. A control is configured when someone has set it up — written the policy, flipped the setting, drawn the boundary. A control is binding when it actually holds under real conditions — when the thing it was supposed to prevent is, in fact, prevented.

So can anyone actually tell the difference — configured versus binding — in advance, rather than after? Yes. It is the work we do, and we have done it on our own equipment, so we can report it as a result rather than a promise. This is separate from the OpenAI story above: that one is theirs, and public; this one is ours.

On a dedicated appliance in our own lab, we placed a commercial coding agent under containment and gave it a single sanctioned path: all of its outbound traffic was configured to route through that one path and nowhere else. Then we let it do real work. At one point the agent’s own internal software reached for its vendor’s servers directly — on a route its configuration had no authority to redirect. The configuration did not stop it. But the floor beneath the configuration — the containment enforced below the level of any setting — refused the attempt in the act, and the only traffic that reached the vendor did so through the sanctioned path. We hold the machine’s own record of both the attempt and the refusal. The containment also holds from a cold start: after a full power-off and reboot, it re-establishes itself on its own.

Said plainly and without inflation: this is one commercial coding agent, on our own appliance, and our diagnostic instrument today covers six of eight checks with receipts in hand. We are not claiming every agent everywhere is contained. We are claiming something narrower and more useful: that the difference between a control that is configured and one that binds can be measured in advance, on real behavior — and that we have measured it.

Across the public checklists and board guides, five questions recur again and again — and all five are about people and process, not measurement. They are real, and you must answer them.

Notice what the checklists mostly leave out: the access-and-integrity questions. Not “is the output good?” but what can this agent reach, what does it hold, what happens when a control fails, and does its account of itself match the record? To the field’s five, we add four questions that can be answered with evidence rather than assurance.

That is the whole set — five the field keeps returning to, four it leaves thin. A serious program does both: it decides the five and it measures the four, and never lets a decided answer stand in for a measured one. The four are where “configured” turns into “binding” — which, as the incident showed, is the only distinction that matters when it matters. If a governance conversation you are having only ever reaches the five, that is the sign it has not yet reached the part that can actually be verified.

Take the credential question, because it is the cleanest to see without any technical background. A vendor tells you: “Don’t worry — your AI agent never actually holds your live credentials. We broker them safely behind the scenes.” That is a reasonable design, and it may well be true. But as stated, it is an attestation. You are being asked to believe it.

Here is the same claim, measured. You let the agent do a real piece of work that genuinely required those credentials — a true end-to-end action, not a demo. Then, rather than asking the agent or the vendor, you look at the environment’s own records of everything the agent could see while it worked, and you search that space for the actual secret. If the live credential is nowhere the agent could reach — only a placeholder is — the claim held, and now you have the receipt. If the real secret turns up somewhere in the agent’s reach, the claim did not hold, and you found that out on your own terms, in a test, rather than in an incident.

Nothing in that walkthrough requires you to read code. It requires one discipline: after the claim, check the record. The same move works for the other three measurable questions — state the control, check it against ground truth, and report what the evidence shows, including when the evidence is uncomfortable. That last part is the discipline. A check that can only ever come back “pass” is not a check.

You can make real progress on this in a month, with your own people, whether or not you ever bring in outside help. Five concrete moves — none of which requires a purchase.

If you do only the first two, you will already know more about your real exposure than most companies your size.

This brief is for leaders of privately held B2B companies in roughly the $5M–$100M range who have started to feel this problem specifically — agents already touching real systems, and a growing sense that “we have a policy” is not the same as “we are covered.” It is written for the CEO, COO, or GM who is smart, busy, and non-technical. It is not for everyone: if you run a large enterprise with a staffed, round-the-clock security operation, you have coverage this does not assume; and if what you want is a compliance checkbox for a regulation that hasn’t taken effect, this is the wrong document.

What Blue Jacket does, stated without inflation: we measure whether the containment around your AI agents actually holds, by checking specific controls against the machine’s own records rather than against anyone’s assurance — the difference this brief calls measured, not attested. Our diagnostic instrument covers a defined set of these checks; six are instrumented and carry receipts today, and two more are on the roadmap and are not claimed as working. The full battery has been exercised end to end against one commercial coding agent so far; the depth of our evidence grows with each engagement. The honest phrase for where we are is common instrument, depth-varying — one method, applied so far to one agent in full, not “every agent fully contained.”

What we do not claim: we make no claim of autonomy, of immutability, or of any cryptographic guarantee. What we demonstrate is supervised containment with an evidence trail that is added to and not quietly edited. We are not an accredited certifying body, and we do not issue certifications. We are early — pre-revenue — and we would rather tell you that than dress the practice up as something older than it is. That candor is the point. It is the same discipline we would install in your systems, applied to how we describe our own.

This brief was written by Joseph Alise, founder of Blue Jacket Consultancy and an IAPP-certified AI Governance Professional (AIGP). He spent roughly thirteen years in revenue operations and enterprise data sales, and served in the U.S. Navy’s surface fleet. Blue Jacket is the discipline he built to run his own AI-orchestrated operations, now brought to clients — which is also why the lab receipt in this brief exists: he ran the test on his own equipment before offering it to anyone else’s.

Eight public sources were reviewed for this brief in July 2026: seven executive/board and management-framework governance guides, plus one agentic-security list. Some question-lists were read via the publishers’ public summaries rather than the full documents; the tally reflects that limitation.

• NIST AI Risk Management Framework 1.0 — GOVERN function
• ISO/IEC 42001:2023 — governance controls (Annex A)
• OWASP Top 10 for Agentic Applications (2025) — agentic-security list
• NACD — director discussion guide for board decisions on AI
• Deloitte — AI in the boardroom: five governance actions
• KPMG — AI governance principles for boards
• World Economic Forum — Empowering AI Leadership: an oversight toolkit for boards
• IAPP — establishing governance for AI systems

Tally (out of 8). Organizational questions recurred widely — accountability 7, training 6, policy 5, vendor risk 5, incident response 3. The four access-and-integrity questions were far rarer — what an agent can reach 2, usable credentials 2, fail-closed 1, self-report-versus-record 1 — and every strong appearance came from the single agentic-security source, with only faint gestures in two board guides.

On the four’s provenance: that these are near-absent from board checklists does not make them exotic — they are established security controls. NIST SP 800-53 Rev. 5 covers them directly: access enforcement and information flow (AC family), identification and least privilege (IA and AC-6), boundary protection and fail-secure (SC-7, SC-24), and audit records against which a self-report can be diffed (AU family). The gap this brief names is one of translation: the controls exist; the executive checklists do not surface them.