Regulatory Operations and Vanta
Why we tackled this. Most compliance signals live in a different tool than the one where releases get decided. So they show up late, or not at all. LoopIQ supports your GRC platform. It does not replace it.
What we built. A Vanta integration and a Regulatory Operations surface. A regulatory findings workflow for remediation, linkage, and risk acceptance. Vanta and regulatory signals now connect into release certification checks, so posture can inform whether a release is ready. Plus Vanta UI navigation, branding, and an operations panel.
Jira migration tooling
Why we tackled this. Migration friction is the quiet reason teams stay on a tracker they have outgrown. If moving your work is painful, you do not move. So we made it less painful.
What we built. A Jira connector and a dedicated import page under Import and Export. Import now goes beyond Service Requests to cover user stories, tasks, and issues. We hardened migration readiness with templates, normalization, and error handling, and made routes and trailing-slash behavior consistent across the backend, KrakenD, and the import services so imports hold up.
AI agents and Bring Your Own Agent
Why we tackled this. Agents are starting to do real engineering work. That creates an evidence problem. A human approval leaves a record. An agent that analyzes a story, attaches evidence, or requests a status change has to leave one too, or the audit chain has a hole in it.
The question is no longer whether AI can do the work. The question is whether the enterprise can control how AI does the work.
What we built. Backend support for Bring Your Own Agent workflows: agent registration, runtime, task, invocation, and approval APIs. Register an external agent. Define its provider type, authentication, allowed surfaces, capabilities, mutation policy, and approval behavior. Assign a story, task, or issue to it, and you create a durable task a runtime can claim and execute. We also shipped the frontend BYOA configuration and launcher flows, AI action buttons across key workflows, and policy logic that filters AI actions by page, permissions, subscription, and approval rules.
A note on execution, because precision matters here. Webhook agents can be invoked directly. LoopIQ calls the endpoint, waits, and processes the returned actions through governance policies. MCP-style agents, local workers, cloud workers, and other provider types are cataloged and participate through the BYOA task queue, where runtimes claim work, report progress, and submit governed output. Direct live invocation today means webhook. MCP-style agents can be registered and governed through the BYOA runtime and task model as we expand direct MCP execution support.
The governance layer matters
BYOA in LoopIQ is not "connect an agent and let it run." Every external agent operates inside the same governance model as the rest of the platform.
- Sensitive actions can require approval. Status changes, evidence attachment, release-impacting actions, and other high-risk mutations can be paused for human review before LoopIQ applies them.
- Mutation policies define what an agent can change. An agent can analyze, comment, attach evidence, request a status change, or create work only if its policy allows it. Denied actions are recorded, not silently ignored.
- Permission and subscription boundaries still apply. BYOA does not bypass tenant, organization, team, role, or plan controls. An agent only operates within the surfaces and capabilities your organization has enabled.
- Non-webhook agents run through governed runtimes. Webhook agents can be invoked directly. MCP-style agents and worker-based agents participate through the BYOA task queue, where runtimes claim work, report progress, and submit governed output.
- BYOA agents are not human users, but they can be assigned work. A story, task, or issue can be assigned to a BYOA agent, creating a durable task a runtime can claim and execute.
- Outputs become governed artifacts. Agent results are stored as output attachments, comments, audit records, evidence, or action results depending on policy. That gives auditors something inspectable, not just a chat transcript.
Every LoopIQ-mediated invocation, task event, approval, output attachment, and blocked action becomes part of the evidence trail. That is the difference between "we used an agent" and "we can prove exactly what the agent did."
Bring your agents. LoopIQ brings the governance. The future will not belong to the teams with the most agents. It will belong to the teams that can govern agents at scale.
MCP and the assistant layer
Why we tackled this. Agentic workflows have to stay governed even when the tools are broadly available. A raw tool surface wired straight to the UI is a governance gap waiting to happen.
What we built. We expanded LoopIQ MCP tooling with AI and ML agent exposure, and added assistant policy enforcement so the frontend does not expose raw MCP tools directly. The assistant backend filters MCP tools by page context, permissions, subscription, and approval rules. We also added backend-controlled AI action visibility for the UI, and improved MCP route catalog generation and the production deployment flow.
Release governance
Why we tackled this. The release is the moment compliance is either proven or reconstructed by hand months later. The closer the evidence sits to the release, the less audit prep costs. We want the dossier to exist the moment the release ships.
What we built. AI governance actions in release certification, and release-level checks for compliance, security, evidence, risk, and readiness. We added backend WorkGraph traversal APIs for related items, impact, traceability, and evidence-chain views, and improved release evidence dossier support. A governed agent output can appear in the release dossier when it is linked to release evidence or governed output, the same chain a human approval flows through.
Security operations
Why we tackled this. Security findings are release evidence. Treat them as a separate report and you pay to stitch them back into the audit story later.
What we built. Improved GitHub Security Operations metrics and trend handling, improved Datadog Operations data handling, and better support for vulnerability metrics and release evidence panels. We also improved how Datadog and GitHub security findings render in the frontend.
Analytics
Why we tackled this. Reporting tells you what happened. A real analytics layer helps you ask better questions. And a generated query you cannot trust is worse than no query at all.
What we built. Plain English SQL generation for analytics, backed by a SQL generation API with validation guardrails. We wired it into custom charts and the metric drawer, and added analytics agent support for SQL generation and validation, so the query is checked before it runs.
Global search and WorkGraph
Why we tackled this. Traceability needs a connected graph with consistent fields. Inconsistent search documents make impact and evidence views unreliable.
What we built. We standardized Elasticsearch documents with canonical fields like object type, tenant, team, title, description, permission scope, and semantic search text, and upgraded the Elasticsearch agent toward query-planner behavior across search, graph, SQL, and MCP actions. We ran a production canonical backfill and updated the production sync runner to preserve canonical search fields.
Platform hardening
Why we tackled this. Governance is only as strong as its boundaries. A platform people trust with audit evidence has to be reliable and secure by default.
What we built. On access and permissions, we restricted Grant and Revoke Access to organization admins, improved user fetching for access management, added backend-controlled action visibility based on permissions and subscription state, and addressed permission-related 403 patterns. On the import and export platform, we secured tenant access for the APIs and added Cloud Deploy and Cloud Run deployment pipelines. In project management, we improved sprint dashboard behavior and limits, work item assignment, project calendar stability, and performance review rendering. We added BYOA setup and usage documentation, refreshed the documentation navigation and content map, and on the operational side moved production Elasticsearch sync to Secret Manager instead of hardcoded secrets, repaired production bastion SSH access, and verified canonical search indexing after the backfill.
See it in your stack
That is what we shipped this week. One throughline runs under all of it. The work and the record live on the same surface, so the evidence moves with the work instead of being reconstructed after it.
Less manual follow-up. Less duplicate entry. Less audit anxiety. More traceability. More confidence. A release that once took days of evidence gathering moves toward a one-click release compliance dossier.
Try LoopIQ free and see the evidence chain on your own releases.