AAXIS Logo
BLOGADVISORY SERVICESENTERPRISE AI
Published October 2, 2026Updated October 2, 20263 min read
byPrashant MishraPrashant Mishra

Governing AI Agents From Outside the Agent: What We Learned Testing NVIDIA OpenShell

KEY TAKEAWAYS

Enterprises can separate AI agent governance from agent development by enforcing policies at the runtime layer. Using NVIDIA OpenShell, AAXIS tested an architecture where each AI agent operates in an isolated sandbox with independent controls over what it can access, which APIs it can call, how credentials are used, and what actions are permitted. This creates a clear separation of duties: developers build the agents, while governance owners control what those agents are allowed to do—without changing the agent's code.

  • Governance can live outside the agent. Policies can control agent behavior independently of the agent's underlying code.

  • Access can be highly specific. Controls can restrict hosts, HTTP methods, paths, programs, and credentials for each individual agent.

  • Agents don't need direct access to real API keys. OpenShell can inject credentials only when an outbound request meets approved policy.

  • Policies can change while agents are running. Network rules can be updated without restarting the agent.

  • Every decision can be auditable. Allowed and denied actions can be captured in structured logs, including the policy rule responsible for the decision.

  • Runtime governance is only one layer. Application controls, model guardrails, and independent auditing are still needed to govern what agents say and how approved external services are used.

As AI agents move from demos into daily operations, governing them gets harder: who decides what an agent can reach, and how do you enforce it when the agent's own code could be manipulated? We tested this using NVIDIA OpenShell, an open-source runtime for running autonomous agents in isolated sandboxes governed by declarative policy. We ran five agents from Quillic, our AI-assisted sales intelligence platform (discovery, research, scoring, SEC filings analysis and action planning), each in its own OpenShell sandbox on a local gateway. Every sandbox gets its own YAML policy, which covers three things. Filesystem, process and Landlock settings are fixed when the sandbox is created. Network rules can be updated on a running sandbox, down to specific hosts, HTTP methods, paths and the programs allowed to use them. API keys are attached as OpenShell "providers": the agent only ever sees a placeholder, and OpenShell's proxy inserts the real credential on approved outbound requests. The agents never connect to our database directly. Their database operations go through Quillic's API, which checks each agent's tool allowlist and tenant scope before acting.

The results matched the policies. The scoring agent, whose policy allows only the model API, was blocked from calling a web search service. The research agent was blocked from sending data to a site outside its allowlist. A POST to SEC EDGAR from the filings agent was denied at the HTTP layer, while read-only GET requests to the same host were allowed. OpenShell also caught a mistake of ours. When we attached a worker credential to the wrong set of endpoints, it blocked the request and flagged it as "Provider credential used at an unauthorized endpoint." We updated the research agent's network policy several times while it kept running. Every allow and deny was written to a structured audit log (OCSF format) along with the rule that decided it, and we fed that log into a governance dashboard inside Quillic. The practical result is a separation of duties: developers build and ship agents, and a governance owner controls what those agents may do through policy, without changing agent code.

This is the runtime layer of agent governance, not all of it. OpenShell controls what an agent can reach, read and authenticate as. It doesn't judge what the agent says, so an approved call to a model or search API is still a channel that application controls, model guardrails and independent audit must cover. OpenShell is also early: we tested version 0.1.2, and its interfaces changed noticeably between releases. Our next steps use capabilities OpenShell already documents:

  • Agent-initiated policy proposals that wait for human approval
  • An advisor and prover that review policy changes before they apply
  • OpenTelemetry export to a monitoring stack owned by the governance team
  • Audit-only enforcement for agents that need the open web
  • A global policy override, which we've scripted but not yet validated in our tests

For enterprises scaling agentic AI, keeping governance out of the agent's own code is one of the most important architectural decisions they'll make.

FAQs

FAQs

AI agent governance is the set of controls that determines what an AI agent can access, which systems and APIs it can interact with, what credentials it can use, and what actions it is permitted to take. Runtime governance allows these controls to be enforced independently from the agent’s own code.

NVIDIA OpenShell runs AI agents in isolated sandboxes governed by declarative policies. These policies can control filesystem and network access, API credentials, approved endpoints, HTTP methods, and other permissions while creating an audit trail of allowed and denied actions. OpenShellGovenranceBlog

No. Runtime governance controls what an agent can reach, read, and authenticate as, but it does not determine whether the agent’s responses are appropriate. Enterprises still need application-level controls, model guardrails, and independent auditing as part of a broader AI governance strategy.

KEEP READING

You May Also Find Interesting

View All Articles

Engineered for; Impact.

Executed with; Excellence.