An agent working on your integration changes a target's address to a host nobody on your team approved. The next request carries your data there. Reviewing every change the agent makes would catch it, but then you are doing the work yourself, only slower.
The outbound host allowlist takes that change out of the agent's reach. An agent can narrow where your project sends. It cannot widen it: that takes a person, signed in to the panel.
Name the hosts you are willing to send to
Every project has an outbound host allowlist. It starts empty, which means any public host. Put entries in it and the project can only send to what you named.
That covers every host we would make a request to on your behalf, not only the delivery target. The callback URL we call when a delivery finishes is an address you chose too, so it counts. A list that permitted your target but forbade the callback it triggers would say one thing and do another.
An agent can only narrow the list
Anything that manages EchoRelay over the API or MCP, a management token or a connected agent, can only narrow that list. An empty list already allows any public host, so an agent may set the first list itself. After that, what it submits has to be a strict subset of, or equal to, what is already there. Adding a host is refused. Clearing the list back to empty is refused. So is a wildcard that would cover a host you had pinned exactly: that widens the list too.
Widening is web-only. A person, signed in, in a browser.
So an agent can shrink the set of places your data can go, and cannot grow it. It has edit access stops meaning it can point my traffic anywhere, and starts meaning something you can hand out.
A list that would block a target you use is refused
If the project already points at a host your submitted list would not permit, the change is refused instead of accepted. Inactive lines count too, because switching one back on would send to that host. A draft that points outside the list is refused when you publish it.
A refusal now is cheaper than a delivery failing next Tuesday for a reason nobody connects back to a configuration change made on a Friday.
Set the list once, in the panel
Look at the hosts your targets send to today and enter exactly that set under Outbound hosts in the project settings. You do it once.
From then on, only a person can make it longer. As you retire a target, an agent can drop it from the list as part of the same piece of work. Anything that would open the list back up comes to you, and you will notice, because it will be the only kind of change that does.
The list controls where requests go, and nothing else
It is a host allowlist, not a firewall. It governs where this project's targets are allowed to point. It has no opinion about what you send or what comes back.
It does not replace credentials either. A permitted host still has to accept your request; being on the list is permission from us, not from them.
And it is per project, which is usually what you want. A project that talks to one partner should not inherit the list of one that talks to nine.
Routine changes stop waiting on a review
Your team can give an agent the routine work, retiring a target or tightening the list, without reviewing each call. The one change that could send your data somewhere new still waits for a person.
