Guardrails

Guardrails bound what agents may do. Each agent’s Guardrails card has one tab per control: Collaboration, Self-improvement, Guardian, Limits & budgets, LLM, Integration access, Commands, and Networking. The same controls appear in organization and workspace settings, which add Skill import and spend limits of their own.

Most controls start open, because an agent is useful to the extent it can act, and you add restrictions where a mistake would be expensive. Each restriction is an explicit setting you can inspect at the level that set it. Two safeguards are on from the start: Guardian reviews what an agent is about to send out, and new organizations block obfuscated commands.

What an agent may do

Collaboration

Whether the agent may delegate to subagents (other agents, each working in a session of its own) and collaborate with peer agents in the same tree of delegated work. Delegated work appears inline in the session as 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 subagents: 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 subagents.

In organization and workspace settings, the same tab also sets how far delegated work may spread: how deep a chain of subagents may go, how many run at once, how many direct model consultations an agent makes per turn, and how many hops a chain of agent API calls may run. Each shows its default and how high your plan lets you set it; Enterprise allows more than Pro.

Self-improvement

Whether the agent may form memories, write skills, save code to its Library, adjust its own personality, improve itself while dreaming (refining skills, Library code, and personality during idle time, beyond consolidating memory), reflect weekly on how its work was received (see Reflections), manage its assignments, manage its own integrations and skills, activate a connected integration for a single session, and contribute to shared 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.

These toggles set what an agent may change about itself. They do not pass that ability to whoever is talking to it. An agent changes its personality, tools, skills, or assignments only when the person it is working for could make that change on the agent’s page. A teammate who can talk to a shared agent but not edit it can ask in a session, and the agent will tell them it cannot.

The same goes for the workspace’s shared work. An agent working for someone edits a document, writes to a data table, moves a board task, updates knowledge, or posts in a channel only if that person could do it themselves, so a viewer cannot have something changed by asking an agent to change it. In a channel an agent can do what any workspace member could do and no more, whoever asks, because a channel is open to the whole workspace. For anything beyond that, ask the agent in a direct session. A request one agent passes to another arrives with the people who made it. A data table restricted to particular agents is the exception: any member can have one of those agents write to it. A run that no person started, such as one a webhook fires, is bounded by the agent’s own guardrails and access.

Integration access

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.

Commands

Classes of shell command the agent may not run. Shell access is allowed by default; turn a class off to block every command in it:

Class	Covers
Obfuscated commands	Encode-then-execute patterns such as `base64 -d \| sh`. Blocked by default for new organizations.
Compound commands	Chaining, pipes, redirection, or handing execution to another program.
Interpreter inline code	`python -c`, `node -e`, and similar.
Unclassified commands	Anything that matches none of the other classes.
Destructive filesystem operations	`rm`, `shred`, `mkfs`, and similar.
Privilege escalation	`sudo`, `su`, `doas`, and similar.
Network fetches	`curl`, `wget`, and similar.
Package installation	`apt`, `pip`, `npm`, `brew`, and similar.
Git push	`git push` only; clone, fetch, and pull are unaffected.

Blocking compound commands is broader than it looks — most real shell work pipes or chains — so the editor warns that it effectively disables the shell. A code-review agent that should read a repository but never publish to it is the typical case for blocking Git push alone.

Networking

A default of Allow all or Deny all, refined by allow and deny rules for exact domains or CIDR ranges. A rule for github.com covers only that name, not api.github.com; wildcards are not accepted. Where an allow and a deny both match, the deny wins.

Every destination the agent chooses — web fetches, MCP servers, the browser, and every shell command — leaves through a per-session proxy that checks it against the resolved policy. The sandbox has no route around that proxy, so the policy holds whatever the model decides. Under any policy, agents reach public destinations only over HTTPS on port 443 and HTTP on port 80, so SSH, database clients, and custom ports are closed, and private addresses are always refused. A refused request tells the agent the workspace policy blocked it, so it can tell you why the request failed.

