Secure AI Agents with Tensorlake Dynamic Network Policies

Tensorlake introduced dynamic network policies for its Sandboxes product, enabling AI agent workloads to change network boundaries during execution phases—trusted context, approved tool, network isolation, and controlled recovery—without recreating the sandbox or losing state. The company published source code and five experiments on GitHub demonstrating the pattern, which reduces security exposure by granting least-privilege access per phase rather than static permissions.

Imagine an AI agent operating inside a production banking workflow. It retrieves approved business context such as lending policies or risk information, calls an approved service or tool, and then processes the collected information locally before producing a result. Functionally, this is one continuous workflow. From a security perspective, however, each stage may require a different network boundary. Context retrieval needs access to a trusted source, tool execution may require a different destination, and local computation may require no new outbound connections at all . A static network policy designed around everything the workload might need can therefore grant more access than the current phase requires. For increasingly autonomous AI agents that consume external content, invoke tools, maintain state, and execute model-generated actions, that creates unnecessary security exposure. This changes the least-privilege question. Instead of asking: What network access does this sandbox need? we can ask: What network access does this workload need right now? That is the idea I wanted to test with Tensorlake Sandboxes . Rather than treating network access as a static property of a long-running sandbox, I built a workflow in which the network boundary changes with the execution phase: Trusted Context → Approved Tool → Network Isolation → Controlled Recovery The key constraint is that the workload itself remains intact as the network policy changes. The sandbox should not need to be recreated, the persistent worker should remain alive, and filesystem state and intermediate results should survive across phases. The goal was therefore simple: Change the privilege, not the workload. In this article, we will build and validate that pattern end to end using Tensorlake Sandboxes, then examine what it means for designing secure, long-running AI agent workloads in production. The complete source code, all five experiments, and the captured outputs accompanying this article are available on GitHub: Tensorlake Secure AI Agent Execution Examples — GitHub The repository includes the progression from inspecting Tensorlake’s network-policy capabilities through runtime policy transitions, phase-based access control, persistent-worker validation, and the final end-to-end secure agent execution workflow. A production AI agent may retrieve trusted information, invoke an approved service, process returned data, and execute code while maintaining state across the workflow. These actions are part of the same task, but they do not require the same network privileges. Consider a lending or risk workflow. The agent may first need an approved policy or knowledge source, then a specific risk or fraud service. Once those inputs are available locally, subsequent computation may require no new outbound connections. A simplified execution path looks like this: Phase 1: Trusted ContextAgent → Approved policy or knowledge sourcePhase 2: Approved ToolAgent → Approved external servicePhase 3: Local ProcessingAgent → No outbound network accessPhase 4: Controlled RecoveryAgent → Restore or transition network access With a static network policy, destinations required at different stages may remain available throughout the workflow, even when the current phase no longer needs them. That matters for AI agents whose behavior can be influenced by user input, retrieved content, tool responses, and model-generated instructions. A prompt can guide which resources an agent should use, but it is not an infrastructure security boundary. A stronger model is to make network privileges follow the execution phase. Each phase exposes only the destinations required for new connections at that point in the workflow. During local processing, new outbound connections can be blocked entirely. The security model therefore becomes: Trusted Context ↓Approved Tool Access ↓Network-Isolated Processing ↓Controlled Recovery The challenge is doing this without recreating the sandbox, restarting the worker, or losing the state accumulated during earlier phases . That is the production behavior we need to prove experimentally. For phase-based security to work with a long-running AI workload, four behaviors need to hold together. Finally, these transitions should preserve the persistent worker and its accumulated state. The experiment therefore validates four properties: 1. Runtime policy mutation Change network access on a running sandbox2. Destination-specific access Allow only the destination required by the current phase3. Network-isolated execution Continue local computation with outbound access disabled4. Execution continuity Preserve the worker, filesystem, and intermediate state across policy transitions Together, these tests demonstrate something more useful than a configuration update: the network security boundary can change while the workload itself continues running. The next question is how to change the network boundary without interrupting the running workload. Tensorlake Sandboxes support runtime network-policy updates, allowing the surrounding application to apply network access appropriate to the current execution phase. For example, trusted-context access can be restricted to a specific destination: network policy = NetworkConfig allow internet access=True, allow out= "buildaisystem.com" , deny out= , sandbox.update network=network policy When the workflow advances, the orchestrator can replace the policy or block new outbound connections without recreating the sandbox. This separates two important lifetimes: The experiment tests this separation by changing the network policy while keeping the same execution environment and persistent worker alive. The first phase establishes a narrow network boundary: the workload can reach the trusted context source, while new connections to destinations outside the allowlist are blocked. In the experiment, buildaisystem.com represents the trusted source: network policy = NetworkConfig allow internet access=True, allow out= "buildaisystem.com" , deny out= , sandbox.update network=network policy The experiment validates both sides of the policy: The observed result matches the intended policy: destination : https://buildaisystem.comexpected : reachableactual : reachablehttp status : 200result : PASSdestination : https://www.tensorlake.aiexpected : blockedactual : blockedresult : PASS www.tensorlake.ai serves as a negative-control destination, confirming that new connections outside the active allowlist are blocked. The workflow then records the verified context locally: /tmp/trusted context.txttrusted-context-verified and advances the worker state to: phase-1-context-ready This gives us the first property we need from the phase-based model: the workload can acquire trusted context under a narrowly scoped network policy, block unrelated outbound access, and preserve the resulting state locally for the next phase. With the trusted context stored locally, the workflow moves to the approved tool phase. Instead of adding another destination to the existing allowlist, the orchestrator replaces the network policy with one scoped to the service required for this phase. In the experiment, www.tensorlake.ai represents the approved tool or platform destination: network policy = NetworkConfig allow internet access=True, allow out= "www.tensorlake.ai" , deny out= , sandbox.update network=network policy The experiment validates the updated boundary: The observed result confirms the transition: destination : https://www.tensorlake.aiexpected : reachableactual : reachablehttp status : 200result : PASSdestination : https://buildaisystem.comexpected : blockedactual : blockedresult : PASS This shows that new connections follow the updated policy rather than accumulating access from earlier phases . The workflow then records: /tmp/tool result.txtapproved-tool-access-complete The worker state advances to: phase-2-tool-complete The trusted context from Phase 1 remains available locally alongside the new tool result. Phase 2 therefore demonstrates that network privileges for new connections can change without losing execution state accumulated earlier. By Phase 3, the workflow has collected the trusted context and completed the approved external interaction. Everything required for the next step is available inside the sandbox, so new outbound connectivity is no longer necessary. The network policy is reduced to its strictest form: network policy = NetworkConfig allow internet access=False, sandbox.update network=network policy The updated policy blocks new outbound connections . Connections that were already established before the policy update are not interrupted by the transition. The experiment verifies this by attempting new connections to both previously used destinations: destination : https://buildaisystem.comexpected : blockedactual : blockedresult : PASSdestination : https://www.tensorlake.aiexpected : blockedactual : blockedresult : PASS More importantly, local execution continues. The same worker remains active, its heartbeat advances, and state from earlier phases remains available: /tmp/trusted context.txt/tmp/tool result.txt/tmp/worker state.txt Using only that local state, the sandbox performs the final computation and writes: /tmp/final result.txtsecure-agent-execution-complete The execution succeeds while new outbound connections are blocked: Network-Isolated Local Computation----------------------------------exit code : 0stdout : secure-agent-execution-completeresult : PASS Phase 3 demonstrates the key property of the pattern: the network boundary can tighten while the persistent worker, filesystem state, and local computation continue uninterrupted. After the isolated computation completes, the workflow transitions back to a network-enabled state without rebuilding the sandbox or restarting the worker. In the experiment, the runtime restriction is cleared with: sandbox.update network=CLEAR NETWORK POLICY The experiment then verifies that new connections to both previously used destinations succeed: destination : https://buildaisystem.comexpected : reachableactual : reachablehttp status : 200result : PASSdestination : https://www.tensorlake.aiexpected : reachableactual : reachablehttp status : 200result : PASS The worker remains active and the state accumulated across earlier phases is preserved: /tmp/trusted context.txt/tmp/tool result.txt/tmp/final result.txt/tmp/worker state.txt The final result remains: secure-agent-execution-complete and the worker state advances to: phase-4-recovery-complete This completes the full privilege lifecycle: Trusted Context Access ↓Approved Tool Access ↓Network-Isolated Execution ↓Controlled Recovery For this experiment, CLEAR NETWORK POLICY demonstrates that new outbound connectivity can be restored while preserving the running workload and its state. In a production banking system, the next phase would typically apply another explicitly restricted policy rather than return the workload to unrestricted outbound access. The final integration test brought all four phases together in the same Tensorlake Sandbox and persistent worker. The sandbox was not recreated, the worker retained its process identity and heartbeat, and state from earlier phases remained available throughout the workflow. The final validation produced: worker continuity : PASSphase-based access control : PASStrusted context access : PASStool access transition : PASSnetwork isolation : PASSstate persistence : PASSlocal isolated execution : PASSnetwork recovery : PASSfinal result : secure-agent-execution-complete Together, the experiment demonstrated that: Throughout these transitions, the worker and filesystem state persisted. The key result is that the privilege lifecycle can change independently from the execution lifecycle . A long-running workload can preserve the state it needs while the orchestrator changes the network privileges available to new connections at each phase. The experiments point to an important architectural principle: the workload should not be responsible for granting itself additional network privileges. That responsibility belongs to the orchestrator. Before each action, the orchestrator identifies the execution phase, applies the corresponding network policy, and then allows the workload to proceed: Determine Execution Phase ↓Apply Required Network Policy ↓Execute Workload Action ↓Validate Result ↓Replace or Remove Privilege ↓Continue to Next Phase This separates responsibilities clearly. The agent or worker performs the task, the orchestrator authorizes the phase and its privileges, and the sandbox enforces the resulting network boundary for new connections. In a production banking workflow, these mappings can be explicitly defined by the application: phase policies = { "trusted context": trusted context policy, "approved tool": approved tool policy, "local processing": isolated policy,} The agent may propose that a tool is needed, but the surrounding application validates the transition and applies only the network policy associated with the approved phase. The production principle is simple: the agent proposes the action, the orchestrator authorizes the phase, and the infrastructure enforces the network authority available to it. The experiment uses public websites for reproducibility, but the same security pattern becomes more meaningful in a production workflow. Consider an AI agent supporting lending or risk operations. It may retrieve approved policy information, invoke a risk or fraud service, process the results locally, and prepare an output for downstream review. Instead of exposing every required system throughout the workflow, network privileges can follow the execution phase: Customer / Application Request │ ▼ AI Orchestrator │ ▼ Secure Execution Sandbox │ Persistent Worker │ ┌─────────┴─────────┐ │ │Local State Working Files │ │ └─────────┬─────────┘ │ ▼Phase 1: Trusted ContextOnly approved policy / knowledge source reachable │ ▼Phase 2: Approved ToolOnly required risk / fraud service reachable │ ▼Phase 3: Local ProcessingNo outbound network access │ ▼Phase 4: Next Approved ActionTransition to another explicitly scoped network policy The key architectural property is that execution state can persist while network privileges change . Once policy information or a tool result has been retrieved, it can remain inside the sandbox for subsequent processing without requiring new connections to the original source. This is particularly useful for model-generated actions or code execution. Application-level instructions can guide agent behavior, while the network policy provides an independent infrastructure boundary around new outbound connections. For regulated environments such as banking, this creates a clear separation between reasoning and authority: The model proposes an action. The application approves the phase. The infrastructure determines the network access available to that phase. The public-host experiment is intentionally simpler than a production banking architecture, but it validates the underlying pattern: a stateful workload can continue running while its network privileges change across execution phases. Phase-based network access should complement, not replace, the broader security controls around an AI workload. An approved destination being reachable does not mean every operation should be permitted. Authentication, authorization, tool-level permissions, argument validation, and application policies still determine what the workload can do after establishing a connection. Secrets should follow the same least-privilege model. Temporary network access should not imply persistent access to API keys, tokens, or credentials. Ideally, both network and credential privileges are scoped to the phase and capability that require them. Network isolation also does not make generated code inherently safe. Even without new outbound connections, code can consume resources, modify files, corrupt local state, or behave unexpectedly. Resource limits, filesystem boundaries, execution timeouts, process controls, and sandbox isolation remain essential. The orchestrator should also handle failures deterministically. If a phase fails after temporary access is granted, the system should know which policy remains active and how that privilege will be replaced or removed. Finally, policy transitions should be observable. Production traces should record the active phase, permitted destinations, actions performed, results, and subsequent policy transitions. The broader security model therefore combines: Agent authorization + tool permissions + secrets management + sandbox isolation + resource controls + phase-based network access + observability Dynamic network policies strengthen the network layer of this architecture by allowing privileges for new outbound connections to change as the workload moves through its execution lifecycle. For implementation details, policy configuration, and current networking behavior, refer to the T ensorlake Sandboxes networking documentation . The results should be interpreted within the boundaries of what was tested. The experiment demonstrates that a running Tensorlake Sandbox can transition between outbound network policies while preserving its worker, filesystem state, and execution context. It validates destination-specific behavior for new connections, runtime policy changes, local execution while new outbound connections are blocked, and subsequent recovery. This is not a complete production security implementation. The public destinations are intentionally simple: buildaisystem.com represents a trusted context source, while www.tensorlake.ai represents an approved external destination. In production, these could be internal policy services, risk systems, fraud APIs, or other controlled enterprise resources. The experiment validates network reachability, not application-level authorization . A reachable hostname does not determine which APIs, records, or operations the workload can access. Those controls must be enforced independently. Similarly, blocking new outbound connections does not make arbitrary code safe. A workload can still consume resources, modify accessible files, or corrupt local state within the permissions available inside the sandbox. The experiment also does not cover production edge cases such as concurrent actions, complex DNS behavior, failures during policy transitions, retries, dependency-specific networking, or partially completed phases. The conclusion is therefore deliberately scoped: The experiment demonstrates that network privileges for new outbound connections can change with the execution phase of a running AI workload while preserving its worker and execution state. Production adoption still requires the broader security controls discussed above. Long-running AI agents may need to preserve context, intermediate results, files, and worker state across multiple actions. What does not need to remain constant is the network authority available to the workload . In this experiment, the same Tensorlake Sandbox and persistent worker moved through four security phases: Trusted Context Access ↓Approved Tool Access ↓Network-Isolated Execution ↓Controlled Recovery Across these transitions, network privileges for new outbound connections changed while the worker remained alive and its filesystem and execution state persisted. This creates an important architectural separation: Execution LifetimeSandbox ───────────────────────────────────────────────►Worker ───────────────────────────────────────────────►State ───────────────────────────────────────────────►Privilege Lifetime Context Access ├──────────┤ Tool Access ├──────────┤ No Network ├──────────┤ Recovery ├────────► The execution lifetime can be long while the privilege lifetime remains short. An agent may require several external systems during a complete task, but it does not need new connections to every system throughout that task. This leads to the central principle: The lifetime of a privilege should match the lifetime of the requirement that justified it. The pattern also separates reasoning from authority. The agent can propose an action, the orchestrator can authorize the phase, and the infrastructure can enforce the network policy under which that action executes. Prompt instructions alone should not define the workload’s security boundary. Dynamic network policies are only one part of production AI security. Authentication, authorization, secrets management, tool permissions, resource controls, sandbox isolation, observability, and deterministic failure handling remain essential. For regulated environments such as banking, however, phase-based network control provides a practical way to preserve stateful execution while limiting new outbound connections to what the current phase requires. The broader lesson is straightforward: Keep the workload alive. Preserve the state it needs. Grant only the network privilege required for the current phase, and change that privilege as the workflow advances. To explore the platform and this capability further, visit Tensorlake https://www.tensorlake.ai/?utm source=medium&utm medium=sponsored content&utm campaign=raj aug2026 and the Thank you for taking the time to read this article. If you found this walkthrough helpful, I’d love to hear your thoughts . Feel free to leave a comment with your feedback, questions, or experiences using Tensorlake Sandboxes, dynamic network policies, or secure AI agent execution patterns . I’m always happy to discuss ideas and learn from the community. If you enjoyed the article, please consider giving it a clap and sharing it with your colleagues or network. Your support helps more developers, AI engineers, and architects discover practical, production-focused approaches to building secure AI systems with Tensorlake Sandboxes . If you’d like to continue exploring practical, production-focused AI engineering with me, follow me on Medium. I regularly write hands-on articles on AI Engineering, Agentic AI, RAG, LLMOps, AI System Design, and emerging AI infrastructure , with a focus on turning concepts into architectures and working implementations. Secure AI Agents with Tensorlake Dynamic Network Policies https://pub.towardsai.net/secure-ai-agents-with-tensorlake-dynamic-network-policies-3149b7a11e16 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.