# Permissions and safe actions

> Scope agent credentials, review evidence, and require confirmation for destructive changes.

Canonical page: https://anectico.com/docs/agents/permissions-and-safety/


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](/docs/agents/security-model), and the
per-job scope sets are in [Scope recipes for agent jobs](/docs/agents/scope-recipes).

## Begin read-only

Use `mcp:read` for investigation. It allows the agent to retrieve Anectico evidence but does not grant a
general ability to mutate the platform.

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.

## 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](/docs/reference/mcp-tools), *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_saved_search` 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.

## 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](/docs/agents/revoke-agent-access) is the runbook, including what a
revocation stops at once, what finishes anyway, and what it cannot take back.

- [Permission scope reference](/docs/reference/permissions)
- [Connect an AI agent with MCP](/docs/agents/connect-mcp)
- [How agent access is enforced](/docs/agents/security-model)
- [Scope recipes for agent jobs](/docs/agents/scope-recipes)