Policy reference

Every governance rule in Trellaris is a row in one table, resolved by one engine, and enforced at runtime — not in the UI, and not by convention. This page covers the policy model, then each of the ten policy kinds in detail: what it does, its exact configuration, how conflicts resolve, where it bites, and what happens when it isn't configured.

Anatomy of a policy

A policy is four fields. The kind selects the rule family, the scope says who it applies to, and the config carries the kind-specific settings.

A complete policy

{
  "kind": "budget",
  "scope": { "team_id": "8f2c…" },
  "config": {
    "period": "month",
    "soft_usd": 50,
    "hard_usd": 100,
    "on_hard": "block"
  },
  "enabled": true
}

Scope grammar

A scope is a small JSON object. Exactly one key narrows it; an empty object is org-wide. Each scope carries a specificity used to break ties.

How conflicts resolve

• Deny wins. A deny at any applicable scope blocks the item, however specific a competing allow is. A narrow allow can never punch a hole in a broad deny.
• Most-specific wins among allows. If both an org and a team policy define an allow list, the team's list is the operative one for that team's members.
• DLP is the deliberate exception: rules union across scopes rather than overriding, because a broader scope must not be able to strip a narrower scope's protections. A rule redefined under the same id at a more specific scope wins for that id.

When no policy of a kind exists

Defaults are deliberate: open where openness is safe, closed where it isn't.

dlp — data-loss prevention

An ordered list of rules applied to text as it crosses a boundary. Each rule matches by builtin id or a custom regular expression and takes one action.

config

{
  "rules": [
    {
      "id": "dlp.ssn_us",
      "name": "US Social Security Number",
      "matcher": { "type": "builtin", "builtin_id": "ssn_us" },
      "action": "redact",
      "applies_to": ["input", "output"],
      "replacement": "[REDACTED_SSN]"
    },
    {
      "id": "dlp.employee_id",
      "name": "Internal employee id",
      "matcher": { "type": "regex", "pattern": "EMP-[0-9]{6}" },
      "action": "flag",
      "applies_to": ["output"]
    }
  ]
}

Builtin matchers ship for the common sensitive classes:

applies_to picks the direction: input screens text before the model ever sees it; output screens generated text before it is delivered. Most rules want both.

Enforced at every boundary where text moves, not just the chat window:

• Model input and model output, on every run.
• Tool arguments and tool results, at the gateway choke point — so data read back from an external system is screened before it re-enters the model.
• Text extracted by browser_use, voice transcripts before they reach the model, and content written to a canvas document.

Resolution: rules union across every applicable scope; a rule id redefined at a more specific scope replaces the broader definition for that id.

tool_allowlist — which tools may be called

Governs the tool plane: built-in tools, connector tools, and MCP servers from the Tools Library.

config

{
  "allow": ["*"],
  "deny": ["browser_use", "mcp:unvetted-server"]
}

• Patterns are globs. * allows everything; a bare id like code_execution matches exactly.
• MCP servers are matched under the id mcp:<slug>, so one deny removes a whole server's tool surface.
• A denied MCP server is hidden — its tools never enter the run's tool registry, so the model doesn't attempt them and collect a wall of errors.

Enforced at tool-registry assembly for every run, at MCP discovery, at the gateway (for external MCP clients as well as the executor), and during a version's tool-surface review at scan time.

model_allowlist — which models may be used

config

{
  "allow": ["claude-*", "default", "cheap", "strong"],
  "deny": []
}

• Globs again: claude-* covers a whole model family.
• Matched against the model the agent declares, which may be a tier alias (default, cheap, strong) rather than a concrete id — if your agents use tiers, allow the tier names too.

Enforced at definition time: creating an agent or a new version with a disallowed model fails validation with a field-path error, so a disallowed model never reaches runtime in the first place.

approval — force a human decision

Additive on top of the platform's baseline (writes park). An approval policy can only tighten, and it always wins over autonomy.

config

{
  "when": {
    "tool_tags": ["write"],
    "connectors": ["servicenow"]
  },
  "approver": "team_admin"
}

Enforced at the executor, immediately before a tool call executes — the run parks at awaiting_approval with its loop state saved, and resumes to execute the approved call exactly once. Over the MCP gateway, where no human is present to answer, the call is refused rather than parked.

