Skip to main content

​
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.