Private Networking for Foundry Agents: Inbound Is Only Half the Design

Start with two different network questions

A private endpoint can make an agent service reachable through a private network path. That addresses inbound access: who can connect to the service, and from where? It does not, by itself, answer what the service can reach after a request arrives. An agent that can call tools still needs an outbound path to those tools, and that path needs its own routing, access rules, and failure behavior.

This distinction matters because an agent request can cross several separate boundaries. A user or application sends a request to the agent service. The agent may then call an internal API, retrieve information from a data service, or send work to another system. Each connection has a source, a destination, a name that must resolve, and a route that must work. Treating the whole journey as one “private network” setting makes it difficult to see which link is actually protected.

For Foundry agents, the networking guidance makes the central distinction explicit: private inbound access does not by itself isolate outbound traffic, and tool compatibility needs to be checked. Microsoft’s networking options guidance is the starting point for validating the supported options for a particular deployment. The architectural lesson is broader: design entry and egress as separate paths, then test the complete tool call rather than inferring its behavior from the endpoint’s inbound configuration.

A useful analogy is an office with a controlled front entrance and a separate loading dock. A locked front door limits who can enter the building. It does not decide which suppliers employees can contact or which deliveries can leave the loading area. In an agent system, the private endpoint is part of the front entrance; outbound routing and tool access are the loading dock. Both matter, but they answer different questions.

This explainer focuses on those network paths and their interaction with tools. It does not select an agent deployment model or define the broader runtime-and-data architecture. For those decisions, see Foundry Prompt Agents vs Hosted Agents: Choosing a Deployment Model and Microsoft Foundry Agent Architecture: Separate Runtime, Tools and Data. Network reachability also does not establish which identity may use a tool; that is a separate design concern covered in Entra Identity for AI Agents: Who Is Allowed to Do What?.

The basic terms: ingress, egress, and tool connectivity

Ingress is traffic entering a service. In this context, it is the request path from an application, user-facing component, or other permitted caller to the agent service. Inbound controls determine which network paths can reach the service. A private endpoint is one way to provide a private-addressed entry path where supported and configured for the service. It is not a description of every route the service can use after accepting a request.

Egress is traffic leaving a service. For an agent, outbound traffic may be a request to a tool endpoint, an internal API, or another service needed to complete a task. Egress design asks which destinations the runtime can reach, which network route the request takes, and what happens when the destination is unavailable. The answer should be specific enough to distinguish an approved tool from an arbitrary destination.

A tool is an operation an agent can invoke to get information or initiate work outside its own response generation. The network may carry that invocation to an API or service, but the network path does not define what the tool is allowed to do. Network reachability is not authorization, and a successful connection does not show that the result is correct or that a requested business action should be carried out.

Name resolution, often called DNS resolution, translates a service name used by a caller into an address the caller can connect to. In private-network designs, an address can be private while name resolution still points a caller somewhere unexpected—or a name may fail to resolve from one network but work from another. For that reason, the test is not merely “does this name resolve?” It is “what address does this name resolve to from this specific source, and can that source reach the intended destination?”

Routing determines the path packets take between a source and a destination. Filtering determines whether traffic on that path is allowed. They are related but not interchangeable. A permissive rule cannot make an unreachable route work; a working route does not mean the intended destination should be permitted. A sound design records both the route and the reason a connection is allowed.

Tool compatibility means that a particular tool’s connection pattern can operate through the intended network design. A tool may rely on a destination name, protocol, authentication method, or response path that needs to be checked against the runtime’s available connectivity. Do not assume that every tool works simply because the agent itself is reachable privately. Confirm the actual connection requirements for each tool and deployment configuration before treating it as available.

These definitions help keep three questions separate: can the caller reach the agent; can the agent reach the tool; and should this caller or agent be permitted to use that tool? A private inbound endpoint is relevant to the first question. Outbound routes and filtering address the second. Identity and application-level controls address the third. Solving one does not automatically settle the others.

Follow one request in both directions

A user may see a single interaction, but the system can make multiple network connections. The initial request travels toward the agent. If the agent decides that a tool is needed, a separate request travels away from the runtime toward that tool. A response then returns from the tool, and the agent sends a result to its caller. Each leg can fail for a different reason.

