NVIDIA today contributed OpenShell to the Cloud Native Computing Foundation as a Sandbox project under community-led stewardship. OpenShell is a runtime that provides agent governance and decides which actions they execute based on user-defined policies. It acts as a shared control layer that creates the runtime boundary and integrates with other software tools to manage agent behavior. Bedrock Data's part is knowing what the data is and what the business allows, and to see why that matters.
Consider a research agent. An analyst asks the agent for a view of a logistics company. The agent searches the firm's document stores, finds a slide, and summarizes it: a revenue multiple, a date six weeks out and two initials.
Nothing in that summary would trip a scanner that looks for patterns like card numbers or names, yet the slide came from a restricted deal folder, because the firm is preparing an unannounced acquisition of that company. The fragment is material nonpublic information, and the analyst's agent should never have seen it.
The data was sensitive because of where it came from, and nothing in the data itself could have told you that. Stopping it before it reaches the agent takes a check that sits outside the agent and knows the business, which is what OpenShell and Bedrock Data work together to accomplish.
OpenShell sees everything an agent does
An OpenShell agent runs in a sandbox with no direct network access. Every request it makes passes through the supervisor, a process outside the sandbox that checks the request against policy and logs the result. The agent cannot route around it.
The other place people put a data check is a hook inside a specific agent tool, such as the hooks in Claude Code or Cortex Code. Bedrock Data ships those too, and they are the right control when that tool is the only boundary you have, though they come with three limits:
- A hook covers one agent tool, and anything else running in the environment is uncovered.
- A hook sees data after the tool returns, when it is already in the agent's context.
- A hook runs inside the agent it is policing.
The OpenShell supervisor covers every path out of the sandbox, inspects responses before the agent receives them, and runs outside the agent, so a data decision can happen before the data enters the agent's context and nobody has to trust the agent's own account of what it did.
Where Bedrock Data fits
OpenShell manages the path the agent takes based on policies and which request may reach its destination. Bedrock Data decides the data: whether what the request carries may go where it is headed. It attaches through OpenShell's Supervisor Middleware, and the agent and its tools do not change.
For the research agent above:
- The agent requests the slide, and the supervisor checks the request against OpenShell policy. If it is not permitted, it stops here.
- The request is permitted, so the response comes back to the supervisor, which hands it to Bedrock Data before the agent receives it.
- Bedrock Data identifies the data, and fingerprinting matches the slide to the deck in the restricted deal folder.
- Bedrock Data checks policy. The deck is material nonpublic information (MNPI) and this agent is not authorized for it, so the verdict is deny, with the reason.
- The supervisor enforces it, and the slide never enters the agent's context.
The same path covers data going out. A support agent that files tickets with an outside vendor may send a summary of a customer's problem, and when its request also carries the customer's account record, Bedrock Data returns a redacted version of the request, so the ticket is filed and the personal data is stripped before it leaves the sandbox. Every verdict (allow, redact or deny) comes with a reason the agent can act on and is logged.
Why a scanner is not enough
A scanner can tell you a request contains something shaped like a card number. The decisions above turned on things the content does not show: where the data came from, who is entitled to it, and who will be able to read it next.
Bedrock Data gets those from the Metadata Lake, a graph of the company's data: what it is, where it lives, where it came from, who and which agents can reach it, and what policy says about it. We build it by scanning data in place, and only metadata ever leaves your environment.
Three cases show what the graph adds:
- Origin. The MNPI slide above is harmless as content and restricted because of its source, and fingerprinting ties the fragment to that source while the graph knows what the source is.
- Exposure. A customer record moving between two internal systems with the same audience is fine, while the same record headed to a third-party MCP server is a disclosure. The graph informs policy about who can reach each destination, so personal data can be redacted before it goes anywhere wider.
- Combination. In private equity, documents from separate deal rooms must stay apart, and an agent with access to both can combine them without any single permission being wrong. Once the agent has read from the first deal room, the second is off limits, and any read from it is denied.
Observe, review, then enforce
- Pick one agent and one sensitive data source. Choose an agent whose job requires a permission you are uneasy about.
- Attach Bedrock Data in observe-only mode. OpenShell forwards requests as usual, and Bedrock Data records the verdict it would have returned.
- Review the verdicts for a week. For each one that would have been redacted or denied, decide who approves it.
- Turn on enforcement. Expand by data source and by agent once the verdicts match what you expect.
The runtime is now built in the open
With OpenShell in the CNCF, the enforcement boundary for agents is something anyone can inspect, extend and depend on. To get involved, join the openshell-community mailing list, find the maintainers in #openshell-dev on CNCF Slack, and watch the ai-openshell GitHub organization.
OpenShell decides whether an agent's action is permitted and Bedrock Data decides whether the data in that action may go where it is headed, so every read and every write an agent makes is checked against the company's rules before the data moves.
Agent DLP for OpenShell is available to Bedrock Data customers today as an OpenShell supervisor middleware service. If you are attaching your own controls to the supervisor, I would be glad to hear what you are learning.
Frequently asked questions
What does OpenShell policy evaluate on each request?
The OpenShell supervisor evaluates every outbound request from an agent sandbox against policy at the binary, destination, method and path level, supplies credentials only where policy allows, and logs every allow and deny.
What does Bedrock Data add to OpenShell?
Bedrock Data adds a decision about the data inside a permitted request or response. It identifies the data in the request, checks company policy using context from the Metadata Lake, and returns a verdict (allow, redact or deny) to the supervisor, which enforces it.
How is using Bedrock Data with OpenShell different from a hook in an agent tool?
A hook runs inside one agent tool and sees only what that tool exposes, usually after the data has already come back. The OpenShell supervisor runs outside the sandbox, covers everything running in it, and inspects responses before the agent receives them, so a data check can stop data before it enters the agent's context.
Do agents or tools need to change?
No. Bedrock Data attaches at OpenShell's supervisor middleware, outside the sandbox, so agents and their tools run as they did before.
Can teams try it without blocking agents?
Yes. In observe-only mode OpenShell forwards requests as usual and Bedrock Data records the verdict it would have returned, so teams can validate policy before turning enforcement on.