Skip to main content

Why AgentVisor™?

When you deploy autonomous agents that act across systems, the execution model gap creates concrete risks that standard deployment infrastructure doesn't address:

  • Data exfiltration: Agents could send sensitive data to unauthorized endpoints
  • Resource abuse: Uncontrolled API calls can rack up costs or violate rate limits
  • Prompt injection: Malicious inputs could hijack agent behavior
  • Compliance violations: Lack of audit trails makes governance impossible

Production Challenges

The Problem in Detail​

When you deploy an AI agent without additional protection:

Agents Have Unrestricted Network Access​

Your agent can call any URL. A prompt injection or buggy tool could:

  • Exfiltrate sensitive data to unauthorized endpoints
  • Hit internal services it shouldn't know about
  • Rack up costs on pay-per-call APIs
  • Violate compliance boundaries

Agents Run Arbitrary Code Paths​

Unlike deterministic services, agents make runtime decisions. You can't predict every code path, which means:

  • Standard allow-lists don't work
  • Security reviews can't cover all behaviors
  • Testing doesn't guarantee production safety

Agents Are Targets for Manipulation​

Prompt injection is real. Malicious inputs can:

  • Override system instructions
  • Invoke tools in unintended ways
  • Access data the user shouldn't see

You Have No Audit Trail​

When something goes wrong, you need to answer:

  • What did the agent do?
  • What external calls did it make?
  • Why was that decision made?

Without instrumentation, you're blind.

How AgentVisor Solves This​

AgentVisor provides containment and observability at the execution boundary — sandbox isolation, credential brokering, and policy governance deliver containment; audit logging and durable execution deliver observability — without limiting what agents can do:

RiskWithout AgentVisorWith AgentVisor
Network accessUnrestrictedAll HTTP proxied through policy engine
IsolationContainer boundariesDefense-in-depth: hardened sandbox + network isolation + optional syscall interception (gVisor)
Credential brokeringEnvironment variablesSymbolic tokens — real keys never enter sandbox
Principal-bound credentialsN/AOAuth token exchange and JWT (JSON Web Token) passthrough for scoped tokens
Unauthorized APIsHope your code is rightDeny-by-default, explicit allow-list
Internal network accessPossibleBlocked at network level
Untrusted tool code (MCP)npm/PyPI code runs in host processEach stdio MCP server isolated in its own per-server sandbox (gVisor or Docker)
Audit trailBuild it yourselfEvery request logged with full context
Policy decisionsNonePer-request PBAC (Policy-Based Access Control) evaluation

Zero-Trust by Default​

Agents in AgentVisor have no network access. None. Every HTTP request flows through a policy-controlled proxy. If it's not explicitly allowed, it's denied.

# Example: Allow only OpenAI and Anthropic APIs
resources:
  - name: llm-providers
    selector:
      - "mrn:agentvisor:http:api\\.openai\\.com.*"
      - "mrn:agentvisor:http:api\\.anthropic\\.com.*"
    group: "mrn:iam:resource-group:allowed"

Complete Host Isolation​

Every agent runs in a hardened security sandbox with no access to anything not explicitly granted. Agents cannot reach the host filesystem, network, OAuth tokens, secrets, or any other resource unless policy explicitly permits it. All external communication goes through a policy-enforced proxy, ensuring complete control over agent capabilities. On Linux, gVisor provides the strongest isolation; Docker mode delivers equivalent containment on any platform.

Defense-in-Depth Isolation​

AgentVisor applies 14 independent security layers. The key layers include:

  • Sandbox isolation: Container-based isolation prevents direct host access; in gVisor mode, a userspace kernel (gVisor) also intercepts every system call before it reaches the host kernel
  • Network isolation: Agents have no direct network access — all traffic routes through the policy proxy
  • Credential brokering: Real API keys never enter the sandbox — only symbolic tokens that are substituted at the host boundary
  • stdio MCP server sandboxing: Each stdio MCP server (arbitrary npm/PyPI code) runs in its own per-server gVisor or Docker sandbox, preventing untrusted tool code from reaching the host trust domain
  • Privilege separation: OpenSSH-style privsep with per-agent UID isolation prevents cross-tenant access

Additional layers include read-only filesystems, minimal Linux capabilities, seccomp syscall filtering, user namespace blocking, process visibility restrictions (hidepid), resource limits, environment variable curation, guest image hardening, and socket hardening. No single layer is perfect, but woven together they form a defense-in-depth approach that significantly raises the bar for any exploit to reach your infrastructure. See Sandbox Modes for details.

Next Steps​