AI Agent Permissions Need More Than a Prompt

Before you give an AI agent access to your business, ask the person deploying it to demonstrate one thing: an action the system will refuse to take.

A convincing demo usually shows the successful path. The agent finds information, prepares a recommendation, and updates a record. That proves something useful. It leaves an equally important question unanswered: what prevents the same agent from reaching the wrong customer account, sending an unapproved message, or changing a record outside its assignment?

This week's agent-security announcements make that question more urgent. Our view is that business leaders should use them to raise their acceptance standards for AI workflows, regardless of which platform they buy.

What changed this week

On September 28, 2026, NVIDIA announced its Open Agent Safety Platform, combining OpenShell runtime software with the Sentry reference system design. NVIDIA describes controls outside the agent that govern execution and access, with separate monitoring in the reference design. These are vendor-described capabilities, not results from a Revival Group evaluation. Read NVIDIA's announcement.

Anthropic's same-day announcement describes using Claude Managed Agents with OpenShell to separate credentials from the agent and enforce limits on what it can execute and reach. Read Anthropic's explanation.

The practical implication is broader than either product. When an agent can act across business systems, its access needs an enforcement mechanism. Instructions in a prompt express intent. The surrounding system must decide which actions are allowed and prevent the rest.

Translate the assignment into actual permissions

Consider a hypothetical customer-service workflow. An agent reviews an incoming request, reads the relevant account history, and drafts a response for a staff member.

That assignment does not automatically require permission to issue refunds, export every customer record, or send email. Yet a broad account connection can make those actions technically available unless someone deliberately restricts them.

Start with the smallest useful scope. Specify the records the workflow can read, the changes it can propose, and the actions it can execute. Enforce account boundaries in the integration or service that handles the request. Giving the model a customer ID and asking it to stay within that account is not an access-control test.

For this example, the initial deployment could read the assigned customer's service history and save a response draft. Sending the response would remain a separate action requiring approval. Refunds would be outside the workflow entirely.

The owner should be able to explain that boundary in ordinary language. The implementation team should be able to show where it is enforced.

Make approval specific enough to mean something

An approval button is useful only when the reviewer can see what they are authorizing.

For an outgoing customer message, that means the recipient, the exact message, any attachments, and the account context. If the agent changes the recipient or rewrites the message after approval, the previous approval should no longer authorize sending it.

The same principle applies to a CRM update. Show the existing value, the proposed value, and why the change is being requested. A general instruction to clean up the pipeline gives a reviewer too little information to judge individual changes.

Decide what happens when nobody responds. In the customer-service example, the draft should remain pending and the assigned owner should see that work is waiting. Silence should not expand the agent's authority.

This connects to our earlier discussion of designing the exception path. A blocked action needs a useful destination, with enough context for a person to resolve it.

Test the boundary before expanding access

Ask for a controlled demonstration using test records. Include a permitted action and deliberate attempts to cross the boundary.

For the customer-service workflow, a practical acceptance check would include:

• Reading a different customer's record. The request should be denied by the access layer.
• Sending a response without approval. The send operation should remain blocked.
• Changing an approved message. The changed version should require a new decision.
• Repeating a completed send after a timeout. The workflow should reconcile the result before attempting another send.

Record what was attempted, what enforced the decision, and what the operator could see afterward. A model saying it will not perform an action is weaker evidence than the underlying service rejecting the request.

Also test the cost of those controls. If routine requests get blocked unnecessarily, staff may start looking for workarounds. Measure legitimate completion, unnecessary escalations, and review time alongside prohibited actions prevented. The goal is a workflow people can operate reliably.

Give someone responsibility for keeping the limits current

Permissions change as a workflow grows. A new connector, a broader service account, or a revised approval rule can change what the agent is able to do even when the original prompt stays the same.

Assign an operating owner who reviews those changes and can pause the workflow. Keep a record of the approved scope and rerun the relevant boundary checks when access changes. This is part of the ownership an AI system needs.

For your next deployment review, bring one workflow and ask for evidence of its limits. Start with a narrow assignment, prove that useful work completes inside it, and expand access deliberately.

Revival Group helps organizations define and operate these workflows, including integrations, approval controls, monitoring, and ongoing accountability. Talk with us about the workflow you're preparing to put into production.