Skip to main content

Internet egress

Agents run code that other people wrote or that a model generated: MCP servers, and Python functions. That code runs in sandboxes inside FYAI. Internet egress decides whether those sandboxes can open connections to the general internet.

Out of the box nothing changes: every organisation and project is Open, which is how FYAI has always behaved. Restricting is an explicit choice, made per organisation or per project.

The two settings​

SettingWhat agent code can reach
Open (default)The public internet, as before. FYAI's own network, other tenants and cloud metadata are always out of reach, in either setting.
RestrictedName resolution (DNS) and the IP ranges you allow. Nothing else.

Restricted is for organisations that want to be sure a tool cannot send data to a place nobody approved, for example because an MCP server holds a customer's credentials.

Allowing IP ranges​

A restricted scope can carry an allow-list of IP ranges, written in CIDR form (for example 8.8.8.0/24, or a single address). Everything on the list is reachable on any port and protocol, and nothing else is.

  • Ranges, not hostnames. The network layer matches addresses; it cannot match api.example.com. To allow a service you have to know the addresses it uses, and those can change without notice, especially for services behind a CDN. Check the allow-list when a restricted tool starts failing to connect.
  • Only public IPv4 ranges are accepted. Private, loopback, link-local, carrier-grade NAT, documentation and reserved ranges are refused with the reason, and so is anything wider than /8 or a list longer than 64 entries.
  • FYAI's own network (including the Kubernetes API and the cloud metadata endpoints) stays blocked even if a range you enter would cover it.
  • Name resolution stays on so that tools can find the addresses you allowed. DNS can in principle carry a trickle of data out in the names it looks up; the Restricted setting does not close that, and a function set to None (below) does.

Where to set it​

LevelWhereWho can change it
OrganisationSettings → Organization → Risk Appetite, section Internet EgressOrganisation Owners and Admins
ProjectSettings → Project → Risk Appetite, section Internet EgressProject Admins, Owners and Admins

At project level you can choose Inherit organisation setting, Open or Restricted. A project's own choice wins over the organisation's, with one safeguard: a Project Admin cannot widen a restricted organisation. They can keep it, or tighten it (restricted with the same ranges or fewer), but opening it or adding ranges needs an organisation Owner or Admin. A Project Admin can always restrict a project in an open organisation.

Every change records who made it and when. Organisation Owners and Admins can read the history of the organisation and all its projects through the API (below).

How it combines with a function's own setting​

A function can also say it needs no network at all (its egress setting, currently changed through the functions API). Egress is decided from both, and the stricter one wins.

Organisation / projectFunctionResult
Opennot set, or InternetOpen
OpenNoneNone: no network, not even DNS
Restrictednot set, or InternetRestricted. A function cannot widen a restricted scope
RestrictedNoneNone

What it applies to​

The setting applies to code that FYAI runs for your agents in a sandbox:

Runs asRestricted means
MCP server (command-based, or a remote endpoint reached through FYAI)The server's sandbox is placed with restricted egress for that session. It reaches DNS and your allow-list.
Local Python functionRuns only in a dedicated restricted worker pool. If your deployment has not set one up, the function is withheld from the agent's tools and a call is refused, rather than run with internet access.
Data sources and workflows that call either of the aboveThe same as the function they call.

It does not apply to:

  • FYAI's own services. The platform calls model providers, content screening, storage and email on your behalf, and those calls are not agent code. Your model connections are unaffected.
  • Built-in tools and agent-to-agent calls. They are platform code.
  • Tools that run on your own machine (the local execution agent). They use your network, not FYAI's.
  • Execution environments you deploy as a separate agent service. They are a full agent runtime that needs its own model access.

When a change takes effect​

The setting is read when a sandbox is placed. A change reaches every part of FYAI within about 30 seconds, and applies from the next time a session starts a sandbox or opens an MCP server. A server that is already running keeps the network it started with until its session ends. If you restrict a project to stop something happening right now, end the active sessions too.

Each restricted sandbox is separate from the session's ordinary one, so a session that mixes restricted and open servers uses more than one sandbox. They count against the same capacity limit.

What you will see when something is refused​

FYAI prefers refusing to running a tool with more network access than you asked for. A restricted server can fail to start with one of these reasons:

  • No restricted-egress network policy is installed. The environment cannot enforce the setting yet; the server was not started.
  • The internet egress setting could not be read. A database problem; the server was not started rather than guessed to be open.
  • The runner did not confirm it was placed that way. An older runner that does not know the setting; the server was not started.
  • Would have to download its package from a registry. npx and uvx servers install from public registries at start-up, which a restricted sandbox without that registry's address range cannot do. Add the registry's range to the allow-list, or use a server already built into the sandbox image.

Known limits​

  • Restricted limits where code can connect, not what it does with data it can reach. Inside the allow-list a tool can send anything to anyone.
  • A shared worker pool serves every tenant, and network rules apply to a pod, not to a tenant. That is why local Python functions need their own restricted pool.
  • Allow-lists are IP-based and can go stale.
  • Already-running servers are not interrupted by a change.

API​

RequestPurpose
GET /platform-settings/internet-egressThe organisation's setting: mode (open or restricted), allow_cidrs, updated_by, updated_at.
PUT /platform-settings/internet-egressSet it. Body: mode and, for restricted, allow_cidrs. Organisation Owners and Admins.
GET /platform-settings/internet-egress/historyRecorded changes for the organisation and its projects. Organisation Owners and Admins.
GET /project-settings/internet-egressThe caller's active project: its own mode (null when it inherits) and the effective_mode, effective_allow_cidrs and effective_source (default, tenant or project).
PUT /project-settings/internet-egressSet the project's override, or clear it by sending mode: null. Project Admins and above; widening a restricted organisation needs an organisation Owner or Admin.