Governance checklist

Setup makes an organization able to run agents; these practices keep it safe to. Each item below is something the product can enforce or show you — none of it is aspiration.

Policy posture

• Start everything on Approve. New servers, new tools, new agents: watch a few runs go through the approval queue before you move reads to Allow. Loosening a policy you understand beats tightening one you don’t.
• Keep destructive writes on Approve permanently. Deletes, bulk updates, and anything that sends to people outside the organization deserve a human every time, no matter how routine the agent.
• Use conditions where tools support them. The built-in web fetch tool takes an allowed-domains list — an allowed tool with a narrow condition is safer than an approved tool nobody reads carefully.
• Mind the “Include all future tools” checkbox. It is convenient for read-only servers and dangerous for servers that grow write tools — a server update can silently add capabilities to an agent’s reach.

Access hygiene

• Keep the Admin count small and the Agent Reviewer count adequate. Admins can change policy; reviewers can only see. Most oversight needs are reviewer-shaped.
• Prefer user-scoped credentials. When each member connects their own account, agents inherit exactly that member’s access and nothing more — see Data scoping.
• Rotate provider keys on personnel changes. Keys are write-only, so rotation is delete-and-re-add under Settings → Secrets; runs pick up the new key immediately.
• Rotate webhook trigger secrets on the same occasions. Rotation keeps a grace period for the previous secret, so callers can migrate without a hard cut.

Review rhythm

• Check Outcome: Denied in the audit log weekly. Denials are the policy doing its job — a spike means either an agent is misconfigured or someone is probing what agents can do.
• Watch the Agent-driven tile. The share of activity performed by agents should grow because you widened policy deliberately, not because you stopped looking.
• Read one full run end to end periodically. Pick a scheduled agent, open its latest run, and read the execution log. Drift in what an agent actually does is easiest to catch by reading, not by dashboards.
• Review Usage monthly. Token consumption by agent and model is the early-warning system for both cost and runaway plans.

Operational readiness

Before an agent goes on a schedule, confirm:

• Someone will be there to approve. Pending approvals expire after one hour and fail the run. Schedule agents to fire when their owner is working, or move well-understood tools to Allow.
• The owner’s access is durable. Scheduled runs re-check the owner’s provider and tool permissions at every dispatch — an owner who loses access stops the agent. Agents owned by people who are leaving should be rebuilt under a new owner.
• The timezone is right. Schedules run in an IANA timezone, so wall-clock times survive daylight saving. Verify the schedule shows the zone you meant, not UTC by accident.
• Overlap behavior is understood. Only one run per agent is active at a time; a slot that fires while a run is still going is skipped, and missed slots catch up to a capped number. Long-running plans on short intervals mostly produce skips.