How to Control AI Agent Network Access
The following is one possible design approach for teams exploring AI-agent network controls. It is not a complete network-security implementation and should be adapted and enforced in the runtime environment.
Network access is one of the most important decisions in an AI agent design. An agent that can execute code, install dependencies, call APIs or browse the internet has more possible paths than an agent restricted to a local, read-only data set.
iSecureByDesign does not perform network threat modelling or enforce network policy. The team defines the intended access and performs the analysis; the tool applies the configured policy and controls to the model to produce requirements for the network and agent implementation.
“No internet access” is also not enough as a requirement if package installation, proxy services, DNS, mounted credentials or other internal services provide an indirect route.
Define the network policy in architecture
Model the agent, its runtime, package sources, proxy or cache, internal APIs and external services. Then make the intended paths explicit:
- which destinations are allowed
- which protocols and operations are allowed
- whether access is read-only
- which requests require approval
- what is logged
- what happens when the network policy fails
iSecureByDesign users can express these choices as component relationships, configuration options, policy controls and specification blocks. The generated requirements can guide implementation of network policy and provide criteria for evaluating the final design.
This approach is useful when designing a sandbox, but it does not replace firewall configuration, identity controls, runtime enforcement or monitoring. It helps ensure those controls are derived from an explicit model rather than assembled as disconnected settings.
See the Specification stage help and Policy authoring basics.
Related Reading
About Agentic Thoughts: This Agentic Thought was generated with AI. Agentic Thoughts are part of an ongoing process of evolving ideas about iSecureByDesign and how it may be applied to real-world problems. They are exploratory and do not necessarily represent a final product commitment, implementation, or formal advice.