Why include an "AI MCP Connector" with a security extension?

Danilo

I was extremely surprised to notice that recent updates to HTProtect now include an MCP connector.

While interesting, this obviously introduces a new surface area for potential security issues; if there are any bugs within the connector, it could provide a new entry point for malicious actors.

Because of this, I was wondering if it might be better to offer the AI MCP Connector (and all the Dashboard features) as a separate extension. This way, users who specifically want those functionalities can choose to install them, while those who only want to tighten security for a (usually single) website can stick to the core HTProtect security features without the added complexity.

Pascal

Hi @Danilo,

Good security mindset – and luckily, the answer is reassuring.

The key point: the AI/MCP layer is OFF by default and can be enabled per site with just one click – and just as easily turned off again anytime. As long as you don’t switch it on, it’s like a switch set to “off” with nothing connected behind it: no service account, no token, no API access, no AI access. For your security, it’s as if the feature doesn’t even exist – no new attack surface.

And if you do turn it on, it’s deliberately built tight:

Enabling it only works via a cryptographically signed command from your unlocked dashboard – an attacker can’t just activate the AI on their own.
Trusted methods instead of DIY: the AI mostly works through Joomla’s own Web Services API with a dedicated token; anything beyond that runs over the same signed, relay-blind command channel HTProtect already uses – no new open access.
Minimal permissions: the default AI account is explicitly not a Super User (content only) – no server access. Higher permissions require a separate, explicit opt-in and still stay below Super User level.
The token never touches your browser and only leaves the site encrypted server-side – it’s never passed on to any third-party service. Revoking it with one click removes everything immediately.

And this is exactly why we offer it: Lots of people are already hooking AI into their Joomla sites – but usually way riskier. They hand out full SSH credentials, use unrestricted Super User access, or give a permanent API token to an external service (like some ready-made Joomla MCP solutions from JoomlArt). That’s exactly what we wanted to avoid: AI has huge potential, so we built a super easy way to use it quickly and with zero setup hassle – but as secure as technically possible (opt-in, signed, minimal rights, one-click on/off, elevated rights time-limited and automatically restricted back to read-only), not as a risky afterthought. And we’re expanding these features step-by-step – always following the same principles – as secure and useful as possible.

Why include it in HTProtect instead of a separate extension? Because “separate” doesn’t increase security (off is off), it just adds complexity and a second update track. One hardened, signed, auto-updating extension is ultimately safer – and if you just want to secure your sites without using AI, you simply won’t notice it unless you turn it on.

Thanks for the critical questions!

Cheers
Pascal

Danilo

Hi @Pascal,

Thank you so much for taking the time to provide such a detailed and precise explanation. It’s a relief to have such a clear answer, and I truly appreciate the level of attention you give to user security and privacy.
I also loved learning more about the robust architecture of the AI layer; these are vital considerations that I think many other users would find interesting, too.

I just wanted to offer a quick clarification regarding my suggestion about a separate extension increasing security.
While it is true that "off is off", my thought was that a separate extension provides an extra layer of protection for those who choose not to install the second one at all. While there is always a risk of a bug affecting how an "off" status is managed, if an extension isn't installed, there is simply no way for it to compromise a user.
That said, I completely agree with your other points, specifically that separate extensions add complexity and require a second update track. I just wanted to clarify my initial thought rather than argue against that decision.

Thanks!