<!-- Generated from agent-behaviour-policy-next.html by scripts/site/generate.mjs. Edit the page, not this file. -->

# RiskMandate — which Agent Behaviour Policy next?

The applications and business functions people have asked an Agent Behaviour Policy for, and a form to suggest or vote for the next one.

Source: https://riskmandate.ai/agent-behaviour-policy-next.html

---

# Which Agent Behaviour Policy next?

An Agent Behaviour Policy is built from a measured or documented grant, never typed. These are the applications and business functions people have asked for. Each becomes a vault once its vendor pages have been read and quoted, or once one product's grant is documented for the function. Voting is coming; for now, the form at the bottom reaches us directly.

## By target application, and what each one waits for.

The connector shapes below become policies the way the five connector examples were: the connector's own scope or permission page read and quoted on a date, a row per capability the scopes permit, the contradictions between what is advertised and what is granted published unresolved, and the open questions handed to whoever researches next.

### Claude's Google Workspace connector

Gmail, Calendar and Drive from inside Claude. The connector's scope list has not been read yet; the Google pages behind it have.

### An assistant connected to Slack

Channels are mostly other people's writing, and a bot token reaches every channel it is in.

### An assistant connected to GitHub

A fine-grained token can be scoped to a repository; an OAuth app cannot, and most connectors are OAuth apps.

### An assistant connected to Notion

An integration is added page by page, which is the one connector model with a floor. Whether the assistant's connector uses it is the question.

### An assistant connected to Salesforce

A CRM is entirely third-party material by construction.

## What the agent is for, not what it runs on.

A different axis: a policy for the CRM, the service desk or the finance data, whichever product holds it. The mandate is the same across products; the grant is per product; the policy is built once one product's grant is documented for the function.

### Access to the CRM

Customer records are third-party material by construction. Salesforce, HubSpot, Dynamics.

### The customer-service desk

Tickets, and the conversations inside them. Zendesk, Intercom, Freshdesk.

### Finance data

Spreadsheets, ledgers and the exports beside them. Sheets, Excel, NetSuite.

## Run something that is not here? Tell us.

The form opens a message in your mail client with what you typed; nothing is stored on this site. Say which application or connector, what it is connected to, and why it matters to you. If your agent already holds the credential, every vault carries `MAP-A-GRANT.md`: give it to the agent and it measures its own grant and drafts the first policy — send us what it finds and the policy gets a tile.

## The 15 we have are on the library page.

Each one read live from its vault, with its scenarios, its open questions and the files you hand the agent.
