Microsoft Foundry Agents: GA Autonomy, Preview Egress Controls

Microsoft is making it easier to build AI agents that don’t wait for a human to press a button.

Microsoft Foundry Routines can invoke an agent automatically on a timer, recurring schedule, or external event. Hosted agents can run custom agent code on Microsoft-managed infrastructure.

That moves enterprise AI beyond the familiar request-and-response model:

User → Prompt → AI → Response

toward something operationally very different:

Trigger → Agent → Identity → Tools → Enterprise Systems → Actions

But there is an important architectural wrinkle.

Some of Microsoft’s newer controls for governing what hosted agents can reach—and some of the tooling for analyzing their production behavior—remain in preview.

Microsoft’s documentation currently labels hosted-agent network egress controls as preview and explicitly states that preview features are provided without a service-level agreement and aren’t intended for production workloads.

Microsoft’s Insights in Foundry, which analyzes production-agent traces to identify recurring behavior, is also in preview and carries the same warning against production reliance.

That does not mean Microsoft Foundry lacks production networking controls. Foundry supports network isolation using customer-managed or Microsoft-managed virtual networks, private endpoints, Azure Firewall, and related Azure networking capabilities.

The larger architectural lesson is more useful:

The ability to execute autonomously can mature faster than the controls you may want around that autonomy.

Enterprise architects should not assume that because an agent execution feature is production-ready, every desirable containment, observability, evaluation, and governance feature surrounding it has reached the same maturity.

Microsoft Foundry Routines Change the Operating Model

Microsoft Foundry Routines provide a project-native mechanism for automatically invoking an agent.

A Routine contains a trigger and an action.

The trigger can be:

• A one-time timer
• A recurring schedule
• An external event

The action invokes a prompt agent or hosted agent.

Microsoft also keeps the Routine’s trigger, identity, connections, lifecycle state, and run history within the Foundry project.

This eliminates infrastructure teams might otherwise assemble themselves using technologies such as Azure Functions, Logic Apps, schedulers, queues, custom storage, and authentication code.

That is useful.

But architecturally, it changes something important.

The agent no longer necessarily needs a person sitting in front of an interface.

It can execute because something happened.

A timer fired.

A schedule arrived.

A GitHub issue changed.

A Teams message appeared.

The trigger becomes the initiating actor.

That means the organization needs to stop thinking only about:

What happens when somebody asks the AI a question?

and start asking:

What happens when this system starts executing without somebody asking it anything?

Scheduled AI Is a Production Workload

Imagine a simple Routine:

Every weekday at 7:00 AM, analyze yesterday’s support activity and identify tickets requiring escalation.

That sounds straightforward.

Now start asking production questions.

What identity executes the work?

What systems can that identity access?

Can the agent only read support tickets, or can it modify them?

Can it send email?

Can it contact arbitrary internet destinations?

What happens if the agent fails halfway through execution?

Will it retry?

Could retries duplicate an action?

How frequently can it execute?

How long can it run?

How much can it spend?

Where are its actions recorded?

Who owns it six months from now?

Who can stop it?

Those aren’t primarily AI questions.

They are production systems questions.

Once an agent can execute automatically, its trigger, identity, permissions, tools, network access, retry behavior, observability, cost, and failure handling become part of the architecture.

The Egress Problem

One particularly important control is network egress.

Egress determines where an agent can make outbound connections.

For a traditional application, architects routinely ask:

• Which databases can this service reach?
• Which APIs can it call?
• Can it access the public internet?
• Which external domains are approved?
• Does traffic pass through a firewall or gateway?
• Can sensitive information leave the network?

AI agents don’t make those questions obsolete.

They make them more important.

An agent capable of choosing tools, constructing requests, processing retrieved information, and adapting its behavior can potentially interact with destinations that weren’t anticipated in one deterministic code path.

For production agents, unrestricted outbound access should therefore be an explicit architectural decision—not an accidental default.

Microsoft’s Agent-Level Egress Controls Are Still Preview

Microsoft is developing hosted-agent network egress controls that provide a particularly interesting agent-specific containment mechanism.

The controls can evaluate outbound requests according to ordered rules.

Rules can:

• Allow requests
• Deny requests
• Transform requests
• Rewrite requests

Organizations can configure the default action as Deny, creating an allowlist model.

Microsoft also documents fail-closed behavior: if the policy cannot be evaluated, the request is denied.

The controls support an Audit mode for observing traffic before enforcing restrictions and an Enforce mode that actually blocks denied requests.

