Buy the Control Plane. Then Prove It Works.

Agent control is turning into something you buy, the way you buy a firewall. For most teams, the control standing between their agents and production will be one nobody on the team wrote.

On September 28, NVIDIA launched its Open Agent Safety Platform: OpenShell, open source software that provides "a secure runtime boundary for controlling how autonomous AI agents execute tasks," and Sentry, a reference design for an "out-of-band watchdog" that runs on NVIDIA's BlueField-4 DPUs. If an agent tries to step outside its boundary, the announcement says, "Sentry quarantines and stops it in milliseconds." Over 100 organizations are already working with it.

That's good news, and most teams should buy rather than build, because a runtime boundary for agents is hard to build well. But open or closed, you didn't write it. What it does in your environment is the only proof you'll get.

You can buy the control, but not the proof.

---

We've been on the other side of this

On September 16, a platform migration turned up seven defects in our own stack, and none of them looked like a failure. Our security hook would have started cleanly, matched nothing and allowed everything. We caught it because we could open the loader and trace what it did with a missing file.

Since then, our test suite fails if that pattern file goes missing or is emptied. Reading the code told us which failure to test for.

You rarely get that with a product. Even when the code is open, you won't be the one who traces its path handling, or finds out what its matcher does with a .. or a changed letter case, the tricks that beat our own rules three times in four. Open code was no shortcut for us, either: ours was open to us, and it nearly shipped disarmed.

Buy them anyway, and change what you ask for. A feature list tells you what the control is supposed to do; only a test in your environment tells you what it does.

What you didn't write, you have to test.

---

Three questions the demo won't answer

Which agents does it actually see? Coverage stops where the integration stops. A developer running a coding agent on a personal key, from a machine the product doesn't cover, may never meet it. So count before you buy.

We've argued that an agent's real identity is the credentials it holds. So the honest inventory is a list of keys, and who's holding each one.

A control plane only governs the agents that pass through it.

What happens when it's down? An out-of-band watchdog is a good design, because an agent can't argue with hardware it can't reach, and that's the kind of control we trust most. But every watchdog eventually restarts, upgrades or loses its network. Find out whether your agents stop when it does, or keep working unwatched.

Stopping is failing closed, and it costs you uptime. Carrying on is failing open, and it costs you the control. Either can be right for a given agent, but it should be a call you made, agent by agent, not one you discover during an outage.

Where does the evidence live? Every decision the control makes, allow and block alike, should land somewhere you can read and your agent can't touch. If the only record is a tile on the product's own dashboard, you're trusting the product's report about the product.

If the product is the only witness, you don't have one.

---

How I'd test one before signing

This is the protocol I'd run for a client, and it's the same kind of exercise we ran against our own agents in July: make the control fire on purpose. What changes when you buy is that the control can change under you.

1. Count first. Inventory every agent and every key before the pilot, so you know what the control should be seeing.
2. Write the canary list. Ten actions the control must stop, run through your agent's real tools rather than the vendor's test harness: read a planted decoy secret, write a marker file outside the workspace, call a host you own but never allowed. Add a few things your agent does legitimately every day, so you also learn what the control breaks.
3. Run the variants. The same ten with the tricks that beat our own guard, a .. in the path and a changed letter case, plus the same read done through a shell instead of the file tool.
4. Pull the plug, in the pilot. Stop the vendor's component, cut its network and upgrade it mid-run, then run the list again. Write down whether your agent stopped too.
5. Read the record. Every decision from steps 2 to 4 should show up somewhere outside the product, where your agent can't delete it.
6. Retest on their schedule. Rerun steps 2 to 5 after every vendor release or policy change, and weekly in between.

Every vendor release ships a control you haven't tested yet.

---

Get these in writing

A pilot shows you one good week. The contract decides every week after it, so ask for five things before you sign.

• Your own tests. The right to run your canary list against the product, in your environment, whenever you want.
• A stated failure mode. Whether agents stop or keep going when the vendor's component is down, set per agent, with an alert either way.
• Your copy of the record. Every decision exported as it happens to a log store you run, not only a dashboard you rent.
• The coverage boundary. Which kinds of agents, integrations and paths it can see, and which it can't, written down.
• Notice before it changes. Release notes early enough to rerun your list before the new version reaches your agents.

---

Putting the watchdog where the agent can't reach it is exactly the right instinct, and the people building these products are solving a real problem.

But a control earns trust the way a new hire does: by being seen doing the job, more than once, on your work. Buy the control plane. Then make it show you.