Security

What this is: how to give an AI client exactly the access it needs, and see what it did. When you need it: before you connect an agent to a real organization.

1. Approve only the scopes the client needs.
2. Switch on read-only for clients that only look.
3. Run unattended agents as a service account.
4. Review what agents create before it lands.

Least privilege

The client can do only what its scopes allow, and never more than you can. An assistant that answers questions needs tasks:read alone. Destructive tools require admin — don’t grant it to an agent unless that is the job.

Read-only mode

Switch on Read-only in the app’s MCP generator and the connection offers no write tools. The server enforces it, not only the configuration text.

Service accounts for agents

An agent that runs on its own should act as a service account — a member of your organization that cannot sign in — with its own token, restricted to the projects it works in. Its changes are then attributed to it, and it keeps working when people leave. Mint its token in Developers → Tokens.

Agent tasks are reviewed

A task created through MCP or a token lands as an agent task for review instead of going straight into the work. A person accepts it (it becomes a normal task) or rejects it (it is archived). By default an agent’s task cannot land in a private project without that acceptance. Created by agents filters them everywhere.

What an agent creates waits for a person

finalised at 5.4: Where the review list lives in the app, and the setting that controls acceptance.

Revoking access

• An OAuth connection: revoke it on the Developers page; the client’s session ends.
• A token: revoke it in Developers → Tokens. It stops working at once and answers token-revoked. Rotate tokens you keep.

What is logged

• Every tool call, in your organization’s events, with the token’s name.
• The agent’s name on each change it makes, in the audit log.
• Token events — minted, rotated, revoked — in the audit log.