Architecturally, those are useful capabilities.

But Microsoft currently labels these hosted-agent egress controls preview.

Microsoft’s own documentation says preview features are provided without an SLA and aren’t intended for production or live operating environments.

There are also current limitations. The controls apply only to hosted agents, enforcement occurs within the Foundry-managed agent sandbox, and some planned capabilities—including additional rule types and data-loss-prevention-related functionality—aren’t yet available.

That distinction matters.

A control existing in the portal does not automatically make it a production control.

Preview Controls Should Not Become Production Dependencies

There is nothing inherently wrong with using preview technology for experimentation.

Preview features are how customers learn what’s coming, evaluate capabilities, provide feedback, and prepare future architectures.

The mistake is allowing a preview feature to become the only thing standing between an autonomous workload and an unacceptable outcome.

Suppose your security requirement says:

This agent must never communicate with an external destination outside an approved list.

If satisfying that requirement depends exclusively on a feature whose vendor documentation says isn’t intended for production workloads, you have an architectural problem.

Your requirement is production-grade.

Your control isn’t.

The answer isn’t necessarily to abandon the agent.

The answer is to move the critical boundary into infrastructure mature enough to enforce it.

Foundry Already Provides Production Networking Options

This is where the distinction between agent-level egress policy and network architecture becomes important.

Microsoft Foundry supports multiple networking models.

At the simplest end, a Foundry deployment can use public networking.

For stronger isolation, organizations can use a bring-your-own virtual network or a Microsoft-managed virtual network.

Microsoft documents configurations supporting:

• Private endpoints
• Virtual network isolation
• Customer-controlled routing
• Azure Firewall
• Approved outbound destinations
• Private access to Azure resources
• VPN or ExpressRoute connectivity to on-premises systems

With a customer-managed virtual network, enterprises can control IP ranges, peering, routing, and other network infrastructure.

Microsoft also supports managed virtual networks for organizations that want isolation without managing the underlying address space themselves.

This gives enterprise architects an important option:

Use mature Azure infrastructure controls to enforce production boundaries while newer agent-specific controls continue maturing.

Defense in Depth Still Applies to AI

This isn’t an AI-specific invention.

It is ordinary security architecture.

A production agent can have multiple layers of control:

Agent instructions
Define expected behavior.

Capability boundaries
Limit which tools and business functions the agent can invoke.

Workload identity
Determine which principal executes the action.

Authorization
Limit what that identity can read, write, modify, or delete.

Application gateways
Control access to enterprise capabilities and APIs.

Network controls
Restrict reachable systems and external destinations.

Human approval
Gate consequential operations.

Observability
Record what happened.

Kill switches
Provide independent intervention authority.

No single layer should be expected to carry the entire security model.

That includes the prompt.

And it includes an agent-platform guardrail.

The Same Maturity Gap Appears in Observability

Microsoft’s Foundry Insights provides another example of differing maturity levels across the agent stack.

Insights analyzes traces from production agents and organizes recurring behavior into findings that people can review and validate.

That’s exactly the direction enterprise AI operations need to move.

Traditional application monitoring asks questions such as:

• Did the service fail?
• How long did the request take?
• How much CPU did it consume?
• Which dependency returned an error?

Agentic systems add new questions:

• What behavior is repeatedly emerging?
• Which tool sequences are common?
• Are agents developing undesirable execution patterns?
• Are failures clustered around particular decisions?
• Is agent behavior drifting as models, prompts, tools, or data change?

Foundry Insights is designed to help analyze this kind of agent behavior.

But it too is currently preview.

Microsoft explicitly recommends human validation of generated Insights before taking action.

Again, that doesn’t make the feature unimportant.

It means architects shouldn’t design a production operating model that assumes this preview capability is already a complete production observability strategy.

Production Observability Cannot Wait for the Platform

If an agent is production-ready today, its observability needs to be production-ready today.

That may mean using established Azure capabilities such as Application Insights, Azure Monitor, Log Analytics, distributed tracing, application logs, security telemetry, and custom business-event logging alongside Foundry’s agent-specific capabilities.

For consequential agent execution, organizations should be able to reconstruct:

Trigger → Agent → Decision → Tool → Identity → Authorization → External Call → State Change → Result

If money moved, a customer record changed, a document was sent, infrastructure was modified, or an external system was contacted, the organization should be able to determine what happened.

The fact that richer AI-native analysis is still evolving does not remove that requirement.