budget — cap spend

config

{
  "period": "month",
  "soft_usd": 50,
  "hard_usd": 100,
  "on_hard": "block"
}

Resolution is unusual and worth understanding: the most-specific budget wins outright, and the winning policy's scope also selects the spend basis. A team-scoped budget is measured against that team's combined spend, a user-scoped one against that user alone, an org-wide one against everything.

Enforced at three places, all of them before money is spent:

• Chat — sending a message returns 402 budget.hard_stop before a run row is even created.
• Non-interactive paths (automations, channels, inbound A2A) — the run fails with budget_exceeded rather than silently spending.
• The gateway — a tool call is refused with 402 before the upstream request is made.

autonomy — how much runs unattended

An organization-side ceiling. The effective level for a run is min(what the agent declares, the policy floor), so an agent can never grant itself more autonomy than the organization permits.

config

{ "max_level": "supervised" }

Deny-wins here means the lowest max_level across applicable policies is the floor. Autonomy only relaxes the baseline — an explicit approval policy still parks the call.

Enforced at the executor's write-parking decision, and again at promotion: proposing an agent to a shared ring whose declared autonomy exceeds the floor is rejected with policy.autonomy_floor.

browser_egress — where the browser may go

The one allowlist that is default-deny. Driving a real browser is the widest-blast-radius capability on the platform, so it reaches nothing until someone says otherwise.

config

{
  "allow": ["*.internal.example.com", "docs.example.com"],
  "deny": ["admin.example.com"]
}

• Hostname globs. Allow and deny lists union across applicable scopes.
• With no policy at all the allow list is empty, and browser_use fails closed with browser.egress_blocked.

Enforced at the browser_use tool, before navigation. It composes with the rest: navigate and extract are reads, while click, type, submit, and download are writes that route through the approval gate, and extracted text is DLP-screened before the model sees it.

wakeup — bound agent self-scheduling

An agent can schedule its own follow-up with schedule_followup. These caps stop that from becoming an unbounded queue of future work.

config

{
  "max_horizon_days": 30,
  "max_pending_per_user": 20,
  "max_pending_per_agent": 5
}

Resolution is per key: the most specific policy overrides only the keys it actually sets, so a per-agent policy can tighten one cap without restating the others.

Enforced at schedule_followup. A breach returns a structured tool error rather than failing the run — the model sees the refusal and can explain it to the user.

injection_screen — screen retrieved content

Content coming back from the outside world — tool results, fetched pages, knowledge chunks — is data, never instructions. This screen enforces that before the content re-enters the model.

config

{ "action": "warn" }

Detection looks for the classic markers — instruction overrides, "disregard the above", demands to reveal the system prompt, exfiltration phrasing, injected role changes, and comment-smuggled directives. The detector sits behind a swappable backend: a deterministic pattern matcher ships by default, and a real classifier is a configuration change rather than a code change.

Enforced at the tool boundary in the executor, covering tool results and knowledge alike. Every action taken is audit-logged.

conditional_access — constrain agent identity

An agent can hold its own workload identity, minted as a short-lived, audience-scoped token. This policy constrains when such a token may be issued at all.

config

{
  "deny": false,
  "allowed_hours": [8, 18],
  "allowed_cidrs": ["10.0.0.0/8"],
  "risk_max": "high"
}

Resolution: the most specific applicable policy wins as a whole, not merged key by key. Enforced at token minting — the single point every agent-identity token passes through — alongside the identity's own lifecycle state, so a killed or paused agent gets nothing regardless of policy.

Managing policies

Policies live under Admin → Policies, restricted to organization admins. Picking a kind prefills a valid starter config; the scope box takes the JSON from the grammar above. Policies can be enabled, disabled, or deleted, and every change is written to the audit log.

Practical advice

• Scope narrowly first. Prove a rule on one team or one agent before making it org-wide.
• Disable, don't delete while investigating — you keep the config and the history.
• Prefer allow lists to deny lists for models and tools. A deny list needs updating every time something new appears; an allow list fails safe.
• Use flag and warn as a measurement phase for DLP and injection screening before switching to enforcement.
• Remember the interaction order: explicit approval policies beat autonomy, deny beats allow, and the most specific allow wins the rest.