Permissions and safe actions

AI agents should receive the same least-privilege treatment as any other automation.

Begin read-only

Use mcp:read for investigation. It allows the agent to retrieve Teml 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.

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.

• Permission scope reference
• Connect an AI agent with MCP