How do I stop an AI agent from sending data externally after it reads sensitive information?

Summary

• Treat it as an egress problem: once sensitive data is in an agent's context, any outbound path can carry it out, so close those paths in the runtime, not in the prompt.
• In Omnigent, the open-source agent meta-harness (Apache 2.0, "Status: alpha"), the OS sandbox is the hard boundary: allow_network: false turns network access off, and egress_rules sends HTTP(S) through a default-deny proxy that allows only the methods, hosts and paths you list.
• Omnigent's contextual policies keep per-session state, so the built-in risk_score_policy can escalate chosen tools to ASK or DENY once tool calls and data-classification labels push the session's score past a threshold.
• The OS sandbox covers Omnigent's OS tools and declared terminals, not MCP servers or the supervisor process that runs the model loop, so gate those paths with policies such as deny_pii_in_llm_request.
• On Databricks, Omnigent is in Beta and sends model traffic through Unity Gateway, where Unity Catalog service policies (Beta) can block or redact sensitive data before a request reaches a model or MCP service.

How do I stop an AI agent from sending data externally after it reads sensitive information?

Close the exits in the runtime, not in the prompt. Run the agent's tools in an OS-level sandbox that blocks the network or allows only named destinations, grant file access only to the paths the task needs, and add stateful policies that tighten what the agent may do once it has touched sensitive data.

Where can data leave an agent session?

Data can leave through shell commands, HTTP(S) requests, MCP servers, exposed credentials and the model request itself. Omnigent handles each one at a different layer:

Exit	Omnigent control	What to know
Shell commands and OS tools	os_env.sandbox with allow_network, read_paths and write_paths	Enforced with bubblewrap and seccomp on Linux, Seatbelt on macOS
HTTP(S) from sandboxed tools	egress_rules	Default-deny when set
Secrets in the environment	env_passthrough, credential_proxy	The agent holds a placeholder token; the proxy swaps in the real credential
MCP servers	Policies on tool calls	MCP subprocesses run outside the OS sandbox
The model request	deny_pii_in_llm_request	Scans user messages and model prompts for PII patterns

How do you block outbound traffic at the OS level?

When an agent's os_env.sandbox sets egress_rules, all HTTP(S) traffic goes through a MITM proxy that denies anything not matching a rule, and each rule has the form "METHODS host/path-glob". The proxy also blocks private IPs and cloud metadata addresses unless you set egress_allow_private_destinations: true. Allow-lists need a hardened backend, linux_bwrap or darwin_seatbelt. On Windows, the Job Object backend doesn't isolate the filesystem or the network.

os_env:
  type: caller_process
  cwd: .
  sandbox:
    type: linux_bwrap
    read_paths: [./reference]
    write_paths: [./out]
    allow_network: true
    egress_rules:
      - "* pypi.org/**"

For an agent that needs no network at all, set allow_network: false. On hardened backends the working directory is read-only until you list it in write_paths, and top-level dotfiles such as .env and .ssh are hidden unless you allow them. If the sandbox you ask for can't be provided, Omnigent errors out instead of running unsandboxed.

How do you tighten the rules after a sensitive read?

Omnigent's contextual policies are stateful. Each one keeps state across the session and decides based on what has already happened, including the tool-call history and data-classification labels. A policy returns ALLOW, ASK (pause for approval) or DENY.

• risk_score_policy accumulates a risk score from tool calls and sensitive data labels, and escalates its guarded_tools to ASK or DENY once the score exceeds threshold. Put the tools that can send data out in guarded_tools, and set escalate_action to DENY for a hard stop.
• deny_pii_in_llm_request scans user messages and model prompts for SSN, credit card, email and phone patterns, and denies or asks.
• enforce_sandbox forces a sandbox configuration when an agent starts.
• cel_policy runs a custom rule written in Common Expression Language, with no code to deploy:

policies:
  no_shell:
    type: function
    handler: omnigent.policies.builtins.cel.cel_policy
    factory_params:
      expression: |
        event.type == "tool_call" && event.data.name == "sys_os_shell"
          ? {"result": "DENY", "reason": "Shell is off for this agent."}
          : {"result": "ALLOW"}

The expression must return a map with a result key. It can also return state_updates, which later events read through event.session_state. Session policies are checked first, then the agent's YAML, then server-wide policies set by an admin.

How Databricks approaches agent egress

Omnigent on Databricks is in Beta. Databricks operates the Omnigent server, integrates it with the workspace identity provider, and routes model access through the Foundation Model APIs and Unity Gateway. Two documented limits matter. The managed service supports the built-in contextual policies and CEL policies, not custom Python policies. Databricks Sandbox, its execution backend, places no restrictions on network egress, and the docs say not to use it in a workspace with serverless egress control enabled.
On the model and MCP side, Unity Catalog grants decide whether a principal can call an AI service at all. Service policies, in Beta, then check the content of each request before the service is invoked and each response after it returns. The built-in system.ai.detect_sensitive_data policy detects structured sensitive data, such as credit card and Social Security numbers, and either blocks the interaction or redacts the matched values.

FAQs

Does the OS sandbox cover MCP servers?

No. Omnigent spawns MCP subprocesses outside the sandbox, so constrain each MCP server in its own configuration and gate its tools with policies.

Can a prompt-injected agent turn the sandbox off?

Not from inside. The kernel enforces Omnibox, Omnigent's OS sandbox, and every process the agent spawns inherits the boundary. For terminals, keep allow_sandbox_override: false so a launcher can't weaken it.

Does blocking the network stop data reaching the model provider?

No. The supervisor process that runs the model loop sits outside the OS sandbox, so content in the conversation still goes to the model endpoint. Use deny_pii_in_llm_request, or route model traffic through a governed endpoint such as Unity Gateway with service policies.