How Maicell’s ConnectPlaza exposes governed AI tools, and what that does and doesn’t solve

Every enterprise integration platform was built to answer one question: who or what is allowed to talk to which system, and under what conditions. For twenty years the “who” was mostly humans behind applications, and the “what” was mostly other applications. In 2026 there is a third category. Copilots, autonomous assistants and LLM-powered workflows want direct, real-time access to order systems, ERPs, ticketing platforms and customer data, and they want it by calling a tool rather than by a person clicking a screen.

How well that third category gets governed turns on something unglamorous. Governance loses to convenience whenever convenience is faster. The ungoverned route takes an afternoon. The governed route takes a meeting. ConnectPlaza’s MCP Server Listener is built to close that gap, by exposing integration flows already running in production as governed AI tools, so the compliant path is also the quickest way to get an agent connected to something real.

Maicell grew out of ConnectPlaza, an integration platform running in production at more than 1,500 organisations worldwide since 2008. Governed Intelligence is the name for what sits underneath it. It’s enterprise AI that stays coherent, compliant and under executive oversight, with policy in the execution layer rather than added afterwards. The MCP Server Listener is where an agent meets that policy, and where it is authenticated, scoped and recorded before it reaches anything.

The governed path is the shorter path

For an organisation already running ConnectPlaza, exposing a flow through a governed MCP listener is less work than the alternative. The flow exists. The authentication configuration exists. What’s left is a listener configuration.

The alternative is what most organisations are seeing now. Static API keys pasted into prompt configurations, one-off scripts that route around existing access controls, temporary integrations that quietly become permanent. Teams take that route because it has been the quicker one, and speed usually decides.

Integration flows become AI tools

ConnectPlaza treats AI agents as a new consumer of infrastructure that already exists, so integration teams don’t build a parallel AI layer from scratch. A flow that already pulls stock levels from a retail ERP, looks up a customer’s order history or resolves a postal code gets exposed with the right shape and the right protocol. An incoming MCP request is converted into ConnectPlaza’s native message format, so it runs through the same engine, the same monitoring and the same operational controls as every other integration already in production.

How the ConnectPlaza MCP server works

The listener speaks JSON-RPC over Streamable HTTP and over the older HTTP with Server-Sent Events, so both current and earlier MCP clients can connect. ConnectPlaza 5.3.0 supports MCP specification revisions up to 2025-11-25, and ConnectPlaza 6.0.0 will add support for the 2026-07-28 revision. The listener distinguishes Tools, which are functions implemented as ConnectPlaza flows that execute logic and return data, from Resources, which are addressable content already held on the platform.

An agent’s call therefore lands in the same place a REST call from any other client lands. There is no separate AI path to instrument, and nothing new for an operations team to watch.

ConnectPlaza’s MCP listener at a glance

How AI agents are authenticated and authorised

The risk with agentic AI is what happens when an agent gets access it shouldn’t have, or when an integration built for internal convenience becomes the easiest route to exfiltrate data because nobody expected an LLM to be the client.

The same authentication as production REST

The ConnectPlaza platform gives the MCP listener the same authentication options as its production REST listener rather than a lighter, AI-specific substitute. BASIC authentication for simple cases, and full OAuth2 and OIDC support, implemented through the platform’s own HTTP server framework. It is a standard OAuth2 resource server rather than a bespoke AI-specific mechanism, so a security team can reason about it with what it already knows.

OAuth2 scopes and JWT claim expressions

Configured through an issuer URI or a JWK set URI, OAuth2 on the MCP listener requires a valid, verifiable access token before an agent can see which tools are available, let alone call one. Scopes limit a given agent, application or user to a defined slice of capability rather than the entire flow catalogue.

JWT claim expressions go further, letting administrators write explicit allow and deny logic based on what sits inside the token: department, role, environment, customer tenant. Authorisation becomes a policy decision made per request. That matters most in multi-tenant environments, and it goes further than it first appears, because the OAuth2 server itself is designated per MCP instance. Different tenants can authenticate against different identity providers while calling the same underlying flows, with access decided on the claims each one presents.

Add TLS with proper certificate and keystore management and the AI access layer becomes something a security team can reason about with the tools it already has, because it is a production integration endpoint.

Where it runs

The MCP Server Listener is part of the ConnectPlaza Agent, and the Agent runs wherever the customer puts it. On-premises, in a private cloud, in a public cloud region of their choosing.