Give Every Routine a Production Contract

The simplest way to operationalize this is to stop treating a Routine as merely a schedule.

Treat it as a production workload.

Every production Routine should have an explicit contract.

Owner

Who is accountable for the Routine?

Not who created the demo.

Who owns its behavior in production?

Trigger

What starts execution?

Is it time-based, event-based, or manually dispatched?

Identity

Which identity executes the Routine and agent?

Is it a dedicated workload identity?

Permissions

What can that identity read, create, modify, approve, or delete?

Capabilities

Which tools and business capabilities can the agent invoke?

Egress

Which systems and external destinations may it contact?

How is that boundary technically enforced?

Frequency

How often may it execute?

Could an unexpected event storm create hundreds or thousands of invocations?

Duration

How long may one execution continue?

Retry Behavior

What happens when an operation fails?

Could retrying cause duplicate business actions?

Idempotency

Can the same action safely execute twice?

This becomes particularly important in event-driven and retrying systems.

Cost

What is the expected cost per execution?

What happens if consumption exceeds the expected range?

Observability

What traces, tool calls, authorization decisions, external requests, state changes, failures, and costs are recorded?

Human Intervention

Which operations require approval?

Kill Switch

Who can disable the Routine, revoke the identity, block network access, or stop the underlying capability?

Those questions should be answered before autonomous execution becomes routine.

Put Safeguards Outside the Agent’s Authority

One architectural principle deserves special emphasis:

The agent should not control the safeguards designed to contain the agent.

If the agent can disable its own logging, modify its own permissions, change its own network rules, remove its own resource locks, or disable its own kill switch, those controls aren’t independent.

The same principle has existed in enterprise security for decades.

Recovery credentials shouldn’t be identical to production credentials.

Audit logs shouldn’t be alterable by the workload being audited.

Backup systems shouldn’t depend entirely on the production environment they’re protecting.

AI agents don’t invalidate those principles.

They inherit them.

GA Does Not Mean “Everything Around It Is GA”

Enterprise teams often make a subtle mistake when evaluating rapidly evolving platforms.

They look at the maturity label of the central feature and mentally apply it to the surrounding architecture.

The agent is GA.

Therefore, the agent platform is production-ready.

But production readiness isn’t a property of one feature.

It is a property of the complete system.

An enterprise agent depends on:

• Identity
• Authorization
• Networking
• Secrets
• Tools
• Data access
• Observability
• Evaluation
• Cost controls
• Recovery
• Incident response
• Human intervention

Each dependency has its own maturity level.

The correct architecture question isn’t:

Is the agent GA?

It is:

Is every control required by this workload sufficiently mature for the risk we’re accepting?

That is a much harder question.

It is also the one that matters.

Don’t Wait for Perfect Agent Platforms

There is an equally important mistake on the other side.

Enterprises shouldn’t conclude that AI agents must wait until every specialized agent control reaches general availability.

That could mean waiting indefinitely.

Instead, use established enterprise architecture to compensate.

If agent-specific egress controls aren’t sufficiently mature, enforce the boundary through Azure networking and gateways.

If AI-native behavioral analysis isn’t sufficiently mature, capture traces and operational telemetry using established observability systems.

If autonomous approval is too risky, keep a human approval boundary.

If a general-purpose tool gives an agent excessive authority, expose a narrow deterministic capability instead.

This is how enterprise architecture has always dealt with technology maturity.

Don’t ask immature components to carry production responsibilities they aren’t ready to carry.

The Enterprise Agent Control Gap

We’re entering a period where AI’s ability to execute work may advance faster than the surrounding controls become standardized, integrated, and production-hardened.

That creates an Enterprise Agent Control Gap.

On one side:

Agents can act.

On the other:

Enterprises must prove that those actions remain inside acceptable boundaries.

Closing that gap requires more than agent prompts and platform features.

It requires architecture.

For Microsoft-centric organizations, that means combining Microsoft Foundry’s agent capabilities with the mature identity, networking, application, security, observability, and governance infrastructure already available across Azure and the broader Microsoft stack.

Use new agent controls as they mature.

Evaluate preview features.

Prepare to adopt them where they improve the architecture.

But don’t make a preview feature the only thing protecting a production boundary.

The principle is simple:

Autonomy can move faster than control maturity. Architecture has to close the gap.

More Information

Microsoft AI and .NET Engineering

Enterprise AI Architecture — Agents | Pillar 6 of EAA

Frequently Asked Questions