The first route begins at the caller. The caller resolves the service name and attempts to reach the configured endpoint. If private access is intended, test from the actual caller network rather than a developer laptop with different DNS, routes, and permissions. Confirm the resolved destination, the path taken, and the observed response. A successful test from one subnet does not establish that every application environment uses the same path.

The second route begins inside the agent’s execution environment. The agent’s runtime needs a path to the tool destination. The destination might be internal to the organization or hosted elsewhere; do not assume its location from the fact that the agent endpoint is private. Record the tool’s actual hostname and connection needs, identify the network path intended for the runtime, and establish how that path is limited to approved destinations.

The return path matters too. A connection that leaves the runtime may still fail if the destination cannot return traffic along a compatible route, if a name resolves differently from the tool’s environment, or if an intermediary rejects the request. Operationally, observe the call from both sides where possible: the agent’s attempted destination and outcome, and the tool’s receipt or absence of a request. That comparison narrows the failure boundary without assuming the model is at fault.

The following diagram is a proposed pattern, not a claim about a particular Foundry configuration. It shows the two paths as separate design decisions and treats a denied or unusable tool path as a deliberate stop rather than an invisible fallback.

flowchart TD
    A["Approved caller"] --> B["Private ingress"]
    B --> C["Agent runtime"]
    C --> D{"Outbound path allowed?"}
    D -->|"Yes"| E["Approved tool endpoint"]
    D -->|"No"| F["Stop and record failure"]

    accTitle: Separate inbound and outbound paths for an agent
    accDescr: A caller reaches the agent through private ingress. The agent then checks a separate outbound path to an approved tool. If that path is not allowed, the operation stops and the failure is recorded.

The decision point is not a substitute for the network’s enforcement controls. It represents the intended outcome: an unavailable or disallowed tool call should be visible and handled, not silently redirected to an unreviewed destination. In a real design, the network rules, application behavior, and operational signals must agree about what “allowed,” “denied,” and “failed” mean.

Build the Azure design around explicit responsibilities

An Azure-specific design still needs a responsibility map. Naming a private endpoint or a firewall in an architecture sketch does not establish which team configures its settings, verifies the route, maintains the destination, or diagnoses a failed connection. Assign work by network boundary and evidence, rather than relying on a box in a diagram to imply ownership.

The matrix below is an implementation worksheet. “Platform/network team” and “agent/tool team” are proposed responsibility labels that an organization should adapt. A shared row means that one team supplies a dependency while another verifies the end-to-end outcome; it does not mean the task can be left unowned.

Design area	Platform or network responsibility	Agent or tool responsibility	Evidence to retain
Inbound caller path	Define the permitted caller networks and configure the selected private access path where supported.	Use the intended service name and test from the actual application environment.	Caller location, resolved destination, connection result, and the expected entry path.
Name resolution	Establish how relevant networks resolve the service and tool names.	Identify the names the application and tools actually use.	Resolution result from each relevant source network and the intended destination.
Agent-to-tool route	Define the egress route and destination limits for the runtime environment.	Document each tool’s destination and connection requirements.	Approved destination, route decision, and a successful or intentionally denied connection test.
Return path	Check that the selected route and filtering permit the expected response path.	Make the tool response behavior and failure handling observable.	Correlated request and response evidence, including time and outcome.
Change and incident handling	Record network changes and identify who can diagnose routing or filtering problems.	Identify a tool owner who can confirm endpoint changes and service behavior.	Change reference, affected paths, verification result, and rollback or recovery action.

This division avoids a common gap: the network team may know that a route exists, while the application team knows which hostname the tool calls, but neither has tested the connection from the runtime. Make the verification boundary explicit. For each connection, name the source, destination, expected name resolution, permitted route, and the person or team responsible for confirming the full path.

A private ingress design also needs a caller inventory. “Internal callers” is not a useful test category if one application runs in a different network environment from another. Record the intended caller environments individually, even if they initially share the same network path. That creates a way to detect when a new workload, environment, or network change falls outside the tested design.

