Governance & Policies

The Govern layer. Every tool call, model output, and resource access an agent makes is checked against policy at runtime — before it takes effect. Nothing is permitted unless a policy explicitly allows it.

#Overview

Agents are useful because they take real action on real systems. They are safe to run in production because every action they take passes through a decision point first. That decision point is the governance gateway: the runtime enforcement layer that sits between an agent and everything it can touch.

During a run, every tool call, every model output, and every resource access is evaluated against the policies that apply to that agent. The gateway returns one of three outcomes — allow, deny, or escalate to a human — and that outcome is enforced before the action happens. Policy decisions are made here, not in the agent code and not in the SDK, so an agent cannot opt out of governance.

Note

The gateway is deny-by-default. If no policy explicitly permits an access, it is denied. There is no implicit allow, no fall-through, and no way for an unmatched action to slip past.

#The policy model

A policy is a rule that decides what an agent may do. Each policy has an effect, a pattern that selects which tools or resources it applies to, the connector it governs, an optional agent or role binding that narrows who it applies to, a priority that orders it against other policies, and optional conditions that gate when it is active.

effect"ALLOW" | "DENY" | "ESCALATE"Required

The outcome when this policy is the deciding match. ALLOW permits the action, DENY blocks it, and ESCALATE pauses the run for human approval.

tool_patternstringRequired

A glob over the tool or resource name, for example slack.* to match every Slack tool or * to match everything. Matching is linear-time and does not support backtracking.

connector_idstring (UUID)Required

The connector the policy governs, referenced by its UUID. Every policy is bound to a connector; only policies for the target tool’s connector are considered.

agent / rolestringOptional

Optional binding that narrows who the policy applies to: a specific agent, or a role that groups agents. A policy with neither set applies to every agent for that connector. Agent-bound and role-bound policies are how the same agent gets different permissions in different contexts.

prioritynumberRequired

Orders policies that could otherwise both match. Higher priority is evaluated first within its tier.

conditionsarrayOptional

Optional gating that narrows when the policy is active — a time window or a target-environment list. When conditions are not met, the policy does not match.

The example below is illustrative, not a schema. It shows the shape of a policy set conceptually: deny destructive filesystem writes for an entire role, escalate any Slack post for one agent, and allow read-only database access in production.

yaml

# Highest priority wins within a tier.
# DENY > ESCALATE > ALLOW at equal priority.

- effect: DENY
  tool_pattern: "fs.delete*"
  connector: filesystem
  role: data-team        # applies to every agent in the role
  priority: 100

- effect: ESCALATE
  tool_pattern: "slack.*"
  connector: slack
  agent: reporter        # this agent only
  priority: 50

- effect: ALLOW
  tool_pattern: "db.read*"
  connector: postgres
  priority: 10
  conditions:
    - type: environment
      values: ["prod"]

#Deny by default

Deny-by-default is the foundational invariant of the Govern layer. An access is permitted only if a policy explicitly allows it. If nothing matches, the gateway denies the action rather than falling back to a permissive default.

A tool call with no matching policy is denied, and the run sees a denial rather than a silent pass.
Adding a DENY policy can only ever remove access, never grant it — the system is monotonic, so new restrictions are always safe to add.
Unrecognized or malformed policy data fails closed to DENY rather than allowing the action.

The practical consequence: you build up an agent’s permissions by explicitly allowing the narrow set of tools it needs, and everything else is closed without you having to enumerate it.

#Precedence

When more than one policy could apply to an access, precedence decides which one wins. The order is deterministic — the same set of policies always produces the same decision.

Agent-specific over role-based. A policy bound to the individual agent is evaluated before any policy it inherits from a role. An agent-level rule always overrides a role-level rule, regardless of the priority numbers on either.
Priority within a tier. Inside a tier, the highest-priority policy decides.
DENY > ESCALATE > ALLOW at equal priority. If two policies tie on priority within the same tier, the more restrictive effect wins: a deny beats an escalate, and an escalate beats an allow.

Tip

Because the tie-break always favors the stricter effect, you can layer a broad escalate or allow and then carve out a narrower deny at the same priority — the deny will take precedence for the cases it matches.

#Roles & RBAC

A role groups agents so that policy can be assigned to the group rather than to each agent individually. This is role-based access control: you define a role once, attach the policies that describe what that role may do, and every agent in the role inherits them.

Roles and agent-specific policies compose. An agent gets the union of its role policies and its own policies, with agent-specific policies taking precedence where they overlap. That is what lets the same agent behave differently depending on the role it runs under. Roles are part of the shared platform vocabulary — see Core Concepts for how roles relate to agents, runs, and the rest of the model.

#Conditions

Conditions narrow when a policy is active. A policy with conditions only matches when those conditions hold; otherwise it is treated as if it did not match, and evaluation continues with the remaining policies.

Time window — allow or escalate an access only during defined hours, so a capability that is fine during business hours can be restricted outside them.
Environment — gate a policy to a specific environment, so an agent can have broader access in a staging context than in production.

Conditions are evaluated as part of matching, so they obey the same deny-by-default and precedence rules as everything else: a conditional allow that does not match leaves the access denied unless another policy permits it.

#Where policies are managed

Policies, roles, and their assignments are managed in the Governance area of the control plane. From there you can see every policy that applies to an agent, the roles it belongs to, and the effect that would be enforced for a given tool or resource — without changing agent code or redeploying.

Every decision the gateway makes is written to an immutable audit trail with the context needed to reconstruct it. Policy is the rule; audit is the durable record that the rule was applied.

#Next steps

Human-in-the-Loop — What happens on ESCALATE: pausing the run, approval routes, just-in-time authorization, timeouts, and kill switches.
Audit & Compliance — The immutable record of every governance decision, built for regulated environments.
Connectors — The tools and resources policies govern: governed access to data sources and systems over MCP.