A sound Microsoft Foundry agent architecture keeps four concerns distinct: the agent runtime, the model endpoint, the tools it can call, and the data those tools can access. Assign an owner to each boundary, then test identity and network paths across them. Treat this as a reference design, not a claim that Foundry automatically supplies tenant authorization or that every configuration exposes identical networking options.
That distinction matters because a connected agent is not necessarily an authorized one. The application should establish who is making a request; each tool or data service should enforce what that identity may do. The runtime coordinates work, but it should not become a shortcut around existing access controls.
Reference architecture: separate the call paths
The diagram shows logical boundaries, not a guaranteed product topology. Your deployment may implement or combine components differently; confirm the supported configuration before choosing network routes or tool integrations.
flowchart TD
accTitle: Microsoft Foundry agent architecture boundaries
accDescr: A user enters through an enterprise application. The application invokes a Foundry agent runtime, which calls a model endpoint, a tool gateway connected to enterprise systems, or a tenant-scoped data service.
A["User and enterprise app"] --> B["Foundry agent runtime"]
B --> C["Model endpoint"]
B --> D["Tool gateway"]
D --> E["Enterprise systems"]
B --> F["Tenant-scoped data service"]Read each arrow as a call path that needs an owner and a test. The application establishes the user or workload context that starts the interaction. The runtime coordinates the agent’s work and calls the model endpoint. When an action or lookup is needed, the design routes it through an approved tool boundary or data service. The target system—not an instruction in the prompt—must decide whether the request is permitted.
A direct runtime-to-data path in a logical diagram does not mean the runtime should hold broad database credentials. Prefer a service boundary that can apply the right tenant, user, and action checks. Likewise, a tool should expose only the operations the use case requires, rather than handing the agent unrestricted access to an enterprise system.
Identity and network responsibility matrix
Use this matrix in design review to make ownership and evidence explicit. The owners listed are recommended roles, not assumed Foundry defaults.
| Boundary | Accountable owner | Decision to make | Evidence before release |
|---|---|---|---|
| Application and caller identity | Application owner | How does the request identify the user or workload, and what context is passed to the agent workflow? | Tests show that an unauthenticated request is rejected and that caller context is handled as intended. |
| Agent runtime | AI platform owner with the application team | Which runtime configuration is approved, and what can it call? | Configuration records, assigned operational ownership, and tests of allowed and denied call paths. |
| Model endpoint | AI platform owner | Which endpoint can the runtime reach, and what access boundary applies? | A deployment-specific check confirms the intended runtime can reach the endpoint and that other paths are not assumed. |
| Tools and enterprise systems | Tool owner and system owner | Which actions are exposed, how are credentials managed, and where is authorization enforced? | Tests cover allowed actions, denied actions, and calls made with the wrong identity or context. |
| Tenant-scoped data | Data owner | Where is tenant membership checked, and which service enforces row-, record-, or document-level access? | Cross-tenant tests confirm that changing a prompt or supplied identifier cannot retrieve another tenant’s data. |
| Network paths | Azure network owner with the platform team | Which inbound and outbound routes are required, and which components support the selected network configuration? | A reviewed path diagram and connectivity tests cover both entry into the service and outbound calls. |
Microsoft’s networking guidance describes a public baseline and options for bring-your-own and managed virtual networks. It also cautions that a private inbound endpoint alone does not isolate egress. Check support for the tools and network features you plan to use against the selected configuration; do not infer it from the endpoint choice alone (Microsoft Foundry networking options).
That guidance has a practical implication: review inbound and outbound paths separately. A private way into a service is not, by itself, proof that outbound connections are restricted. Write down which components need to call which destinations, who approves those paths, and how you will test them. Confirm the required tool and networking support for the specific configuration before committing to it.
Put tenant authorization at the data boundary
For a multi-tenant application, pass tenant context through a controlled application or service boundary and enforce access where the data is served. Do not rely on an agent instruction such as “only retrieve records for this customer” as an access control. Instructions can guide behavior; they are not a substitute for authorization enforced by the system that returns the records.
A useful review test is to hold the caller constant and alter a tenant identifier in the request, a tool argument, or retrieved content. The request should not gain access to a different tenant’s data. Also test the reverse case: an appropriately authorized user should still reach the data they need. Record which layer rejects each unauthorized attempt so a failure can be fixed at its source rather than hidden by a prompt change.
This boundary-focused approach is useful whether you are still comparing enterprise agent platforms or have already selected one. For the broader platform-selection decision, see the enterprise agent platform comparison. If procurement has separately selected Claude through Foundry, keep that purchasing route distinct from the runtime, tool, and data authorization decisions; see the Claude procurement guide.
Plan capacity at every boundary
At larger scale, model throughput is only one limit. Estimate concurrent agent sessions, tool calls per task, connection pools, queue depth and data-service capacity. A burst of tasks can exhaust a downstream booking API while the model endpoint remains healthy. Apply per-tenant budgets and bounded queues, then shed or defer work explicitly when a dependency cannot keep up.
For a hypothetical capacity exercise, start with 200 active tasks and an average of three tool requests each per minute: the tool tier must absorb roughly 600 requests per minute before retries or bursts. Those are planning assumptions, not Foundry limits. Validate the actual quotas for your chosen deployment, reserve rollout headroom, and measure tail latency under a representative load. Give the operations team a way to pause new tasks while allowing already-approved actions to reconcile.
Turn the architecture into a release gate
Before implementation, ask each owner to supply three items: the boundary they own, the calls it must accept or reject, and the test evidence that will prove the behavior. Then walk a real user journey end to end—from application entry, through runtime and model calls, to a tool action or data response. Include at least one unauthorized action and one cross-tenant access attempt in the test plan.
Keep the resulting call-path diagram and responsibility matrix with the deployment configuration. Revisit them when a tool, data source, endpoint, or network route changes; a change in one component can create a new path across a boundary another team owns. If your teams need help establishing those ownership and review practices, explore platform engineering support. The architecture is successful when the people operating it can explain not only what the agent can reach, but who approved each path and where access is enforced.