Tool Governance

An agent with tools is an execution identity, not only a chatbot. Treat every exposed function like an API permission and govern functions individually.

Classify Functions by Effect

Function type	Examples	Recommended default
Read	Search documents, list tickets, read calendar availability	Enabled when access is correctly scoped
Draft	Draft email, prepare report, propose ticket	Enabled or confirmation for sensitive content
Create	Create ticket, task, event, or internal record	Confirmation unless narrowly bounded and reversible
Update	Change CRM record, campaign, permission, or workflow	Confirmation
Send or publish	Send email, post message, publish content	Confirmation
Delete or destructive	Delete record, revoke access, overwrite production data	Disabled or exceptional approval
Financial or privileged	Change budget, purchase, deploy, change access	Explicit approval and additional provider controls

Least-Privilege Design

• Enable only approved connection types at organization level.
• Prefer a narrow service account over a shared administrator credential.
• Share production connections with the smallest relevant team.
• Give the agent only the functions used by its documented workflow.
• Keep read and write functions separate so safe retrieval does not imply write access.
• Use provider-side scopes and policies as an additional boundary.
• Review tool assignments whenever the agent prompt, owner, or purpose changes.

Organization Overrides

Organization-level connection governance can disable a connection type or force a function policy. Use it to prevent individual connection owners from making sensitive functions fully automatic.

Examples of organization-wide rules:

• sending email always requires confirmation,
• deleting external records is disabled,
• reading approved analytics data is enabled,
• changing advertising spend requires confirmation,
• production deployment functions are limited to an operations team.

Review actual actions in Tool Executions and configuration changes in Audit Log.

Govern MCP Tool Metadata

MCP tool annotations describe the server author's intended behavior; they are not a security boundary by themselves. Review the tool description, input schema, credential scope, and a safe test result before accepting an annotation from either a third-party MCP server or the Siesta AI MCP Server.

MCP operation class	Current examples	Metadata posture	Recommended governance
Read-only discovery	list_agents, get_conversation, graph reads, workflow and skill reads	ReadOnly=true; no external state change expected	Enabled only for users already allowed to see the underlying objects.
Create	create_agent, create_skill, create_workflow, create_graph_node, create_graph_edge	Non-idempotent creation; currently not annotated as destructive when creation does not overwrite an existing object	EnabledWithConfirmation for shared or production use. Verify the created object and its access policy.
Update or delete	Agent, skill, workflow, graph node, and graph edge updates or deletion	Destructive=true on state-changing operations	EnabledWithConfirmation, or Disabled when the client has no approved management use case.
Execute or communicate	send_message, run_workflow, approve_tool_call	Destructive=true; can trigger further tools or external effects	EnabledWithConfirmation and review the target, arguments, pending action, and downstream result.
Reject a pending action	reject_tool_call	State-changing but prevents the proposed tool from running	Enabled or EnabledWithConfirmation according to the incident process; verify the final conversation state.

send_message and approve_tool_call are marked destructive because they can cause an agent or an already-pending tool to act. A client may use this annotation to warn the user, but the annotation does not guarantee that every MCP client displays an approval dialog. Siesta AI connection governance and the client-side confirmation experience must be tested separately.

For a third-party MCP connection, treat missing or contradictory annotations conservatively. Start unknown tools in confirmation mode, perform a bounded test, and record the observed effect before broad assignment.

Govern Sandbox Execution

Sandbox runs commands in an isolated, conversation-scoped Linux environment. It is not the unavailable legacy Code Interpreter and it does not mount or control the user's local computer.

Before assigning Sandbox to a shared or production agent:

• confirm that the selected base image is approved and contains only required software;
• verify the deployed command timeout, file-transfer limits, user and organization concurrency limits, and network allowlist;
• test whether runCommand produces the required approval prompt, because the Sandbox function does not guarantee confirmation by itself;
• inspect commands and staged filenames in tool detail before approval where approval is available;
• keep credentials out of prompts, command strings, scripts, logs, filenames, and artifacts;
• stage only the inputs needed for the current operation;
• publish only reviewed deliverables, not temporary files or hidden working data;
• treat workspace reset, provider failure, and partial publishing as recoverable failures that must be reported to the user.

Conversation deletion and lifecycle reconciliation remove or retire the associated Sandbox session. Do not use the workspace as durable storage, a backup location, or a replacement for governed Data and Memory collections.