For egress, start with tool destinations rather than a broad list of technologies. A destination register might contain a tool name, business purpose, hostname, protocol, expected request pattern, owning team, and the environment that must connect. These are proposed design fields, not a Foundry product schema. Their value is operational: they make a vague requirement such as “the agent must access the API” testable and reviewable.

Tool connectivity is an end-to-end property

A tool call is usable only when the whole connection works from the point that initiates it. A browser test from a workstation can establish that the workstation reaches an endpoint; it cannot establish that an agent runtime has the same name resolution, route, or filtering. Likewise, a network team’s route check cannot establish that the agent is calling the hostname the team intended to permit.

For every proposed tool, describe the call in plain terms before configuring access. Identify where the request starts, what destination it needs, how that name resolves from the source, what response the caller expects, and what the agent should do if it does not arrive. If the tool uses more than one destination or has an additional callback path, capture those separately rather than hiding them behind one service label.

Then check compatibility against the deployment’s actual networking options. The right question is not “does Foundry support networking?” It is whether this deployment and this tool can use the specific path the design requires. Validate current product support and configuration for the actual environment. Do not infer that a feature, route, or endpoint is available because a similar architecture works for another service or deployment model.

A practical test should distinguish at least four outcomes. First, name resolution fails: investigate the source network’s name-resolution path and the name the tool uses. Second, resolution succeeds but the connection cannot be established: investigate route and filtering. Third, the connection reaches the destination but the tool reports an error: investigate the destination’s behavior and request requirements. Fourth, the tool returns successfully but the agent’s task still fails: investigate application interpretation and business logic. These are different failure classes, not variations of one generic “network issue.”

Test denied access as deliberately as permitted access. If a tool destination is not on the approved list, verify that the intended design does not treat that destination as an acceptable substitute. This does not require inventing a platform-level enforcement feature: it is a design and validation requirement for the controls the organization actually uses. Record how the denial appears to the application and operator so that a blocked call is not mistaken for a model response or a successful business result.

Worked example: a hypothetical internal support agent

Consider a hypothetical organization building an internal support agent. The agent receives requests from a staff application, can look up an approved knowledge service, and can submit a maintenance request to an internal work-management API. These are illustrative services and requirements, not claims about a particular product integration. The organization wants the caller-to-agent path to be private and does not want the agent’s access to the two tools to be inferred from that inbound choice.

The team begins by writing down three separate connections: staff application to agent, agent to knowledge service, and agent to work-management API. For each connection, it records the source, destination, hostname, expected network path, team responsible for the destination, and how to tell success from failure. The knowledge lookup is read-only in this hypothetical design. The maintenance request can create a real operational record, so its approval and execution behavior must be designed separately from whether its endpoint is reachable.

The private caller path is tested from the staff application’s actual environment. The test checks the name it uses, the resolved destination, and whether the request reaches the intended service through the planned entry path. A developer’s workstation is not substituted for that test. If the workstation succeeds while the application fails, the discrepancy points toward different source-side resolution or routing rather than proving that the agent service is generally available.

For outbound access, the team checks each tool from the agent’s actual execution context. It does not assume that the tools share a route because they belong to the same organization. It records separate outcomes for the knowledge service and work-management API, since one may be reachable while the other is blocked or misconfigured. The permitted destinations are tied to named purposes; a change to a hostname or destination triggers review and a retest rather than being treated as a harmless detail.

Now consider an illustrative failure. After a network change, staff can still reach the agent, but the knowledge lookup begins to fail. The inbound check remains green, so it does not clear the outbound path. Operators compare the failed tool attempt with name-resolution results and destination-side evidence. If the agent’s source resolves the name differently than expected, they investigate that boundary. If the name is correct but the connection is not established, they examine route and filtering. If the destination receives the call and rejects it, the incident moves to the tool’s request behavior. Each observation narrows the next check.

A second failure is more consequential. The maintenance endpoint is reachable, but the application times out before it receives a response. The team must not infer from the timeout that no work request was created. The endpoint could have accepted the request while the response was lost. The recovery design should check business state before retrying an operation that might create a duplicate. This example is not a claim that any network or agent platform can guarantee exactly-once effects; it illustrates why transport success, application acknowledgement, and verified business outcome are distinct facts.

