M3. Confirmation/elicitation for gated write & destructive ops

[sajeetharan]

Why

Destructive tools are hard-blocked over MCP, so agents cannot complete legitimate write workflows (and users fall back to manual runs). Production accounts appear in telemetry, so a safe middle ground beats both "blocked" and "auto-execute."

Proposed behavior

• Use MCP elicitation/confirmation so an agent can request a destructive or write op that requires explicit user approval before execution.
• Combine with dry-run (item G1) and a server-level --mcp-allow-writes opt-in.

Acceptance criteria

• Destructive tool invoked via MCP triggers a confirmation flow.
• Denial is clean.
• Opt-out preserves current block-by-default behavior.
• Documented.

---

Filed from the Agentic & Automation Roadmap (docs/agentic-roadmap.md), item M3, Wave 2. Priority P1.

[rpelevin]

This looks like the right middle ground between blocked destructive tools and auto-executed writes.

I would make the confirmation record carry more than a yes/no decision:

• caller identity and auth context
• tool name, target account/container/resource, and canonical arguments digest
• dry-run summary or diff shown to the user
• explicit approved/denied decision plus approver identity
• execution window and one-shot approval nonce
• terminal outcome: executed, denied, expired, stale, or policy-blocked

Two failure cases are worth making first-class in tests: approval replay after arguments change, and approval granted for a dry run whose live target changed before execution. Both should fail locally before the destructive tool runs.

That keeps M3 compatible with the companion authorization work. Authorization answers who may ask; elicitation records whether this exact caller, tool, args, and target resource may execute once.

Boundary: architecture and regression-test feedback only; no claim about running this project, implementation correctness, Azure alignment, Microsoft alignment, adoption, integration, customer interest, official alignment, or Neura usage.

[mkrueger]

Implemented in #183. Design note: the original acceptance criteria mentioned a write opt-in/opt-out flag to preserve block-by-default behavior. During implementation we dropped that flag in favor of always-on confirmation for destructive commands (delete,
m,
mcon,
mdb): invoking one triggers an MCP elicitation prompt and it runs only if the user approves. It fails closed — if the client can't confirm, the command is refused and the user is told to run it manually. This removes the need for a separate flag while keeping the safety guarantee. The issue will auto-close when #183 merges.

[rpelevin]

Thanks for closing the loop and for documenting the always-on, fail-closed choice in #183.

The remaining boundary I would want to make explicit is whether confirmation is bound to the exact destructive command and target, rather than only to the command category.

Is the merged path intended to reject these cases?

• approve command A, then execute command B;
• approve a target, then change the account, database, or container before dispatch;
• replay or late-use a prior confirmation;
• return no explicit terminal result for confirmed, refused, expired, or unsupported-client outcomes.

If those invariants matter beyond this shell, who owns the acceptance boundary for the Azure/MCP approval path? I can reduce this first to a synthetic, fixture-only review with no live Azure account or customer data before anyone discusses implementation. If the intended scope ends at always-on fail-closed elicitation, that is also useful to make explicit.