How NVIDIA OpenShell and Sentry Limit an Agent’s JSON Tool Calls (2026)
The model still only fills JSON. On 28 September 2026 NVIDIA put the boundary outside the model: OpenShell reads the tool name on tools/call in the sandbox proxy, and Sentry quarantines out of band on BlueField-4. Allowing lookup_order does not allow an arbitrary order_id.
Before you read
| Layer | Official fact | What blocks the call |
|---|---|---|
| OpenShell | Apache 2.0. Sandbox plus kernel isolation. The proxy inspects the request body the sandbox sends to an MCP server | Allow or deny by tool name. Arguments are not matched |
| Sentry | Out-of-band watchdog on BlueField-4. Quarantines a breach of the software boundary in milliseconds. Reference design, optional | Hardware stops execution. It does not fill JSON |
| Policy prover | Runs in the gateway. New credentialed reach, new HTTP methods, or cloud metadata block auto-approval | Before a policy change. Not the runtime Schema |
| Host Schema | The docs: an allowed tool accepts any arguments | Check arguments before execution |
Facts from the 28 September 2026 NVIDIA newsroom post, technical blog, and OpenShell policy docs. Order A-1042 is fictional. The JSON below is the same fields as the documented YAML, not an unpublished Sentry wire schema.
OpenShell blocks the tool name. Sentry blocks execution past the boundary.
The Open Agent Safety Platform is two pieces, not another chat permission. The first is OpenShell, Apache 2.0, broadly available. It sandboxes an agent on a CPU: the kernel governs files, system calls, and the network, and the proxy inspects HTTP leaving the sandbox. An MCP endpoint uses protocol: mcp. It inspects the request body the sandbox sends to the server and can allow or deny by method and by the tools/call tool name. The second is Sentry, a reference design. It runs on a BlueField-4 DPU, out of band, beyond the agent’s reach. If the agent leaves the software boundary, Sentry quarantines and stops it in milliseconds. In a Vera Rubin POD that DPU sits on the node’s only path to the model. Third, arguments are in neither layer. OpenShell says tool-argument matching is not supported yet. An allowed tool accepts any arguments the server accepts.
- OpenShell:
lookup_ordercan be allowed.refund_ordergoes indeny_rules. - Sentry: an optional hardware layer. It correlates interactions, policy decisions, and tool access, and it checks identity. It does not replace the tool list.
- The host: whether
A-1042is legal is still a Schema check onarguments.
allow / ask / deny inside a session is a different gate: the coding-agent permission model. The shape of MCP tools/call: how a coding agent calls MCP. Lab breakout reports are already covered: the agent security crisis and JSON validation. This piece does not retell those events. It only splits how OpenShell and Sentry stop one tool call.
The proxy sees tools/call, not the model’s prose
OpenShell parses the JSON-RPC request the sandboxed process sends to the MCP endpoint. Fictional order. The hostname is orders.example.com:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "lookup_order",
"arguments": { "order_id": "A-1042" }
}
}
It checks method and params.name. By default the tool name must also match ^[A-Za-z0-9_.-]{1,128}$. That switch is mcp.strict_tool_names, default true. Wildcard tool matchers require it to stay on. order_id inside arguments is not part of this policy. JSON-RPC responses, and server-to-client MCP messages on response bodies or SSE, are relayed and are not parsed for policy. One denied call denies the whole batch.
Write the policy by tool name. Put arguments on another gate.
The docs ship YAML, applied in full with openshell policy set. Incremental policy update --add-endpoint does not accept mcp yet. The JSON below is the same fields, so you can diff it. Lookup is allowed. Refund is denied. mcp.allow_all_known_mcp_methods defaults to false, so each method is listed. Omitting mcp.versions allows only the 2025-11-25 revision:
{
"version": 1,
"network_policies": {
"orders": {
"name": "orders",
"endpoints": [{
"host": "orders.example.com",
"port": 443,
"path": "/mcp",
"protocol": "mcp",
"enforcement": "enforce",
"mcp": {
"strict_tool_names": true,
"max_body_bytes": 65536
},
"rules": [
{ "allow": { "method": "initialize" } },
{ "allow": { "method": "notifications/initialized" } },
{ "allow": { "method": "tools/list" } },
{ "allow": { "method": "tools/call", "tool": "lookup_order" } }
],
"deny_rules": [
{ "method": "tools/call", "tool": "refund_order" }
]
}],
"binaries": [{ "path": "/usr/bin/python3" }]
}
}
}
filesystem_policy and landlock lock at sandbox creation. network_policies can hot-reload. The binary path belongs in the rule: which program may reach which endpoint. Outbound policy does not allow private networks by default, and it does not authorize loopback, link-local, or the cloud metadata address. After lookup_order is allowed, the argument gate is the host:
{
"type": "object",
"properties": {
"order_id": { "type": "string", "pattern": "^[A-Z]-\\d{4}$" }
},
"required": ["order_id"],
"additionalProperties": false
}
This Schema is not an OpenShell field. After the proxy allows the tool name, the host still rejects a missing field, an extra field, and an order_id that is not shaped like A-1042. Why Schema is a gate: why AI needs JSON Schema.
Four gates. Do not merge them.
They are all called safety. They look at different objects:
| Gate | What it sees |
|---|---|
| OpenShell proxy | The request from the sandbox to orders.example.com:443/mcp. Method, tool name, and the calling binary. Not arguments. |
| Host Schema | Arguments of lookup_order. Type, required, pattern. Execution happens after the gate. |
| Coding-agent allow / ask / deny | Shell, Git, and file tools inside the session. That list lives in the harness. OpenShell is another layer outside the sandbox. |
| Sentry | Out-of-band execution on BlueField-4. A breach is quarantined. The public posts do not publish a Sentry JSON field list. Do not treat this policy object as that list. |
A policy change can also pass the prover before it takes effect. The prover flags new credentialed reach, new HTTP methods, and access to cloud metadata. A finding blocks auto-approval. The CLI is openshell-prover, suitable for CI. An agent may submit a narrow proposal through Policy Advisor. Approval happens outside the sandbox. How the loop and state land: agent harness and JSON state.
Six steps before you widen a rule
Do not start by turning Sentry on. Name which layer blocked which call:
- Separate the model JSON from the runtime policy. The model fills
params.name. OpenShell decides whether that name may leave the sandbox. - Write the filesystem and Landlock when the sandbox is created. Those sections do not hot-reload like network rules.
- Fill in the MCP endpoint.
host,port,path: /mcp,protocol: mcp,enforcement: enforce. Do not share that host and port with another inspected protocol. - List tool names one by one.
initialize,notifications/initialized,tools/list, thentools/callwithlookup_order. Putrefund_orderindeny_rules. Leavestrict_tool_namestrue. - Give arguments to a host Schema. The proxy does not read
order_id. A refund stuffed into an already allowed tool is invisible to this layer. - Diff before you widen, and run the prover. Sentry is the optional BlueField-4 layer. Without that DPU, do not write the quarantine as something that already happened.
If one call in a JSON-RPC batch is denied, the whole batch is denied. Do not probe a lookup and a refund in the same batch. Server responses are outside this policy.
Before you widen a rule, spread three objects
A denial is a tool name, a binary path, a host and port, or an argument shape. Split those before you edit the prompt.
- format the
tools/callbeside the policy, then Schema validate whetherargumentspass the gate. - Use JSONPath extract for
$.params.name,$.method, and$.arguments.order_id. - JSON Diff
network_policiesbefore and after a widening. Look at the new tool name before you rewrite the prompt. - Sandbox logs name the denied host, path, and binary.
openshell logs --tail --source sandbox. - redact tokens in logs first. Do not paste orders or secrets into a public formatter. JSONSort runs in the browser.
If those three objects line up, you know which layer stopped refund_order. A Sentry quarantine record is not one of those three JSON objects.
Common traps
- Treating OpenShell as session allow / ask / deny. That list lives in the harness. OpenShell is the sandbox proxy and the kernel. Keep both policies.
- Assuming an allowed tool name checked order_id. The docs say argument matching is not supported yet. The host Schema stays.
- Inspecting only the model reply. The proxy sees the request body sent to the MCP endpoint. Responses and SSE are not parsed today.
- Letting the sandbox approve its own policy. Policy Advisor only submits a proposal. Approval is outside the sandbox. A prover finding blocks auto-approval.
- Writing Sentry as a JSON Schema. The public posts describe out-of-band quarantine and correlation on BlueField-4. Without a field list, do not invent one.
- Using this piece to retell a breakout. Those events are already on the site. This text only shows how a boundary stops one
tools/call.
FAQ
Can Sentry replace OpenShell?
No. OpenShell is the software runtime: sandbox, kernel, and outbound policy. Sentry is the optional out-of-band layer on BlueField-4. It quarantines a breach in milliseconds. Without that DPU you have the OpenShell layer only. Both sit outside the model.
Does the proxy read tools/call arguments?
No. It matches method and tool name. An allowed tool accepts any arguments. One denied call denies the whole batch. The host Schema checks the argument shape again.
Is this the same file as Cursor or Claude Code permissions?
No. Those files decide whether Shell, Git, and file tools may run inside a session. OpenShell decides whether a binary in the sandbox may send an MCP request to a host and port. One lives in the harness. The other is the sandbox boundary.
What does the prover block?
It checks a policy with formal verification before the policy takes effect. New credentialed reach, new HTTP methods, and access to cloud metadata are flagged, and a finding blocks auto-approval. It does not replace the runtime tool-name rules or Schema.
Are MCP responses from the server filtered too?
Not in the current docs. JSON-RPC responses, and server-to-client MCP messages on a response body or SSE stream, are relayed without policy parsing. Check the request that leaves the sandbox.
Conclusion
This NVIDIA platform puts the tool-call boundary outside the model. OpenShell allows or denies an MCP tool by name. Sentry quarantines execution past the boundary on BlueField-4. The host still checks arguments with Schema.
Write down that lookup_order is in rules, refund_order is in deny_rules, and A-1042 is in the host Schema. When those three line up, the call is actually limited.
Further reading
- The coding-agent permission model allow / ask / deny is not the sandbox layer
- How a coding agent calls MCP The JSON-RPC shape of tools/call
- The agent security crisis and JSON validation Those events are already written. This piece does not retell them
- Agent harness and JSON state Loop, gate, state
- Why AI needs JSON Schema Schema is a gate
- JSONSort local toolbox Format, validate, Diff, Schema
- All posts More notes on JSON and AI development
Changelog: First published