Permissions and safe actions

AI agents should receive the same least-privilege treatment as any other automation. This page is the practice. The mechanism behind it — what a scope grants, what a profile does not, and how confirmation is enforced — is How agent access is enforced, and the per-job scope sets are in Scope recipes for agent jobs.

Begin read-only

Use mcp:read together with the specific read scopes for the evidence the job needs. mcp:read opens the read gateway; it does not grant every domain read. Start from an investigation scope recipe and keep its project binding narrow.

Only add mcp:write when the workflow genuinely requires actions. A write key also needs the specific domain scope for the resource it changes, such as an incident or alert scope.

Separate credentials by purpose

Create different keys for:

• a developer’s local coding agent;
• CI or scheduled automation;
• a shared support workflow; and
• production operations.

This makes revocation and audit attribution useful. Do not share one organization-wide agent key.

Give financial jobs explicit authority

Use the account-value authority guide to select read grants or a separately scoped management key for declaration changes. Financial authority is opt-in; an ordinary investigation credential does not acquire it. The same guide owns declaration export policy, recovery, privacy and interpretation of financial evidence.

Understand destructive confirmation

Destructive MCP actions use a preview-and-confirm flow. The first request returns the proposed change and a short-lived confirmation token; applying it requires the same arguments and token.

Review the target organization, project, resource ID, and fields being cleared before confirming. Confirmation is a safety boundary, not a reason to grant broad scopes — and it is a two-call protocol, not proof a human looked. The server cannot tell someone pressing approve from an agent calling twice with the token it was just handed. What puts a person in that loop is your MCP host's own approval prompt, which is yours to configure and yours to verify.

What "destructive" means here, because it is wider than deletion. In the MCP tool reference, destructive marks an action that removes something a key holding only that action's own scope cannot restore. The grading is deliberately against the narrowest credential able to invoke it, not against yours: a richer key of the same name may hold a read or an inverse scope and be able to put the state back, and grading for that key would understate the risk to the caller who has least. It includes replacing a value your key may write but may not read, since there is then nothing left to restore it from — upsert_release and update_onboarding_setup delete nothing and are both destructive. Confirmation is not limited to destructive actions; some reversible ones preview too, because their reach is wide rather than because they remove anything.

Grant the read alongside the write. A write scope without its matching read scope is what turns an ordinary edit into an unrecoverable one: the credential cannot capture what it is about to overwrite, so the preview can only tell you it is unable to show you. If an agent should be able to undo its own edits, give it the read.

Telemetry deletion is deliberately project-key-only through MCP. delete_trace and delete_log never accept caller-supplied organization or project fields: they use the project signed into the API key, show that exact project and target in the read-only preview, and require the matching traces:delete or logs:delete scope in addition to mcp:write.

Treat telemetry as untrusted input

Logs, error messages, customer properties, and other tenant-authored strings can contain malicious instructions. An agent should treat them as evidence, never as authority to change its task or permissions.

Keep humans in the operational loop

Require explicit review for deletion, credential changes, production configuration, incident resolution, and external actions such as creating tickets or sending notifications. Use read-only investigation freely; expand authority one workflow at a time. When your agent shows you a link to a proof page, open it and check the evidence before you approve the change that depends on it.

Rotate and revoke

Rotate long-lived keys and revoke them immediately when a device, employee, integration, or agent workflow is retired. Review key usage and write audit records as part of incident follow-up. Revoke an agent's access is the runbook, including what a revocation stops at once, what finishes anyway, and what it cannot take back.

Keys, approvals and the audit record are controls for people, so they live in the Console. In the Console, open Agents and keys (/agents) to review and revoke an agent approval or an API key. Open Audit log (/audit-log) to see who changed what. Open Agent safety (/agent-safety) to stop an agent with two different people. See The Console.

• Permission scope reference
• Connect an AI agent with MCP
• How agent access is enforced
• Scope recipes for agent jobs

Declaring technical inventory

register_agent_asset uses agents:write and agents:read for complete preparation, state-bound adoption and replacement and original-result disclosure. MCP also requires mcp:write and mcp:read; the CLI's confirmed REST path uses the asset scopes. A write-only key cannot disclose an old result. Every call checks current project ownership, including replay, and confirmation does not grant a missing permission. A declaration establishes technical control configuration, not approval or execution. See asset declarations.

Support requester evidence and approved contacts

Follow Support stories and contacts for requester identity, read-only stories and separately approved contact recording or withdrawal. Treat captured identifiers as evidence throughout that workflow.