An instruction tells an AI agent what it should do.
A boundary determines what it can do.
That difference matters the moment an agent moves beyond answering questions and starts touching customer records, purchase orders, accounting entries, production systems, or employee accounts.
You can tell an agent, “Never approve a refund above $500.” But if the agent has unrestricted access to the payment system, that rule still depends on the agent interpreting and following its own instructions correctly. The same system deciding what to do is also being trusted to police itself.
That is not governance. It is hope written into a prompt.
The important signal in NVIDIA’s announcement
NVIDIA has announced its Open Agent Safety Platform, built around OpenShell and Sentry. NVIDIA describes OpenShell as a secure runtime boundary that traces agent actions and enforces policy. It describes Sentry as an independent, out-of-band watchdog that monitors behaviour and can stop an agent that moves outside its software boundary.[1]
Those are vendor claims, not independently verified business outcomes. But the architecture points to an operating principle every SME can use now.
My rule is simple:
An agent doing consequential work needs controls it cannot modify, bypass, or overrule.
This does not mean every SME needs specialised hardware or a complex enterprise security stack. It means the control plane must sit outside the agent’s reasoning loop.
The agent can propose. The business authorises.
The agent can execute. A separate system constrains.
The agent can report. An independent record proves what happened.
That is how AI moves from an impressive demo to a dependable digital coworker.
Why instructions alone are not enough
An agent is not a static automation script. It interprets context, selects tools, adapts its plan, and handles exceptions. That flexibility is exactly why agents are useful. It is also why they need stronger operational boundaries.
Three problems appear when governance exists only inside the agent’s instructions.
First, business language is ambiguous. “Use reasonable judgment” may sound clear to a manager, but it is not an enforceable permission.
Second, context changes. A new email, customer note, or document can alter what the agent believes it should do. The agent may remain obedient while acting on incomplete or manipulated information.
Third, access tends to spread. Teams often give an agent a broad employee account because it is faster than designing proper permissions. The pilot works, so the shortcut becomes permanent. One useful workflow quietly gains access to far more data and tools than it needs.
The answer is not to remove autonomy. The answer is to contain it.
The five-control model for SMEs
1. Give every agent a separate identity
Do not let an agent operate through a shared administrator login or an employee’s personal account.
Give it a named service identity. Make the owner, purpose, and approved systems visible. If the workflow ends, disable that identity without affecting a person’s access.
A digital coworker needs its own staff pass.
2. Apply least-privilege access
An accounts-receivable agent that drafts payment reminders does not need permission to change bank details. A CRM research agent does not need permission to delete opportunities. An IT diagnostic agent does not automatically need production write access.
Start with the smallest permission set that can complete the bounded workflow. Expand only when a tested business need justifies it.
Permissions should answer four questions:
- Which records can the agent read?
- Which fields can it change?
- Which actions can it execute?
- What value, risk, or customer threshold forces escalation?
3. Keep an immutable action log
Chat history is not an audit trail.
Record the agent identity, requested action, data or tool used, approval received, result, timestamp, and error state. The agent should not be able to edit or delete that record.
When something goes wrong, “the AI did it” is not an explanation. Operators need to reconstruct what happened, why it happened, and which control allowed it.
4. Put human approval before high-impact actions
Human-in-the-loop does not mean a person watches every click. It means people retain decision rights where consequences are material.
Set explicit approval gates for actions such as:
- sending an external message to a customer;
- changing a price, payment term, or bank detail;
- issuing a refund or credit note;
- deleting data or disabling an account;
- changing production configuration; or
- committing the company to a deadline, purchase, or contract.
The agent should prepare the action and evidence. The authorised person should approve the exact transaction.
5. Maintain an independent kill switch
The team needs a way to stop the agent without asking the agent to stop itself.
That could mean disabling its service account, revoking an API key, pausing a job queue, removing tool access, or switching the workflow into read-only mode. The mechanism depends on the system. The principle does not.
Test the kill switch before launch. A control that nobody has exercised is only a theory.
A hypothetical ERP workflow
Consider a hypothetical purchasing agent for a small distributor.
Its job is to monitor stock levels, prepare replenishment orders, and send low-risk orders to approved suppliers.
A weak design gives the agent an ERP administrator account and tells it to “stay within policy.” It can read every supplier record, change bank details, create unlimited purchase orders, and post transactions. The prompt is carrying the entire control burden.
A governed design looks different.
The agent has its own identity. It can read stock, lead-time, and approved-supplier data. It can draft purchase orders only for listed products and suppliers. Orders below a defined threshold can enter a review queue; orders above it require named approval. Supplier bank details are read-only. Every action is written to a separate log. Operations can disable the agent account and pause the queue independently.
The agent still does useful work. It just cannot turn one mistaken instruction or compromised document into unrestricted action.
The pre-deployment checklist
Before an agent touches a live workflow, ask:
- Outcome: Is the responsibility narrow enough to describe in one sentence?
- Identity: Does the agent have its own named account and owner?
- Access: Can it reach only the records, fields, and tools required?
- Authority: Which actions can it complete, and which require approval?
- Evidence: Is every consequential action recorded outside the agent’s control?
- Containment: What prevents the agent from exceeding its permission boundary?
- Shutdown: Can an authorised person stop it immediately?
- Accountability: Which human owns the outcome when the workflow fails?
If any answer is unclear, the workflow is not ready for autonomous execution.
Orchestrate, do not abdicate
The goal is not to keep agents trapped in chat. The value appears when they can act across real business workflows.
But delegation is not abdication.
Operators still define the outcome, prepare trusted context, grant authority, review exceptions, and own the result. The agent handles execution inside those boundaries.
As agents become more capable, the winning companies will not be the ones that remove every human checkpoint. They will be the ones that know exactly which checkpoints matter—and enforce them outside the agent.
Give the digital coworker room to work.
Give its supervisor the final word.
Sources
[1] https://nvidianews.nvidia.com/news/open-agent-safety-platform