Skip to content
anecticoDocs
Dashboard
Browse documentation
Guide

Permissions and safe actions

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

Read as Markdown ↗Use with an LLM ↗
On this page

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 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, 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 is the runbook, including what a revocation stops at once, what finishes anyway, and what it cannot take back.