Platform overview

Msharti is one platform with two planes. The access plane connects AI assistants to the systems your business runs on. The control plane decides what those assistants are allowed to do once they are connected. Everything else in this handbook is a detail of one of those two.

26 connectors 149 tools 7 categories 20 live today

The two planes

Most teams reach for AI access and AI governance as separate purchases: an integration layer from one vendor, a policy or monitoring product from another. The gap between them is where incidents live, because the thing that connects is not the thing that decides. Msharti puts both on one platform so a connection cannot exist without a policy attached to it.

Access planeControl plane
Question it answers
How does AI reach the business?
Question it answers
What is AI allowed to do there?
One governed MCP endpoint for every assistant in the organisation OAuth 2.1 identity, so a tool call runs as a person, not as a shared robot
26 pre-built connectors exposing 149 AI-callable tools Role-based access with per-role tool allowlists
Dynamic tool discovery, so new tools appear without client changes Prompt-injection detection and secret stripping on every request
Managed cloud, private instance, or fully on-premise An immutable audit log of every call, agent and permission change
ℹ️

Where the names come from. The marketing site calls these Control Plane and AI access platform. They are the same two planes described here. The handbook uses "access plane" and "control plane" throughout.

What the platform is made of

The path a request takes

Nothing reaches a business system without passing all six stages. They run in this order on every single call, with no fast path and no exemption for trusted clients. Request flow covers each stage in full.

1
Authenticate

The gateway validates the credential on the request. Invalid or expired credentials are rejected before any data is touched.

2
Resolve tenant

Every credential is scoped to exactly one tenant. The gateway loads that tenant's connectors, encrypted credentials and role permissions.

3
Check the role

The role attached to the credential carries a tool allowlist. A tool outside the list is refused here, whatever the assistant asked for.

4
Scan for injection

The payload is checked for prompt-injection patterns, attempts by content inside your own data to redirect the assistant. Flagged requests are blocked and logged.

5
Route to the connector

The request goes to one isolated connector container, which decrypts the credential for that system, calls the real API, and returns the result.

6
Strip secrets, log, return

Keys, passwords and sensitive identifiers are redacted from the response. The call is written to an immutable audit log. The clean result goes back to the assistant.

What is connected today

Coverage is deliberately weighted toward the systems East African businesses actually run on. M-Pesa and KRA are first-class connectors rather than something you build yourself, because no global MCP provider models a Daraja transaction or a KRA PIN.

CategoryConnectorsTools
Core Kenya 2 25
Microsoft 365 4 21
CRM & Support 4 20
Collaboration 7 41
Database 2 10
Marketing & Analytics 5 24
Finance & IT 2 8
Total 26 149

The full list, with the tool names each connector exposes, is in the catalog.

What the platform does not do yet

Two capabilities appear on the roadmap and are named as roadmap wherever they appear on the site. They are not shipped, and nothing in this handbook documents them as if they were.

CapabilityStatusWhat exists today instead
Self-serve MCP builder
Turn an in-house API into a governed MCP server without engaging our team.
Roadmap Custom connectors are built as an engagement. Talk to us.
Approval workflows
Require human sign-off on sensitive write actions before they execute.
Roadmap Scope write tools out of the role entirely. See roles and permissions.