The team’s acceptance criteria therefore include a permitted inbound test, a permitted test for each tool, an intentionally denied destination test, and a failure test for a tool that cannot be reached. For the write-capable operation, the team also specifies how a human or downstream process confirms the resulting work item before the user is told that the request is complete. The criteria test the architecture’s behavior, not just the presence of network configuration.

Tradeoffs: where to constrain the path

A tightly limited destination set can reduce ambiguity and make review easier, but it requires an accurate inventory and a controlled way to handle endpoint changes. If a tool changes its hostname, a narrow rule can interrupt work until the change is reviewed and tested. That friction is useful only when the organization has an owner and a change process capable of responding without encouraging broad, permanent exceptions.

A broad outbound path can be easier to start with, but it weakens the value of describing tools as a known set of destinations. It can also make troubleshooting less decisive: a successful general connection test may say little about whether the actual tool path is appropriate. If a broad route is temporarily required for discovery, define its purpose, scope, owner, review date, and replacement criteria. Do not present a temporary diagnostic allowance as the finished architecture.

Centralized network control can provide a consistent place to reason about permitted paths, but centralization does not remove the need for application-level knowledge. A central team may not know which destination a tool calls or whether a changed endpoint is legitimate. Conversely, leaving every decision to an individual agent team can produce inconsistent records and duplicated diagnosis. Assign shared responsibilities explicitly: the tool owner identifies connection requirements; the platform or network owner implements and observes the path; the application owner confirms the end-to-end behavior.

Private inbound access may be an important requirement for the caller path, but it should not be used as shorthand for “the agent is isolated.” The more accurate statement is narrower: a particular entry path has been configured and verified. Separately describe the runtime’s permitted outbound destinations and the controls that govern them. This language makes reviews more useful because it states what has actually been demonstrated instead of implying protection across unrelated paths.

There is also a practical tradeoff between optimizing for rapid tool onboarding and requiring explicit connectivity review. A lightweight record for each new tool can keep the process proportionate: source environment, destination, name-resolution expectation, route owner, success signal, denied-path behavior, and change contact. An elaborate approval process is not inherently safer if it produces stale records or encourages exceptions without follow-up. The objective is a verifiable path with an accountable owner.

Operational failures: detect the boundary, not just the symptom

A user-facing message such as “the agent could not complete the request” collapses several possible failures. Operations should preserve enough context to locate the boundary without logging sensitive request content unnecessarily. Useful signals can include the tool identifier, time of attempt, destination category, connection outcome, and a correlation reference that lets the relevant teams compare observations. Select logging details according to organizational requirements; do not assume that a network trace or application log is safe to retain without review.

When inbound access fails, begin at the caller’s environment. Check the name and resolved destination from that source, then determine whether its route reaches the intended entry path. Compare a failing caller with a known-good caller only if the environments and tests are recorded. The comparison should identify a concrete difference—such as name resolution or route—not merely repeat that one works and another does not.

When outbound access fails, start with the specific tool call and destination. Establish whether the request was attempted, what name the source resolved, and whether the destination observed a connection. A missing destination-side event is different from an explicit destination rejection. The first directs attention toward resolution, route, or filtering; the second suggests the request reached a farther boundary. Confirm the facts before changing access rules.

A change can affect one direction without affecting the other. For example, a caller may continue to reach the agent while a tool hostname changes, or the tool may remain reachable while a caller’s source environment changes. Therefore, an inbound health check cannot stand in for tool-path monitoring, and a successful tool call cannot prove the intended caller restrictions are still in effect. Maintain separate checks for the paths that matter to the service.

Recovery decisions deserve particular care when a tool changes business state. A timeout is evidence that the caller did not observe a timely response; it is not proof that the destination performed no action. Before retrying, use an appropriate business-state check or an explicitly designed deduplication method if the target system provides one. Do not claim that the agent runtime or network guarantees exactly-once execution. If the outcome cannot be verified, state that uncertainty and route the case for reconciliation rather than asserting success.

Service teams should also distinguish a network recovery from a business recovery. Restoring connectivity can make future requests work, but it does not establish whether a request during the outage was processed, partially processed, or lost. For a read operation, a retry may be acceptable under the application’s rules. For an operation that creates or changes records, the recovery plan should include a way to inspect the business outcome before repeating the action.