How it runs

Guardian

Guardian reviews an agent’s outward writes for confidential information before they run. It holds shell commands that publish somewhere others can read: a git push, GitHub CLI writes such as creating, commenting on, reviewing, or merging a pull request or issue, and HTTP requests that send data (POST, PUT, or PATCH through gh api, curl, or wget). It also holds Slack posts, replies in the thread that woke the session, and email the agent sends, replies to, or forwards from Gmail directly. An email draft left for a person to approve is not held. A fast model checks each one against the platform’s disclosure rules, the same ones every agent is given in its instructions, and against the Organization guidance in effect for the agent. Closing, deleting, and other retractions are reviewed after they run, without holding the call. Every review is recorded in the audit log, flagged or not.

When Guardian objects, the call does not run. The agent receives the reason, addresses the concern or confirms it is unfounded, and re-issues the call, which Guardian does not hold again for the same concern; no destination is held more than twice in a session.

The failure it guards against is self-inflicted. An agent cleared to read internal figures can publish them to a public repository just by never asking who the audience is. The Organization guidance field is where you name your own line: which categories are shareable on which surfaces, and what is never public. Guardian is on by default. Organization owners and admins set it for the organization, and workspace admins for a workspace; between those two the nearer setting wins, so a workspace can turn review back on after the organization turns it off, or off for itself. The agent level only tightens: anyone who can edit an agent can turn review on for it or add guidance that marks more material confidential, but cannot turn off review the organization or workspace keeps on, and the agent’s guidance never overrides the Organization guidance. Switching review off leaves only the disclosure rules in the agent’s instructions.

Limits & budgets

Bounds on a single run. Session budget is what one session may spend before it pauses for your review; it is unset by default, so long-running work is not interrupted over spend unless you ask for it. The doom-loop thresholds catch a wedged session whether or not you set a budget: after a run of identical tool calls the agent is warned it may be looping, and after more the turn ends gracefully. A periodic check also looks for sessions that have stopped making progress.

Organization and workspace settings add usage limits the agent level does not have, because spend authority belongs to whoever holds the budget: a monthly spend cap past which new sessions are refused, and caps on how many agents, assignments, and workspaces the scope may hold.

LLM

The model tier — Tactical, Strategic, or Operational — and the reasoning effort, from Low to Max, that the agent’s sessions use by default. Strategic runs the strongest models throughout and is billed at the Strategic rate. Someone in a session can still pick a different model and effort from the composer for that session.

Skill import

Set at the organization or workspace level: who may accept warnings when a skill is imported from a URL — anyone who can import, admins only, or no one, in which case a warning blocks the import. Findings classified as blocked never import, whatever this says.

Three layers

Every control exists at three levels — organization settings, workspace settings, and each agent’s Guardrails card — and how the levels combine depends on what the control is.

Restrictions flow downward. For collaboration, self-improvement, integration access, commands, networking, and skill import, a child level can add restrictions but never loosen a parent’s. Inherited restrictions show where they came from (“set by org”, “blocked by workspace”) and are locked in place; a Clear overrides button resets a level to what it inherits.

Settings resolve by nearest scope. Limits and the LLM choice are values rather than restrictions, so the most specific level that sets one wins: a workspace can set a larger session budget than the organization default. Guardian resolves by nearest scope between the organization and workspace, so a workspace can turn it back on after the organization turns it off; the agent level can only turn it on, as described under Guardian.

A layered posture might look like this:

Level	Restriction	Why
Organization	Networking deny rule for `pastebin.com`	No agent, in any workspace, can publish to a paste site.
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 publishes to a paste site”), tighten per workspace where a team needs it, and tune individual agents last.

Postures that work

Research agent — allow-all 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 subagents. Small reach, high stakes.
Webhook-facing agent — no subagents, minimal integrations, and a session budget. 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.