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 cannot execute consequential integration operations. Task runs can propose them because the task, run, authorization epoch, version, and blockers provide the durable execution context.

Action Lifecycle

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

The provider call is attempted at most once. A transport failure after dispatch becomes unknown. Do not generate a new idempotency key and retry.

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 attempting a write.
• 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.