Connecting M-Pesa to AI: What Kenyan Businesses Need to Know

M-Pesa Is Money in Motion

M-Pesa processes over KES 30 trillion annually in Kenya. For a business, connecting it to an AI assistant means:

• Customer service: “What’s my last transaction?” answered in seconds
• Operations: AI monitoring payment flows and flagging anomalies
• Finance: Automated reconciliation of M-Pesa receipts against invoices
• Sales: AI-powered checkout via WhatsApp with instant M-Pesa confirmation

But M-Pesa is also regulated financial infrastructure. A misconfigured integration doesn’t just leak data. It can move funds incorrectly, expose customer financial records, or violate the Daraja API terms and CBK guidelines.

This article is a practical guide: how to connect M-Pesa Daraja to AI assistants safely, using an Enterprise AI Access Platform that provides the controls that matter for real businesses.

The Category: Enterprise AI Access Platform

Unlike traditional integration platforms that connect applications to applications, an Enterprise AI Access Platform connects AI to the enterprise, with the security, governance, and audit controls that regulated institutions require.

Unlike AI assistants that rely only on public knowledge, an Enterprise AI Access Platform gives AI secure, governed access to the systems and information that make every business unique.

Unlike point integrations built for a single AI tool, an Enterprise AI Access Platform provides one governed layer that works across Microsoft Copilot, ChatGPT, Claude, and future AI technologies.

Msharti is an Enterprise AI Access Platform. Its mission is simple: give AI secure access to your business.

For M-Pesa specifically, this means the AI never touches the Daraja API directly. Every call flows through the platform’s security layer: authenticated, scoped, logged, and governed.

What the Daraja API Actually Gives You

The Daraja API provides several endpoints, each with different risk profiles:

The golden rule: The higher the risk level, the more controls you need before an AI can call it.

The Unsafe Way (What Most Developers Build First)

A Python script with hardcoded credentials. Direct database connection. No logging. No scope restriction. This works on day one. It’s a breach on day 100.

Everything wrong with it:

• Hardcoded credentials in source code, visible to anyone with repo access
• No authentication on who can trigger the integration
• No log of when balance was checked and by whom
• No rate limiting: an AI loop could call this 1,000 times per minute
• No scope restriction: the same code could be modified to call B2C or Reversal
• No audit trail for CBK or internal compliance
• No error handling for network failures or API changes

If this is in your production environment, you need an Enterprise AI Access Platform.

The Safe Way: Enterprise AI Access Platform for M-Pesa

An Enterprise AI Access Platform wraps every M-Pesa API call in four security layers:

User asks AI: "What's my last M-Pesa payment?"
         ↓
[AI Client: Copilot / Claude / Custom Bot]
         ↓
[Enterprise AI Access Platform: Auth + Authorization]
         ↓  "Is this user authenticated? What can they query?"
         ↓
[Scope Enforcement: Tenant Isolation]
         ↓  "This customer ID can only see their own transactions"
         ↓
[M-Pesa Connector: Daraja API Adapter]
         ↓  "Translate to Daraja-specific call"
         ↓
[Daraja API: Operator Endpoint]
         ↓
[Response flows back through each layer, logged at every step]

Layer 1: Authentication (Who Is Asking?)

Before any M-Pesa API call, the platform verifies:

• User identity: Is this an authenticated customer, employee, or system account?
• AI agent identity: Is this the approved bot instance?
• Session validity: Is the token current?

Layer 2: Authorization (What Can They Do?)

Not every user needs every M-Pesa endpoint. The platform enforces role-based scoping:

Critical rule: The AI should never directly call B2C or Reversal. These require human approval through a separate workflow.

Layer 3: Tenant Isolation (Whose Data?)

In multi-tenant environments (SACCOs, agencies, fintechs with multiple clients):

• Customer A’s AI query returns only Customer A’s M-Pesa data
• Business X sees only Business X’s transactions
• No cross-tenant leakage via prompt injection or query manipulation

Layer 4: Audit Logging (What Happened?)

Every M-Pesa API call is logged:

{
  "timestamp": "2026-07-27T14:32:11+03:00",
  "user_id": "user_abc123",
  "tenant_id": "sacco_nairobi_east",
  "operation": "transaction_status_query",
  "mpesa_request": { "transaction_id": "LGR319G2" },
  "mpesa_response": { "status": "success", "amount": 5000, "currency": "KES" },
  "source_ip": "102.67.XX.XX"
}

These logs export to your existing SIEM, support data subject access requests, and provide evidence for CBK audits.

How Msharti’s M-Pesa Connector Actually Works

Msharti’s M-Pesa Daraja connector provides 9 AI-callable tools:

All 9 tools are governed by the platform’s security layer:

• Prompt-injection detection on every query
• Secret stripping for M-Pesa codes in logs
• Kenya-specific PII detection
• Role-based access control
• Immutable audit logging

Specific Integration Patterns

Pattern 1: AI Customer Support (Read-Only)

Use case: Customers ask your AI chatbot about their payments via WhatsApp.

Platform configuration:

• Endpoints exposed: query_transaction_status, check_balance (if customer owns account)
• Scope: Read-only, filtered by authenticated customer ID
• Rate limit: 10 queries per customer per hour
• No B2C, no reversal, no STK push

Sample conversation:

Customer: “I paid KES 5,000 yesterday. Did you get it?”

AI: “Your payment of KES 5,000 (Transaction ID: LGR319G2) was received on 26 July at 14:32. Your invoice #2847 is now marked as paid.”

Pattern 2: AI Finance Monitoring (Read-Only, Internal)

Use case: Finance team uses Copilot to monitor M-Pesa float and detect anomalies.

Platform configuration:

• Endpoints: check_balance, query_mpesa_history with filters
• Scope: Internal finance team only
• Rate limit: 100 queries per hour per team member
• Alerting: Float drops >30% in 1 hour triggers alert
• No write operations

Pattern 3: AI-Initiated Payments (Write, High Control)

Use case: AI generates STK Push requests for invoices, or initiates B2C payouts.

This is the highest-risk pattern.

STK Push:

• AI can generate the push request (amount, phone number, description)
• Customer confirms on their phone (the operator’s own interface, outside AI control)
• AI monitors for confirmation
• Platform logs every step

B2C (Business to Customer):

• AI prepares the disbursement
• Human manager must approve via dashboard or OTP before platform executes
• Dual authorization for amounts over KES 50,000
• Daily limit enforced by platform
• All B2C calls logged and alerted to compliance

Reversal:

• Never exposed to AI
• Admin-only, manual, fully logged

Real Recipe: M-Pesa Reconciliation

This is an actual recipe from msharti.dev:

// 1. Pulling M-Pesa Paybill 247810 for May
mpesa.query_mpesa_history({
  month: "2026-05",
  paybill: "247810"
});

// 2. Cross-ref against Sage invoices
sage.list_invoices({
  month: "2026-05",
  status: "unpaid"
});

// 3. Validate TCC on each supplier PIN
kra.check_tcc_status({
  pins: suppliers.map(s => s.kra_pin)
});

What the AI returns: “M-Pesa collections: KES 4.2M. Unpaid Sage invoices: KES 890K. 3 suppliers have expired TCCs. Recommend follow-up.”

Time: 4 minutes. Manual equivalent: 3 days.

Regulatory Alignment

Daraja API Terms

The Daraja terms require:

• Compliance with applicable data protection laws
• Appropriate technical and organisational security measures
• No unlawful use of the API

An ungoverned AI integration violates all three. An Enterprise AI Access Platform is the technical measure that demonstrates compliance.

CBK Guidance

The Central Bank of Kenya’s cybersecurity guidance expects:

• Access controls commensurate with risk
• Audit trails for all financial transactions
• Incident response capabilities
• Third-party risk management

An AI that queries M-Pesa is a third-party system accessing financial infrastructure. CBK expects the same controls as for any core banking vendor.

Kenya Data Protection Act

• Lawful basis: Document why AI is processing customer financial data
• Data minimization: AI sees only what it needs (platform enforces this)
• Security of processing: TLS 1.3, credential encryption, audit trails
• Data subject rights: Platform logs support access, correction, and erasure requests

Getting Started

For Existing M-Pesa Integrations

1. Audit what scripts, apps, or AI systems currently call Daraja
2. Inventory where credentials are stored
3. Review whether every integration has access to endpoints it doesn’t need
4. Check logging: can you answer “What queried M-Pesa last Tuesday at 3 PM?”

For New AI + M-Pesa Projects

1. Start with read-only: query_transaction_status, check_balance
2. Add STK push: Customer-initiated, customer-confirmed
3. Add B2C last: Only with dual approval, daily limits, full alerting
4. Never expose reversal to AI: Admin-only, manual, logged

Msharti Free Tier

• 5,000 calls to test the M-Pesa connector
• All 9 tools available
• Full security stack: prompt-injection detection, secret stripping, audit logging
• No credit card required

Docs: msharti.dev/docs, with the M-Pesa connector guide, quick start, and security overview

The Msharti Vision

We believe AI will become the primary interface to enterprise software.

Employees won’t navigate dozens of applications to find information. They’ll simply ask AI.

For that future to work, AI must be able to securely understand, retrieve, and act on business information.

Msharti is building the infrastructure that makes that possible.

msharti.dev

This guide reflects Daraja API terms and CBK guidance as of July 2026. Verify current terms before implementation.