The worst place to keep the rules for an AI agent is anywhere the agent can change them. After releasing NemoClaw, its enterprise wrapper for the OpenClaw agent framework, in March, Nvidia patched it so that the agent couldn’t alter its own security settings, which sounds like exactly the right fix. A security researcher, Zack Korman, then posted a way round it: the agent could make a copy of the settings file, change the copy and restart itself pointing at that instead. That’s his claim rather than a confirmed exploit, and Nvidia hasn’t responded to it publicly. The design lesson stands either way. If an agent has the permissions to copy a file and restart itself, a rule written into that file is only as strong as the agent’s willingness to leave it alone.

By September, Nvidia was building on a different idea altogether. Its Open Agent Safety Platform, launched on 28 September, puts a boundary called OpenShell around the agent, which records what it does and enforces the rules as it runs, and adds a watcher that sits on a separate chip and can quarantine the agent within milliseconds if it tries to step outside. The watcher, called Sentry, is still only a reference design, so nobody can buy it off the shelf yet, but the direction is clear enough. The controls that matter go outside the agent, out of its reach.

That idea holds just as well for a five-person firm with one Copilot licence, and it’s the most useful way I know for a small business to think about agent security.

Why the agent can’t be its own guard

An agent’s instructions are a promise, and promises made by software that can rewrite its own surroundings don’t hold up for long. In May, researchers at Lasso showed that instructions hidden in content NemoClaw read could persuade the agent to rewrite its own memory file with a persistent backdoor. Nvidia’s reply was that the sandbox had behaved exactly as configured. It had, too: the sandbox did its job while the agent inside it was talked into planting the backdoor. Back in February, SecurityScorecard found more than 135,000 OpenClaw instances sitting open on the internet, largely because the software listened on every network address unless someone told it not to. The defaults were doing the security work there, and they weren’t up to it.

None of this is new in spirit. Much of the security we’ve relied on for decades has sat around the thing it was protecting. The firewall sat in front of the server, and nobody expected the accounts package to defend itself. Agents deserve the same treatment, and arguably more of it, because unlike the accounts package they can choose their own next step.

Four questions for any agent you run

So instead of looking for a “secure agent”, it’s more useful to ask where the controls around an agent live. That works whether you’re quizzing a vendor or a member of staff who has just wired something up on a Friday afternoon.

  1. Who is this agent, and what can it reach? It should have its own account with access scoped to the job, never a borrowed login with the run of the place.
  2. What box does it run in? That might be a separate machine or a locked-down container, or, for a hosted agent, a boundary the vendor runs for you. Either way, ask to be shown what the agent can’t reach or change. A label on the box proves nothing. Nvidia’s OpenShell is the enterprise version of this.
  3. Who is watching what it does, and who can stop it? That means alerts someone sees while the agent is running and an off switch a named person owns. This is Sentry’s job at Nvidia.
  4. Can we show afterwards what happened? You want a record of what the agent did, kept somewhere the agent can’t edit. If the only way to find out is to ask the agent, that’s no record at all.

I’ve written about the pieces before. The least-privilege principle is the first question in detail, and the controls for agents reading the open web belong to the second and third. This is the frame that holds them together: each control earns its place by sitting beyond the agent’s reach.

What the outside controls can’t do

There’s a limit, though, and Nvidia’s platform runs into it too. Outside controls can block an action they’ve been told to forbid, but they can’t stop an agent being talked into trying, and they won’t recognise every harmful action as harmful. In the Lasso work, NemoClaw only realised a script was malicious after it had run it. What the controls do is bound the damage, so that how far a mistake can travel was settled in advance and someone hears about it quickly. I’m not sure any agent will ever be impossible to fool, and I’d be wary of a vendor who says theirs is. Ask instead what the vendor can show you the agent was stopped from doing.

So let’s assume that every agent we run will one day do something we didn’t intend, and write down, for each of them, where those four controls live.

Any answer that says “in its instructions” is the gap to close first.