An engineering team gave a root-cause agent a routine job: investigate a backend failure and file a bug report detailed enough for the responsible team to reproduce it. The agent traced the failure to an open-source library, built a runnable reproduction from the company's private application, stripped the comments and unrelated code, and posted it to the library's public GitHub issue tracker. The reproduction still contained the company's pricing logic and now it was public.
No permission in that sequence was excessive. The agent needed permission to read the application because fixing bugs requires it and permission to file issues because the team had delegated reporting to it. The deployment followed least privilege. Each grant was the minimum the job required, but each grant was blind to what the report contained. Least privilege bounds what an agent can reach but not what it does within its reach, because permissions are not data-aware. Within a permitted operation, they cannot tell the company's pricing algorithm from a synthetic repro.
Today we are releasing Bedrock Data Agent DLP for NVIDIA OpenShell, which adds data context to the sandbox boundary where OpenShell enforces every action an agent takes.
Why least privilege does not fix this
The usual response of narrowing permissions does not work here. The acceptable bug report and the leaked one leave through the same permission: create an issue in a repository. Revoke it and the agent cannot report the bug; keep it and the agent can publish the pricing logic. There is no narrower grant between the two, because the difference is in the content of the report, not in the resource it targets.
Least privilege still matters, and reviewing what a job requires is the cheapest control available. But it answers whether an agent can perform an action, not what it may divulge.
What decides instead
Imagine instead that before the issue was filed, something examined the contents of the report, determined that it was intellectual property, recognized that it was about to enter the public domain, and blocked the action. We call this data authorization: before an operation executes, establish what information it carries, which restrictions apply to it and where it is headed, then allow or deny. The agent still investigates private code freely, because the check runs at the moment the data would leave.
Data authorization requires data context: a knowledge graph that connects the data, where it lives, where it came from, which identities can access it and what policy says about it. Without that context the check sees text; with it, the check sees the company's pricing algorithm heading for a public repository.
The sandbox is the right place to apply that context because it is the one boundary every action crosses, whether the agent acts through an MCP tool, a command-line invocation or code it wrote itself. An agent blocked at one path and free at another is not blocked.
How the integration works
NVIDIA OpenShell gives each agent a sandbox with kernel-level enforcement over its processes, filesystem and outgoing connections, in a zero-trust architecture where nothing is permitted by default. Outbound actions are checked against policy before they take effect. OpenShell's Supervisor Middleware is the extension point where an additional decision can be attached to that check, and that is where Agent DLP sits.
The sequence for the root-cause agent:
Agent DLP sits at the OpenShell sandbox boundary. OpenShell decides whether the operation is permitted; Agent DLP decides whether the data in the request may go where it is headed, using what the Metadata Lake knows about that data.
- The agent issues the request from inside the sandbox. OpenShell evaluates it against its own policy first. Is this operation, to this destination, permitted for this agent? If not, the request stops here and Bedrock Data never sees it.
- If the operation is permitted, the Supervisor Middleware sends the full request payload to Bedrock Data.
- Bedrock Data identifies what the payload contains using a combination of content fingerprinting and data categorization and classification. Fingerprinting matches the payload against data the graph already knows to be sensitive, and because it survives removed comments, renamed variables and light rewrites, a reproduction excerpted from a private repository still resolves to that repository. Categorization and classification evaluate the payload against the data types the company has defined, so data that has never been fingerprinted is still recognized for what it is.
- Knowing what the data is, Bedrock Data evaluates whether the proposed action is allowed for it. In this case the request is to create an issue in a public GitHub repository, the graph records the excerpt as intellectual property, and company policy requires intellectual property to stay within private repositories, so Bedrock Data returns deny.
- OpenShell enforces the decision and the request never reaches GitHub.
The decision is made on what the graph knows about the data and its destination, not on whether the payload looks sensitive. A detector for things that look like secrets would have passed this report, because pricing logic looks like ordinary code, and a generic code detector would have blocked it along with every safe reproduction built from a synthetic sample, because it cannot tell the company's code from an example written to resemble it. Knowing that the excerpt came from the company's private repository is what separates the two, and only the graph knows that.
A denied agent is not a dead end, because the middleware returns the reason with the decision, so the agent can rebuild the reproduction from an approved public example and resubmit, or route the report to whoever the company has designated to approve a disclosure. Clear cases proceed without a person in the loop, and only the cases policy cannot resolve reach an approver.
Agent DLP for OpenShell also runs in observe-only mode. OpenShell forwards the request as usual and Bedrock Data records the decision it would have returned. Teams see what enforcement would have blocked before it blocks anything, and turn enforcement on when the decisions match what they expect.
Where the data context comes from
The data context Bedrock Data decides from is the Metadata Lake, a knowledge graph that connects what the enterprise's data is with where it lives, where it came from, which identities and agents can reach it, what it combines into and what policy says about it. We build it by discovering and classifying data in place across cloud, SaaS, AI and on-premises environments, and we keep it current as data and permissions change. Because the graph holds permissions alongside data, it also answers a question at design time that most teams cannot answer today: given the permissions this agent holds, what data can it reach, what does that data combine into, and where would policy be violated? That is an agent's blast radius before it runs.
Three cases the check has to handle
- Toxic combinations. Some restrictions depend on what the agent has already read. We see this with our private-equity customers. Documents from separate deal rooms cannot be combined, so the check has to evaluate the next read against what the agent already holds. Each file on its own passes, the combination is the violation, and blocking an eventual publication is too late, so the check has to run before the read.
- Drift. Data changes under stable permissions. A folder approved for operational documents acquires employee records, and the agent's exposure grows without a single grant changing. Because decisions come from the graph rather than from rules written against a snapshot, they change as the data changes, without anyone rewriting a rule.
- Handoffs. Fleets of long-horizon agents fan out into sub-agents, and a reporting agent that never read the private repository can still publish what a diagnostic agent handed it. Because the decision rests on the data and its destination rather than on which agent is asking, the restriction travels with the data across tables, tools and agents.
Why this is not already done
Defining permitted use is organizational work with no natural owner. The repository owner knows what the code is, the disclosure policy assigns approval to someone else, and lineage lives in a third system if anyone recorded it. Connecting them is nobody's backlog item until an agent publishes something, at which point it is everybody's. The runtime can enforce a decision, but it cannot know what the data means or what the company's rules are, which is why the integration is two products rather than one.
Before deploying an agent with sensitive permissions
- Confirm the permission is part of the job. If it is not, remove it and stop here; if it is, the remaining steps are where the control lives.
- Run Agent DLP in observe-only mode on one agent with one sensitive repository, and read the decisions for a week.
- For each disclosure that observe-only mode surfaces, decide who approves it and record that decision, because the check has nowhere to escalate until someone owns it.
- Turn on enforcement for that agent, then expand by repository and by agent.
- Check the design-time blast radius before each expansion, so the first surprise is in a report rather than in production.
Least privilege is not least risk. It decides what an agent can reach, not what it may do within that reach, and deciding that takes a sandbox that sees every action and data context that says what the action carries. NVIDIA OpenShell is the sandbox, the Metadata Lake is the context, and Agent DLP connects them.
Agent DLP for NVIDIA OpenShell is available today to Bedrock Data customers as an OpenShell supervisor middleware service. Learn more about Agent DLP or request a demo. If you are working through these decisions in your own deployments, I would like to compare notes.