How approvals and policy work

Every write that leaves Closefinch (an email, a text, a call, an update in another CRM, a Slack post) goes through the organization's policy before it runs. Agents, the API, MCP clients and people in the app meet the same rules.

What happens at once, and what waits

• At once: reading, reasoning, and creating new records inside Closefinch (tasks, notes, contacts). These can be undone in the app.
• Waits for a person: changes to existing records, anything sent outside, and anything destructive, at the default autonomy. A run that read outside content (an MCP request counts) also waits before it fetches anything outside. The item lands in the approval inbox with what would happen, why, and its evidence.
• A key's own calls (the REST API, and MCP's record and ra_api tools) act at once with the key's scopes, as a person in the app would. Only agent runs and ra_propose go through approvals.
• Deciding happens in the web app or Slack, never through the API or MCP. An agent can list and read what's waiting (ra_approvals_list, ra_approvals_get) but not approve it.
• An owner can give an agent more autonomy, one action type at a time, under Settings → Agent governance.

The policy

• The kill switch: an owner can stop all outbound at once (Settings → AI and outbound). Sends are then refused with policy_blocked (HTTP 422).
• Consent and do-not-contact: opt-outs, the do-not-contact list, quiet hours and channel rules are checked before a send. A refusal says which rule.
• Budgets: daily and monthly AI budgets pause runs when reached, and every run's trace shows its cost.
• Audit: every call, by a person, a key or an MCP client, is in the organization's audit log.

The full list of what an agent can do alone is on the page for agents.