VDF AI Networks

Policies and budgets

Set guardrails on networks — which models are allowed, which external services they can reach, and how much they can spend per run.

3 min read
On this page

Why guardrails matter

A network without guardrails is a network that could run any model, call any service, and cost any amount. For a few experimental networks, that freedom is fine. For a network your team relies on — and especially one that’s going to run on a schedule or a webhook — you want to know the floor and the ceiling.

Policies and budgets are how you set those.

Most teams set policies and budgets once per network, not once per run. The work is upfront. The benefit is permanent.

Who this is for

  • Workspace admins setting organization-wide defaults.
  • Network owners locking down workflows that will run unattended.
  • Anyone managing the cost or compliance posture of AI work in their organization.

You don’t need a finance or compliance background. The screens are designed to make trade-offs visible.

The three kinds of guardrails

Allowed models

The set of models the network may use. Anything outside the set is blocked.

Allowed external services

Which tools, integrations, and external endpoints the network may call.

Budget caps

How much a single run — or a day of runs, or a month — may cost.

Allowed models

The simplest policy. You declare a list of models the network may use. The router uses one of those models for every step. Everything else is off-limits, even if it would otherwise be a better fit.

When to set an allowed-models list:

  • Compliance. Your organization permits some models for sensitive work and not others.
  • Stability. You want runs to produce comparable results across time, even as new models are added.
  • Cost ceiling. Excluding the most expensive models is a simple way to keep a network economical.
  • Region or vendor preference. Your organization standardizes on one set of providers.

The list can be as narrow as one model or as wide as your organization’s full catalog. A useful pattern is to keep the list small but include both a fast and a high-quality option so the router still has room to pick the right one.

Allowed external services

Networks can do a lot — search the web, read connected apps, call tools. For a network that runs unattended, you may want to restrict what it can reach.

You can allow or block:

  • Web access. Whether the network can fetch external URLs at all.
  • Specific integrations. Allow Confluence and Jira; block external email send.
  • Specific tools. Allow document generation; block image generation.
  • Specific destinations. Allow sending to internal email; block sending to external addresses.

A common pattern for compliance-sensitive workflows: allow internal services only. The network can read from your internal knowledge bases and write to your internal destinations, but cannot reach the open internet.

Block-by-default is often easier than allow-by-default. Many admins find it cleaner to declare the small list of services a network *may* use, rather than the long list it may not. Pick whichever style fits how you think.

Budget caps

Budgets give you a number. The network won’t exceed it. If a run is on track to spend more than the cap allows, the network stops cleanly and tells you what happened.

You can cap:

  • Per run. A single execution can’t spend more than $X.
  • Per day. All runs of the network in a day can’t add up to more than $Y.
  • Per month. A rolling monthly cap, useful for scheduled networks.

Choose the cap that matches the network’s risk profile:

  • Manual networks rarely need a budget cap — a person is supervising.
  • Scheduled networks benefit from a daily cap — protects against a runaway run quietly burning budget.
  • Webhook-triggered networks benefit from per-run and daily caps — the trigger volume is hard to predict.

What happens when a cap is hit

The network stops at the current step and surfaces a clear notification. The work it produced up to that point is preserved as a partial run. You see exactly what completed and what didn’t, and you can decide whether to raise the cap and re-run, or live with the partial result.

The platform does not silently keep running and bill you more. The cap is the cap.

How policies and budgets interact with smart routing

Smart model routing picks a model per step. Policies and budgets are the rails it runs on.

A few examples that make the interaction concrete:

  • Auto mode + allowed-models list of three models. The router picks the best of those three for each step. The list takes priority over the router’s preference.
  • Sustainable mode + per-run budget cap. The router prefers efficient models and the run still has to stay under the cap. They reinforce each other — sustainable mode is usually well under budget anyway.
  • Regulated mode + allowed-services list of internal-only. The router stays inside policy-permitted models and the network can’t reach external services. The strongest compliance posture.

You don’t need every guardrail on every network. Layer them where the risk warrants it.

Setting guardrails at the workspace level

Some guardrails are easier to set once at the workspace level than to repeat per network. Workspace admins can set defaults like:

  • The maximum models any network may use. Network owners can pick narrower lists but not broader.
  • The external services blocked by default. Specific networks can request exceptions.
  • The default monthly budget for new scheduled networks. Owners can adjust within reason; large increases need admin approval.

Workspace-level defaults keep new networks safe by construction. Owners don’t have to remember to set policies — the defaults already protect them.

A few patterns that work

Pair every scheduled network with a daily budget cap

The cost of a runaway scheduled network is the easiest unexpected cost to incur. A daily cap removes that risk entirely. Set the cap somewhere above a normal day and below “this would surprise me.”

Pair compliance-sensitive networks with an allowed-models list

Don’t rely on routing mode alone for compliance. The list is the actual enforcement; the mode is the optimization on top.

Document why a guardrail is set

The network description is a fine place to record “this network has a $10/run cap because each run handles a single customer record and we don’t want one run to burn the whole monthly budget on a pathological input.”

Re-evaluate quarterly

Models change. Costs change. Your organization’s policies change. A quarterly review of your highest-value networks’ guardrails keeps them aligned with the world they run in.

A guardrail that's never tested isn't a guardrail. Run a deliberate over-the-cap test on a new budget cap once. Confirm the network actually stops where it should. Confirm the alert lands with the right person. Five minutes of testing protects months of running.

Where to go next