That answers the data residency question before it gets asked. Agent traffic, the flows it triggers and the records it produces stay on the customer’s own platform, in the jurisdiction the customer selected.

For a European organisation with sovereignty obligations, the question to put to any platform is where its control plane runs, and whether that region can be chosen.

What token-based authorisation doesn’t solve

Any MCP Server, ConnectPlaza’s included, answers one question well: may this caller invoke this tool? That is per-request authorisation, and it is necessary. Behaviour over time is a separate problem. An agent entitled to call a tool can call it two thousand times. Three separately entitled tools can be combined into an outcome nobody designed.

Token validation also does nothing about prompt injection. An agent holding a legitimate token can be persuaded by content it reads to make a request that is both authorised and unwanted. Identity and scope limit how far such a request can reach. They don’t establish intent.

Two questions to ask any platform

Anyone evaluating platforms on agent governance should ask two questions separately, because they are answered by different mechanisms. What stops the call? And what proves, afterwards, what actually happened.
Ours sit in two places.

Cooperation with existing infrastructure.Throttling and rate limiting are infrastructure concerns, handled by an API gateway or its equivalent, in the same place they are handled for every other endpoint an organisation runs. ConnectPlaza works in tandem with the enterprise traffic management, routing and load balancing an organisation already runs, and extends it with the layer those tools don’t reach: security and policy enforced inside the execution path itself.

Stopping a misbehaving flow is a build, not a switch. Somebody has to say what misbehaving means for that particular integration, and the trouble usually starts in the systems a flow connects to rather than in the flow itself. The rule that catches a partner API returning malformed records is not the rule that catches a queue backing up behind a slow ERP. ConnectPlaza uses its pattern components, rules and control / monitoring to achieve this.

Every control above assumes a prior decision about what the agent is allowed to do at all. That decision is not a technical one, and in most organisations nobody has made it yet.

The governance record is a by-product of execution

In large organisations piloting agents, the worry is scale. Nobody knows how many agents exist across the company, what each one can touch, or who signed them off. A Cloud Security Alliance survey fielded in January 2026 found that 82% of organisations had discovered AI agents running in their infrastructure that they didn’t know about, in a population where 68% had said they were confident about their visibility.

An agent registry without a registry project

Packaged software solved that years ago with a registry: one authoritative place showing what exists, who owns it and what it’s allowed to do. Agents need the same catalogue, with ownership, scope and audit history attached to each entry, so governance doesn’t depend on one team’s memory of what got exposed and why.

ConnectPlaza’s flow-based approach produces that catalogue one governed listener at a time, without a registry project having to come first. Every flow exposed as an MCP Tool or Resource carries its own identity: a defined Host/Port/Context combination, an explicit OAuth2 or OIDC configuration, a scope that limits what it can be asked to do, and claim expressions specifying which identities may call it. That’s the metadata a registry needs to answer what tools exist, who can use them, and under what conditions. ConnectPlaza captures it when each capability is built rather than reconstructing it later as a compliance exercise, once dozens of ungoverned integrations already exist.

This catalogues only what runs through ConnectPlaza. An agent wired straight into a system with a pasted API key is exactly what a registry most needs to find, and it stays invisible to this one. Flow-level governance stops the visible part of the problem from growing while the rest is dealt with. That is a smaller claim than a complete enterprise registry, and a better starting point than an empty one.

EU AI Act Article 12 and automatic recording

The same architecture supports readiness for Article 12 of the EU AI Act. For systems that fall in scope as high-risk, Article 12 requires the technical capability for automatic recording of events across the lifetime of the system, so that risk situations, substantial modifications and post-market monitoring can be evidenced. The Digital Omnibus, in force since July 2026, deferred the Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and Annex I obligations to 2 August 2028. The Article 5 prohibitions and the Article 50 transparency obligations were unaffected, and Article 50 took effect on 2 August 2026 as originally scheduled.

Deferral is not cancellation, and the deferred date lands in the same period as most agent rollouts. Deloitte, surveying 3,235 IT and business leaders across 24 countries, found 74% expecting moderate to extensive AI agent use by 2027 and 21% with mature governance for agentic AI in place today. Where identity and action are recorded as the flow executes, the Article 12 question is answered by how the system runs, not by a reporting project bolted on for the audit.

When the compliant route is also the quickest way to get an agent into production, nobody has to enforce it, and the record a regulator will ask for is already being written.