A reusable decision worksheet

Use this worksheet during design review and keep the answers with the deployment’s operational material. It is intended to be printable as part of this article; it is not a downloadable template. Fill in one copy for each distinct caller path and each tool path. “Private” is not a sufficient answer on its own: record the source, destination, and observable test result.

Caller-to-agent path

• Caller environment: Name the application or workload and the network environment from which it makes requests. Avoid an umbrella label such as “internal users” when those callers use different paths.
• Service name and expected destination: Record the exact name used by the caller and the intended resolution result. Verify it from the caller environment that will run in production.
• Entry path: Describe the intended private access path and confirm that the selected deployment configuration supports it. Record what a successful connection test demonstrates—and what it does not demonstrate about outbound access.
• Denied or unavailable behavior: State what the caller sees if the entry path is unavailable or not permitted, and who receives enough operational information to investigate it.

Agent-to-tool path

• Tool and purpose: Name the operation and why the agent needs it. Separate read operations from operations that may change business state.
• Source and destination: Identify the agent execution context, hostname, expected resolution, and destination owner. Capture additional destinations as separate paths when the tool requires them.
• Route and constraint: Record the intended outbound route and how access is limited to the destinations the design has approved. Identify who changes and reviews that constraint.
• Compatibility check: Verify that the specific tool connection pattern works with the actual deployment’s networking options. Record the configuration and the test environment rather than relying on an assumption based on another deployment.
• Success and denial signals: Define how operators distinguish an established connection, a route or resolution failure, and a response rejected by the tool. Include the source and destination observations needed to locate the boundary.
• Business-state recovery: For any operation that can change records, explain how to determine whether the change occurred after a timeout before attempting a retry.

Operational readiness

• Named owners: Assign an owner for the caller path, the outbound path, and each tool destination. Where responsibilities are shared, identify who performs the end-to-end verification.
• Change trigger: State which changes require retesting: for example, a changed caller environment, destination name, route, or tool connection pattern. Use the organization’s actual change process.
• Evidence location: Record where the team keeps test results, relevant change references, and support contacts. Avoid relying on undocumented knowledge held by one engineer.
• Failure exercise: Demonstrate at least one failed or denied tool path in a controlled test and confirm that the application does not misreport an incomplete operation as a verified business result.

The worksheet should be short enough to complete for each path but precise enough that another engineer can reproduce the checks. If a row has no answer, identify whether that is an intentional design decision or an unclosed dependency. If teams disagree about what a test proves, rewrite the acceptance criterion until its source, destination, and expected observation are unambiguous.

Put the design into implementation practice

Before implementation, confirm the chosen agent deployment and its applicable networking options. The relevant choice can affect which connectivity patterns are available, so avoid designing against assumptions borrowed from a different model. The comparison in Microsoft Foundry, Bedrock AgentCore, or Gemini Enterprise: Choosing an Enterprise Agent Platform provides broader platform-selection context; the network plan should then be verified against the actual target configuration.

A practical sequence is to map callers and tools, agree on intended names and destinations, establish the private entry path where supported, define the outbound path independently, and test each connection from its real source environment. Next, test a deliberately unavailable or denied tool path and document how the system responds. Finally, verify any business-changing tool’s outcome handling so that a network timeout cannot be mistaken for proof of either success or failure.

Keep architecture decisions close to operational evidence. A diagram says what should happen; a recorded test says what happened from a particular source at a particular time. Neither replaces the other. When a result differs from the design, update the investigation or the design explicitly rather than treating the diagram as proof that the route works.

If multiple teams own the caller environment, agent deployment, network path, and tool destination, involve them early enough to agree on test boundaries and incident handoffs. Organizations looking to make these responsibilities repeatable across workloads can explore enterprise platform engineering. The useful next step is a focused review of one real caller path and one real tool path, using the worksheet above to expose assumptions before additional tools make them harder to trace.

The design principle is simple: verify the private path into the agent and the permitted path out of it as separate connections. Then verify that each tool can use its intended route, that failures are observable at the right boundary, and that business outcomes are not inferred from network symptoms. A private endpoint is one part of that design, not its conclusion.