Why our 3CX troubleshooting assistant logs in twice

We run 3CX as our own phone system, and like anything you run yourself, most of the job is troubleshooting. So we built a small piece of software that lets an AI assistant talk to our PBX and answer questions about it. It is an MCP server — the emerging standard for handing an assistant a defined set of tools — wrapped around 3CX's own API. The design choice people ask about is that it logs in twice.

Two doors into the same system

3CX's API can be spoken to in more than one way, and we use two on purpose.

• The system (API) login. A service credential that gives the assistant a broad, read-only picture of the whole phone system — queue statistics, call history, extensions, trunks, system status. This is what answers “how did the sales queue do last week” or “which trunk is that number on”.
• The user login. A real 3CX user session, so anything that is scoped to a person runs as that person, with that person's permissions — not with god-mode over everything.

Why not just use the admin key for everything?

Because reading widely and changing things are different risks, and they deserve different keys. It is safe to let an assistant see a lot; it is not safe to let it quietly become an administrator on the phone system. Splitting the two is plain least-privilege: the system credential answers questions, and the user context bounds what can actually be changed, and by whom. It is the difference between “the assistant can read the phones” and “the assistant is an admin on the phones”.

The guardrails that matter

By default the assistant reads. The handful of things that change configuration — re-pointing an inbound number, touching a trunk or an SMS setting — go behind a preview-then-confirm step: it shows you exactly what it intends to do, and nothing happens until a human says yes. Every change lands in 3CX's own audit trail, so it is attributable and reversible. A tool that can change your phone routing should never do it silently, and ours does not.

Why any of this is on a phone company's blog

To be clear about what this is and is not: 3CX's own AI features — call handling, transcription — are 3CX's, and they are good. This is not that. This is tooling we wrote around the platform, for our own system, to troubleshoot faster. We are not selling you an AI bot for your PBX. But it is the reason that when your 3CX does something strange, we can usually tell you what happened and why in about one question — instead of an afternoon spelunking through the console. Knowing a platform that well is not an accident; it is what happens when you build your own instruments for it.