Imagine an insurance claims agent that can settle anything below $10,000. It stays inside its sandbox, uses only approved systems, never exposes a credential and never makes an unauthorized network call. Every individual claim it settles is within the authority it has been given.
Then it settles 3,000 of them, and somewhere along the way the pattern should have triggered a different kind of review.
Nothing escaped and nothing was hacked. The controls worked exactly as designed. The problem is that most controls are very good at deciding whether one action is permitted, and much less good at deciding whether a sequence of individually permitted actions has become something the business no longer wants to allow.
I have been thinking about that distinction because NVIDIA just announced its Open Agent Safety Platform. There is plenty in the announcement about sandboxes, BlueField hardware and isolation, but what interests me is the assumption underneath it: once agents can act, we should stop relying on the agent itself to enforce the limits around those actions.
Moving the control outside the model
For much of the last two years, AI safety has been treated mainly as a model problem. Improve the system prompt, add another classifier, or put a second model in front of the first one to check what it is doing. Those techniques still have a role, but they become less reassuring once the model can run code, call enterprise APIs, create other agents and initiate transactions.
OpenShell puts the agent inside a controlled runtime and governs what files, networks, tools and credentials it can use. Those restrictions continue to apply to code the agent writes and processes it launches. Its optional policy advisor can let the agent ask for additional network access without allowing the agent to simply grant that access to itself.
Sentry takes the same idea a layer lower. It runs on BlueField-4 DPUs outside the host environment and, according to NVIDIA, can quarantine an agent that crosses its boundary within milliseconds. OpenShell itself does not require BlueField, so Sentry is better understood as an additional enforcement layer outside the host rather than a prerequisite for OpenShell.
None of this is especially strange if you come from security. We do not normally ask an application to promise not to read a database it should not read, or ask a service to remember which credentials it should not use. We enforce those things elsewhere. Agents should not get an exemption just because the software making the decision happens to be probabilistic.
I made a related argument recently in my piece on the sandbox and the trust graph: the sandbox is not the whole boundary. What matters is also the surrounding system of identities, networks, tools and services that trust what comes out of it.
Permission is the easier half of the problem
The more difficult question is what exactly we mean by permission once an agent starts doing real enterprise work.
An accounts-payable agent probably needs access to SAP, but that does not mean it should be able to change a vendor’s banking details. It might be allowed to prepare a payment without being allowed to release it. And five $9,000 payments made in quick succession may deserve a different control from one $45,000 payment even if every individual payment is technically inside the limit.
Traditional access control is good at asking whether this identity can perform this operation on this resource. Agentic systems increasingly force us to ask something different: given what this agent has already done, what else is happening around it and what the business is trying to accomplish, should it still be allowed to take the next action?
That is not just an IAM question because the answer depends on context that may sit outside the transaction being evaluated.
SAP’s work with NVIDIA is interesting for that reason. SAP says it is working to connect OpenShell’s runtime isolation with Joule Studio’s business-governance layer, linking technical execution boundaries to enterprise authorization models, IAM and audit trails. That integration is still being built, but the architectural separation makes sense: one layer controls what the software can technically reach, while another represents what the business has actually authorized it to do.
There is an even simpler example in NVIDIA’s announcement. Salesforce has integrated OpenShell with Slack so teams can see agent activity and approve or reject requests for additional permissions.
The approval does not necessarily have to be human. OpenShell already supports an optional auto-approval mode in which a policy checker can approve some network-policy changes without review when its risk checks find nothing to flag. At that point, the quality of the checker and the rules it applies become part of the authority architecture.
This is a migrating-scarcity problem
In Migrating Scarcity, I argued that making one capability abundant does not eliminate scarcity. It exposes the next constraint that the newly abundant capability still depends on.
We can already see that happening with agents. Execution itself is becoming dramatically cheaper. Code can be generated, systems can be called and actions can be initiated without waiting for the human effort that used to sit in the middle.
The scarce thing starts to move toward deciding how much authority to give that execution. That authority has to be clear enough for software to enforce, flexible enough to account for context, and documented well enough that somebody can reconstruct later why an action was allowed.
Most large companies already have a lot of this logic somewhere. Finance has approval thresholds, procurement has rules around vendors, risk teams have escalation criteria, and operating teams know when something unusual needs to be stopped.
The problem is that a great deal of that logic lives in spreadsheets, policy documents, workflow tools and people’s heads. An agent cannot reliably operate against a business rule that exists only as a sentence in a PDF.
That is why more of the business boundary itself will have to become executable.
The operating problem may be harder than the technology
Deny-by-default is straightforward when an agent has a narrow job and two tools. It gets much harder when the workflow legitimately crosses SAP, Salesforce, ServiceNow, email, internal databases and several external services, and the exact path may change depending on what the agent finds.
Lock the environment down too tightly and people spend their time clearing exceptions. Open it too far and you end up with an extremely well-contained agent that still has far more authority than anyone intended.
Someone has to write these policies, test them, watch how they behave and change them as the process changes.
Security cannot do that alone because many of these decisions are business decisions. Process owners cannot do it alone because they often cannot see every technical path an agent can take. AI teams understand how the agent works, but they should not be the ones deciding how much authority their own system receives.
There is a real discipline emerging in the middle of those three groups. Call it policy engineering or something else. The name matters less than the work: turning business intent into rules that software can enforce without making the business unusable.
And this is also where the architecture could fail in practice.
Fine-grained policies may become too complicated to maintain. Hard limits may create so much friction that teams start widening permissions simply to keep work moving. Enterprises could easily recreate, in software, the same bureaucracy agents were supposed to remove.
A launch and a partner list are not evidence that this operating problem has been solved.
That is why I would not read NVIDIA’s announcement mainly as an argument for BlueField hardware, or even as a verdict on OpenShell. The more useful signal is that the control surface around agents is moving out of the prompt and into infrastructure, identity, policy and business authorization.
We spent the first phase of enterprise AI trying to make models behave better. As agents start acting at machine speed, the harder problem will be deciding how much freedom they should have, how that freedom changes with context, and how we know later that they stayed within it.
The agent can reason about what to do. It should not get to decide how far its own authority extends.
