> ## Documentation Index > Fetch the complete documentation index at: https://help.loopiq.com/llms.txt > Use this file to discover all available pages before exploring further. # Governed MCP Actions Approvals and Audit ## What This Does This article explains how LoopIQ governs MCP-powered write actions, especially actions proposed by Helix. MCP can be used for read-only context retrieval or for actions that create or update LoopIQ records. Write actions need stronger controls because they can affect release governance, remediation planning, work item creation, compliance evidence, and audit history. ## How Governed MCP Actions Work LoopIQ follows a plan, preview, approve, execute, and audit pattern. 1. Helix or the MCP client identifies a possible action. 2. LoopIQ builds a structured payload. 3. The user reviews the proposed tool, reason, payload, tenant, and target records. 4. The user approves or rejects the action. 5. Approved actions are executed with tenant and caller auth propagation. 6. LoopIQ returns created or updated record IDs. 7. Audit details are attached to the result. This helps prevent AI-generated actions from inventing unrelated records or creating work without user approval. ## What to Review Before Approval Before approving an MCP action, check: * tenant or organization * team * release * certification * application, module, repository, or service context * tool name * reason for the action * payload fields * parent and child work item titles * evidence, control, or finding references * approval ID * request ID, trace ID, workflow, and idempotency key If any of these are wrong, reject the action and ask Helix to explain which records it read. ## Remediation Work Packages For release blockers, Helix may propose `loopiq_create_remediation_work_package`. This tool is designed to create a parent story and child tasks in one approved transaction. The expected result includes: * the parent story ID * child task IDs * release or certification references * blocker or evidence references * approval ID * idempotency key * audit details Use this tool when the remediation plan should be tracked as one parent work package with multiple tasks underneath it. ## Approval States An MCP action can be: * `Pending approval` when Helix has prepared the payload but has not executed it * `Approved` when the user has accepted the payload * `Rejected` when the user declined the action * `Executed` when the backend completed the approved action * `Failed` when the backend could not execute the action Failed actions should return a structured error instead of a vague assistant response. ## Audit Trail For governed actions, LoopIQ should preserve: * user identity * tenant * request ID * trace ID * workflow * tool call chain * tool name * approval ID * idempotency key * submitted payload * execution result * created or updated record IDs * timestamp This audit trail supports operational review, compliance review, and troubleshooting. ## Idempotency Idempotency helps prevent duplicate records when a request is retried. If a network error occurs after approval, do not immediately approve the same action again. First check the action result or audit trail. The same idempotency key should return or reference the original execution where supported. ## Good Approval Examples Approve when: * the action is grounded in real release evidence * the release and certification are correct * the work items have clear titles * child tasks are tied to the correct parent story * provider findings or control failures are referenced * the owner or team is correct Reject when: * Helix uses the wrong tenant, team, release, or certification * the payload references unrelated backlog items * titles are generic or missing * parent IDs are missing for child tasks outside a work-package transaction * evidence is stale or missing * the action would create duplicate work ## Troubleshooting ### The Action Is Pending for Too Long Refresh the Helix conversation and check whether the approval card is still active. If the action was already approved, check the audit trail or created records before retrying. ### The Action Failed with Missing Fields The payload may be incomplete. Ask Helix to regenerate the action with explicit titles, parent story details, release ID, certification ID, team, and evidence references. ### The Action Created the Parent but Not Child Tasks Use the remediation work-package tool where available. It creates the parent first, captures the real parent ID, and creates child tasks in the same approved flow. ### The Action Result Does Not Match the UI Compare the audit trail record IDs with the records shown in LoopIQ. If they differ, capture the request ID and trace ID for support. ### Helix Cannot Explain What IT Read Do not approve the action. Ask Helix to list the release certification, evidence graph records, provider blockers, failed controls, evidence gaps, and work items it used. ## Related Articles * [Use LoopIQ MCP Tools](/ai-and-agents/use-loopiq-mcp-tools) * [Connect LoopIQ MCP Clients](/ai-and-agents/connect-loopiq-mcp-clients) * [MCP Tool and Action Catalog](/ai-and-agents/mcp-tool-and-action-catalog) * [Build a Custom Agent with LoopIQ MCP](/ai-and-agents/build-a-custom-agent-with-loopiq-mcp) * [Review and Approve Helix Actions](/ai-and-agents/review-and-approve-helix-actions) * [Use LoopIQ Assistant with Governed Actions](/ai-and-agents/use-loopiq-assistant-with-governed-actions)