A New Protocol for AI in Regulated Industries

The Model Context Protocol (MCP) is emerging as a standard for how AI agents interact with external tools and systems. For most industries, this is a convenience — AI assistants that can query databases or manage calendars. For regulated industries like life sciences, it’s something more significant: a structured way to let AI agents participate in MCP regulatory AI compliance GxP workflows while maintaining the guardrails that regulators expect.

At DnXT, we’ve been building MCP-based tools since March 2026. Not as a product announcement — as internal infrastructure. Three MCP servers, 30 tools, running in production every day. Now we’re designing the next step: opening that infrastructure to customer AI agents.

What We’ve Built So Far

Our internal MCP infrastructure consists of three servers, each with a specific purpose:

  • Database Access Server — 9 tools for querying regulatory data (GLB_DATA platform layer). Read-only enforcement is hard-coded: INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, and TRUNCATE are blocked at the protocol level, not by policy. Legacy tables are blocked to enforce our platform-first architecture. Row limits cap at 500 per query.
  • Infrastructure Management Server — 13 tools for Azure Container Apps deployment, log viewing, revision management, and environment variable validation. Production deployments require explicit double-confirmation (confirm_production=true flag).
  • Code Quality Server — 8 tools for pre-build checks, scanning for hardcoded URLs, verifying CSS synchronization, and detecting self-closing HTML tags that cause rendering bugs.

These are developer tools. They assume a trusted operator with shell access. They have no customer-facing authentication layer, no per-tenant scoping, and no rate limiting. They’re useful internally, but they’re not what a customer’s AI agent needs.

What Open GxP Will Look Like

The customer-facing layer we’re designing — we’re calling it Open GxP — wraps our existing REST API surface (369+ endpoints across 100+ controllers) with three additions: OAuth2 authentication, per-tenant scoping, and permission-based access control.

The planned tool registry has approximately 40 tools across seven categories:

  • Workflow Management — list instances, check status, preview transitions (preCheck), advance workflows, manage tasks
  • Document Management — list, search, upload (via signed URL), update metadata, classify for eCTD
  • Audit Trail — query audit records, approval history, access logs, compliance status
  • E-Signatures — check status, list signatures, request signatures, validate integrity
  • Regulatory Configuration — agencies, controlled vocabularies, eCTD mappings
  • Platform Data — object type queries, field mappings, record retrieval
  • Submissions — list dossiers, read validation reports

Important clarification: this customer-facing server is in design. It is not live yet. The internal MCP servers are running in production. The REST endpoints that Open GxP will wrap are running in production. The MCP gateway layer is planned.

The Hard Blocks: What AI Agents Cannot Do

In a MCP regulatory AI compliance GxP context, what you prevent matters as much as what you enable. Our design includes hard technical blocks — not policies that an agent could work around, but tool-level restrictions:

  • AI agents cannot sign documents. There is no esign_sign tool. 21 CFR Part 11 requires electronic signatures to be attributable to specific individuals. An AI agent can request a signature (creating a PENDING record), but the human must authenticate and sign in the UI.
  • AI agents cannot publish submissions. Publishing generates regulatory submissions sent to health authorities. This is too high-consequence for programmatic access.
  • AI agents cannot delete data. Documents are archived via workflow transitions, not deleted via API.
  • AI agents cannot access other tenants’ data. Tenant identity is derived from the API key server-side. The caller cannot specify a different tenant.
  • AI agents cannot bypass workflow gates. If a transition requires e-signature approval, the preCheck returns requiresHumanAction: true and the advance is blocked.

How This Compares to Kivo’s Headless GxP

Kivo, a competitor in the regulatory technology space, announced their “Headless GxP” approach in May 2026, with three features planned for private beta in July 2026. Their approach also uses MCP, with a pattern they describe as: AI researches and recommends, human takes action in the application, Kivo records both.

We think Kivo identified the right protocol and the right interaction pattern. Where the approaches differ is in what sits behind the MCP layer:

  • Infrastructure depth: DnXT has 30 internal MCP tools running in production and 369+ REST endpoints across a full regulatory platform (eCTD publishing, validation, document management, workflow engine). Kivo’s announcement describes 3 features entering private beta. These are different stages of maturity, and that’s a factual difference, not a value judgment.
  • Compliance infrastructure: DnXT’s audit trail is structural — built into the data write layer (PlatformDataWriter), not added as a logging step. Our ESignatureService is designed for 21 CFR Part 11 compliance. Whether Kivo has equivalent infrastructure isn’t clear from their public materials.
  • Scope: DnXT is a full regulatory platform with eCTD publishing, multi-region validation, and document lifecycle management. Kivo appears focused on compliance record-keeping. Different scopes serve different customer needs.

We should also be honest about where Kivo may have advantages:

  • Simplicity: “Plug your AI agent into our compliance API” is a simpler pitch than “adopt our full regulatory platform.” For companies that already have publishing infrastructure and just need a compliance layer, Kivo’s approach could be a better fit.
  • AI-agnostic from day one: Kivo’s marketing emphasizes working with any AI. DnXT’s internal tools were built for Claude Code specifically, though the Open GxP design is deliberately agent-agnostic.

Both companies are early. MCP in regulatory technology is a new frontier for the entire industry. The question isn’t which approach is “right” — it’s which approach fits a given organization’s existing infrastructure and regulatory needs.

Why “Open” Instead of “Headless”

We chose the word “Open” deliberately. “Headless” implies decoupled — the compliance engine operates without a traditional UI. “Open” implies accessible — any AI agent can connect, regardless of provider. Claude, GPT, Gemini, or a custom model built in-house. The MCP protocol is the standard; the AI provider is the customer’s choice.

This matters because pharma companies have diverse AI strategies. Some are invested in one provider. Others use multiple models for different tasks. A regulatory compliance layer should work with all of them.

What Comes Next

Our implementation plan has four phases: read-only tools first (letting AI agents query data and check compliance status), then write tools (workflow advancement, document upload), then advanced features (e-signature requests, regional variants), and finally SDKs and documentation.

We’ll share progress transparently as we build. If you’re evaluating AI integration for your regulatory workflows, we’d welcome the conversation — whether DnXT is the right fit or not.

This article was written by the DnXT Solutions team. We’ve aimed to present both our approach and the competitive landscape honestly. If we’ve gotten something wrong about another vendor, we welcome corrections at se******@***********ns.com.