Unsupervised Agent: Where Will It Send a Request at 3 AM

Egress traffic control for hosted agents is still in preview.

It answers the question facing any unsupervised agent: where this process is allowed to send a request.

My thesis: the answer to this question must remain outside the agent's code.

Without this, the security team will not approve an autonomous agent for production—and it will be right not to.

### Routines: running without a human The first generation of agents worked like chat: a person wrote, and the agent responded. Routines launch an agent based on triggers.

The agent handles a new issue in GitHub, responds to a message in a Teams channel, prepares a report every morning, or periodically checks a long-running process until it finishes. Microsoft itself lists what teams previously had to build around an agent by hand: schedulers, event listeners, webhooks, queues, infrastructure, authentication, run history, and monitoring.

The list is accurate: anyone who has brought an agent into regular operation knows that the agent itself accounts for only a small part of such a project. ### Egress controls: the boundary for outbound calls

The second feature defines where a hosted agent can connect over the network.

In a chatbot, a person provides oversight: they see every response and can stop the conversation. A person cannot see a Routine that starts at three in the morning. Microsoft demonstrates this with an invoice-processing agent.

For the task, it needs two APIs: find a supplier and check a payment record.

Then a document arrives with a link to an unfamiliar upload service.

Or a new helper library makes a request to a URL the developer did not know about.

The list of tools assigned to the agent does not protect against either case: the request bypasses it. In the first case, the request is sent by a model that read someone else’s instruction in a document (prompt injection); in the second, by a transitive dependency.

So the security specialist must ask where this process can physically send data. The question “which tools were given to the agent”

Most of our clients in CIS cannot use Foundry.

The pattern does not depend on Foundry and can be applied to any stack, including GigaChat, YandexGPT, and Qwen in a self-hosted environment.

We build it from five parts. 1. Observation period.

The agent runs in a test environment, and all outgoing calls are logged.

After a couple of weeks, the team has an actual map: which domains are required and which appeared accidentally. 2. An egress proxy with an explicit allowlist.

The proxy blocks calls to domains outside the list and raises an alert.

If a new library makes an external call, the team will find out on the very first day. 3. LLM & Security Gateway for model calls.

The gateway masks personal data, enforces spending limits, and logs requests and responses.

, it does not have full access to the database.

If an attacker extracts the prompt, they get one harmless function. 5. Triggers and schedules through a bus or n8n.

The bus and n8n already provide run history, retries, and monitoring.

You will not need to write a custom scheduler for a single agent.

In our experience, a security boundary adds one or two weeks to an agent launch. Executives often see this as a delay. Without the boundary, security will not let an agent that handles payments move beyond the pilot, and time to value becomes infinite. I have seen this scenario many times: the demo impresses the board, then sits in approvals for six months and quietly dies.

The budget is spent, the metric has not moved, and someone will have to answer for the pilot. The scenario “the agent processes invoices by itself every morning”

looks simple, but requires tedious engineering: call logs, a proxy, a gateway, narrowly scoped tools, and a bus. Engineers do this work, and it is what separates an agent in production from an agent in a presentation.