By Venkata Koppaka, Co-Founder and CTO, TENEX.ai
NVIDIA invited TENEX.ai to participate in the launch of the NVIDIA Open Agent Safety Platform. The part I’m particularly interested in is NVIDIA OpenShell, and how we might use it to put runtime boundaries around our own agents.
Setting boundaries for our own agents
Think about what a security agent actually does. It reads phishing emails, investigates suspicious URLs, and examines scripts someone may have written to compromise a system. It’s going to encounter malicious instructions. In some cases, understanding those instructions is the whole point of the investigation.
We need the agent to work with that material without letting the material change what the agent is allowed to do. Content screening helps, but we also need controls around the files it can access, the credentials it can use, and the destinations it can reach.
NVIDIA designed OpenShell to enforce those controls outside the agent, including controls over execution and inference. NVIDIA’s stated design is that the agent can’t override them even if it has been compromised. That’s what we want to evaluate for future TENEX.ai agents.
We already make a related distinction in our agentic Security Operations platform. A playbook can guide an investigation, and a model can conclude that an endpoint should be isolated. Whether the system is allowed to isolate that endpoint is a separate decision. Our response architecture checks policy when the action is about to execute, against the customer, target, operation, and applicable approval.
OpenShell could extend that approach into the runtime. That’s how I think about Fully-Agentic, Human-Led Security Operations: people shouldn’t have to approve every routine lookup, but they do need to decide what authority they’re delegating, when approval is required, and when the system should stop and ask for help.
Bringing agent activity into the SOC
There’s another part of this that matters for agentic Security Operations: the record of what the runtime allowed or denied.
Take an agent that’s supposed to summarize an internal document. It tries to send data to an unexpected destination, and the runtime blocks it. Good, the boundary held. But I’d still want to know why it tried.
Maybe the document contained an instruction that redirected the agent. Maybe a legitimate integration was configured incorrectly. Maybe the task itself wasn’t authorized. We’d need the task, the content it encountered, the identity it used, and the surrounding activity to work that out. Those explanations lead to different responses, from correcting a configuration to pausing the agent and investigating further.
I’d also want to look at allowed actions. An agent can have permission to use a credential and still use it for something unrelated to the job it was given.
That’s where I see the opportunity for TENEX.ai. We want to evaluate the boundaries around our own agents and understand how OpenShell’s allow/deny data could become useful evidence for the SOC. The runtime can prevent an action. The security team still has to understand what happened, whether anything else was affected, and what to do next.
Read NVIDIA’s announcement
Resources: