Integration Action Safety

Read-only Mode

An MCP tool is read-only only when its annotation explicitly says so. A CLI operation is read-only only when trusted provider logic can classify it before execution. Missing or ambiguous evidence fails closed.

Consequential Input Shape

Full-access MCP tools receive an explicit wrapper containing provider input and action metadata. Trusted CLI effects require a stable idempotency key and plain-language summary.

Task-only Effects

Chat can execute a supported consequential operation explicitly requested by the owner. The action records its conversation, assistant message and originating human message; that request is the approval. The backend validates the enabled Chat profile, active conversation and turn, organization scope and authorization epoch at admission. Before execution it rechecks the origin, cancellation, current integration access, grants, selected tools, provider scope and schema. Accepted work may finish after the reply; cancelled or archived origins cannot start new effects. Task actions retain their existing task/run/version and configured approval checks. Natural-language intent and scope are instruction contracts; source identity and access checks are enforced by the backend.

Private MCP Attachments

When a hosted MCP tool requires private file bytes, persist immutable file metadata in the action and keep bytes in invocation-owned object storage. Verify ownership, size, content type, and SHA-256 before proposal and execution. Build the provider payload only in backend memory, fence it with the live tool-schema hash, and never persist base64 content, local paths, credentials, or upload URLs.

Delete staged files after success, rejection, known pre-dispatch failure, or human reconciliation. Retain them while approval or uncertain external outcome is pending, and backstop abandoned objects with a storage lifecycle policy.

Action Lifecycle

proposed
→ waiting approval or approved
→ fenced execution
→ succeeded / failed / unknown
→ receipt or reconciliation

Known HTTP 429 rejections and transient preparation failures retry the same action, with at most three attempts and persisted availability respecting Retry-After. The X adapter also converts its documented x-rate-limit-reset timestamp into a retry deadline when Retry-After is absent. See X rate-limit headers.

A transport failure after dispatch becomes unknown; it is never automatically replayed. Do not generate a new idempotency key to retry an uncertain effect. Execution attempts retain their original failure details after an owner resolves the action, so the final decision does not erase the reason recovery was needed.

Add a New Effect Classifier

1. Start from provider schema or dry-run output.
2. Define explicit read/effect cases.
3. Reject auth/configuration and unbounded operations.
4. Treat unrecognized future commands as consequential or unsupported.
5. Map risk and policy inputs without provider-specific shortcuts.
6. Preserve the original task version and authorization epoch.
7. Store a redacted typed receipt.
8. Test approval, rejection, execution, timeout, unknown outcome, reconciliation, and stale recovery.

Tests That Must Fail Closed

• Missing read-only annotation.
• Chat writing without an active human source, or attempting a disabled operation.
• Disabled integration.
• Ungranted profile.
• Changed task version.
• Changed authorization epoch.
• Expired execution lease.
• Reused invocation with different input.
• Unknown provider method.
• Credential material in input, logs, or receipts.