Skip to content

Guardrails

Guardrails restrict what agents may do. Everything defaults to allowed; guardrails are the deny controls you layer on top, in four areas: collaboration, self-improvement, integrations, and networking.

The default-allow posture is deliberate — an agent is useful because it can act — and guardrails are how you make that freedom uneven on purpose. Broad autonomy where an agent has earned trust, narrow limits where a mistake would be expensive, and in every case a limit that is explicit and inspectable rather than implied. Different jobs genuinely warrant different postures: a research agent’s value comes from range, while a finance agent touching the system of record should have almost none.

Whether the agent may spawn sub-tasks (delegating work to child sessions) and collaborate with peer agents. Delegated work appears inline in the session as child cards, so it stays auditable — this guardrail decides whether it may happen at all.

A personal agent usually keeps both abilities; delegation is much of its value. A webhook-facing triage agent is a natural candidate for no sub-tasks: it handles one inbound item at a time, and whatever another system posts to it shouldn’t be able to fan out into a tree of child sessions.

Whether the agent may form memories, write skills, adjust its own personality, manage its assignments, manage or activate its own integrations, and contribute knowledge. These toggles govern how much an agent participates in its own evolution.

An agent you work with daily often deserves the full set — its memory accumulates and its personality sharpens as it learns. A shared agent whose voice the team depends on might keep memory on but personality-adjustment off, so it keeps sounding like the persona its owner wrote. And an agent whose schedule someone else owns can have assignment management switched off, so its cadence changes only when a person changes it.

Per-provider blocks. The default reads “can use integrations unless blocked below”; switch a provider off to block it entirely.

Workspace-scoped connections are available to the agents in that workspace, so per-provider blocks are how you narrow that without disconnecting anything: the workspace can keep Salesforce connected for the sales team’s agents while the general research agent has it switched off, and an agent that only ever writes reports can be blocked from everything except Slack.

A default of allow-all or deny-all, refined by allow and deny rules for specific domains or CIDR ranges.

The two defaults suit two kinds of agents. Research agents get breadth: allow-all, with deny rules carving out anything sensitive. A finance agent that summarizes internal tables gets the opposite: deny-all, with an allowlist naming the two or three domains its job actually requires — or no exceptions at all.

The same four controls exist at three levels — organization settings, workspace settings, and each agent’s Guardrails card — and restrictions flow downward: a child level can add restrictions but never loosen a parent’s. Inherited restrictions show where they came from (“set by organization”, “blocked by workspace”) and are locked in place; a Clear overrides button resets any level to what it inherits.

A layered posture might look like this:

Level Restriction Why
Organization Networking deny rule for the internal admin CIDR range No agent, in any workspace, reaches the admin network.
Finance workspace All integrations blocked except the accounting system Finance agents touch one system of record.
Quarter-close agent May not manage its own assignments Its schedule belongs to the controller running the close.

Every agent inherits the first row; agents in the finance workspace add the second; the third applies to one agent alone.

In practice: set the floor once at the organization (“no agent touches production credentials”), tighten per workspace where a team needs it, and tune individual agents last.

  • Research agent — broad networking, collaboration on, self-improvement on. Its value comes from range, and its output is reviewed anyway.
  • Finance agent — deny-all networking with a short allowlist, one permitted integration, no sub-tasks. Small reach, high stakes.
  • Webhook-facing agent — no sub-tasks and minimal integrations. It reacts to whatever another system sends, so keep what it can do with an inbound payload deliberately small.
  • New agent on probation — restrictions set at the agent’s own level while you build trust. Agent-level restrictions are yours to lift later; inherited ones are not.

For the complete site index, see llms.txt.