Governance Policies

By default, agents can use every integration you have connected, and every tool call runs unattended. Governance policies change that: each policy is a rule that pauses a matching tool call until a person approves it.

Configure them in the product under Settings → Agent approval policies.

How rules are evaluated

A tool call needs approval if any enabled rule matches it. Rules do not override one another, and their order on the page is display only — reordering never changes whether approval is required.

Within a single rule, every condition must match. The product reads a rule back to you as a sentence:

the integration's Type is datadog, and its Operation type is write

That rule pauses Datadog writes and nothing else. To gate two unrelated things, write two rules.

Tool calls that match no rule run without approval. With no rules configured at all, nothing is gated.

Condition fields

Every condition describes the integration the tool would touch, or the kind of operation. There are no conditions on which user or which agent is running — a policy applies tenant-wide to every agent.

Field	Matches on	Example value
Type	The integration's type	datadog, github, kubernetes
Name	A specific integration instance	datadog-prod
Operation type	Whether the tool reads or writes	read, write
Label · <key>	A label on the integration	environment is prod

Operators are is and is not. Values are matched exactly and are case-sensitive — Prod does not match prod. There are no wildcards or patterns.

warning

"Operation type is write" is broader than it looks. Tool calls that the platform cannot confidently classify are treated as writes. A rule gating writes will therefore also catch unclassified operations. This is deliberate — it fails toward asking a human rather than acting unattended — but it means such a rule may pause more than you expect.

Labels

Label conditions behave differently from the other fields in two ways worth knowing.

A label condition only applies to integrations that carry that label. Given the rule "environment is not prod":

Integration	Matches?
environment = staging	Yes — has the label, value differs
environment = prod	No — value matches, so "is not" fails
No environment label at all	No — the rule skips it entirely

So a rule phrased as "anything that isn't production" will not cover unlabeled integrations. This is intentional: silently sweeping in everything unlabeled surprises people. If you want unlabeled integrations governed too, add a separate rule that matches on type or operation type instead.

Labels can hold several values. A condition is a membership test, not an equality test. For an integration labeled environment = [prod, us-east], the condition "environment is prod" matches, and "environment is not prod" does not.

Label keys may contain letters, digits, and underscores, and must not begin with a digit. A key like env-name cannot be used in a policy; env_name can.

Add labels to integrations on the Integrations page before writing rules that depend on them.

What happens when a rule matches

The tool call is paused before it runs. Nothing reaches your systems while the decision is outstanding, and the agent waits rather than failing.

An approver can:

• Approve once — this single call proceeds.
• Approve for the session — this call proceeds, and later calls to the same tool on the same integration within that agent session skip the gate. This option is only offered for straightforward commands; anything combining multiple commands, redirection, or wrapper invocations can only be approved once, so that approving one thing cannot quietly authorize another.
• Reject — the call does not run. The reason you give is returned to the agent, which typically adapts its approach rather than retrying the same call.

note

Pending approvals never expire. There is no timeout and no automatic denial — a tool call waits indefinitely until someone decides. An agent run that appears stalled may be waiting on an approval.

Managing rules

Disable a rule to pause it. It stays on the page with its configuration intact and stops gating tool calls immediately. Use this rather than deleting when you may want the rule back.

Delete is permanent. The rule is removed entirely and cannot be recovered — recreate it from scratch if you need it again. Deleting frees its name for reuse; disabling does not.

warning

Editing a disabled rule re-enables it. If you change the name, conditions, or note of a paused rule and save, it becomes active again. Re-disable it after saving if you meant to keep it paused.

Each rule also takes an optional note, shown to whoever reviews an approval. Use it to record why the rule exists.

If two admins edit the same rule at once, the second save is refused rather than silently overwriting the first. Reload the page and reapply your change.

Limits

Maximum rules per tenant	100
Conditions per rule	At least one; no upper limit
Rule names	Required, and unique across enabled and disabled rules
Condition values	Cannot be empty

Permissions

Managing policies and approving individual calls are separate permissions. A responder can clear an approval without being able to change the rules.

	Viewer	Responder	Admin
View policies	✅	✅	✅
Create, edit, delete policies	—	—	✅
View pending approvals	✅	✅	✅
Approve or reject a call	—	✅	✅

See Roles & Permissions for the full permission model.