Ahmadreza Samadi / Home

Explainer · AI agents and permissions

AI agent safety: boundaries before actions

An AI assistant that only answers a question and an agent that can use tools need different safeguards. The moment software can act, permissions become part of the product design.

By ·

Updated

At a glance

Before giving an AI agent access, define which account it acts as, what data and tools it can reach, whether it can read or change things, and which actions need approval. Enforce permissions outside the model, log attempts and failures, and keep a way to revoke access. No single boundary proves an agent safe.

On 28 September, NVIDIA announced its Open Agent Safety Platform. The announcement combines OpenShell software with a separate Sentry reference system design. It is a useful prompt to ask where an AI agent’s limits should live—and what happens if it tries to cross them.

Why agents need more than a careful prompt

A chatbot may explain how to organize an inbox. An agent with email access might actually send, move or delete messages. The second system needs explicit limits on which account it uses, which data it can reach, which tools it may call and which actions require a person’s approval. Instructions inside a prompt are not a substitute for enforceable permissions outside the model.

What OpenShell and Sentry do

According to NVIDIA, OpenShell is an open-source secure runtime that traces agent actions and enforces policy while the agent runs. NVIDIA says OpenShell is now broadly available. Its software boundary is intended to restrict what the agent can do even if the model asks for more.

Sentry is different: NVIDIA describes it as an out-of-band watchdog in a reference system design using BlueField-4 DPUs. It is designed to monitor agent behavior and quarantine an agent that moves outside its boundary. The announcement does not mean Sentry is installed in every AI assistant, or that every system using OpenShell also has this hardware layer.

Which four boundaries would I check before granting access?

  1. Identity: Which user or service account is the agent acting as?
  2. Scope: Which files, messages, records and tools can it reach?
  3. Action: Can it only read, or can it also send, change and delete?
  4. Oversight: Which actions require approval, and how are attempts and failures logged?

The room-and-guard analogy is helpful: grant access to one room, then independently watch the door. But no single boundary proves an agent is safe. Teams still need task-specific tests, review paths and a way to revoke access.

What would I test before allowing an agent to send email?

I would start with a narrow use case: let it draft a message, but require a person to approve the recipient and contents before sending. Next, test what happens when the agent reads misleading instructions inside an email, asks for a tool outside its allowed scope or retries after a denial. Only then should the team consider broader autonomy, with a measurable benefit and a clear rollback path.

Continue the discussion

The seven-slide Instagram carousel explains these ideas visually, and the LinkedIn document post discusses the boundaries in more detail. For the related question of what a connected assistant can read or change, see Connected AI apps: access, scope and approval.

Source