Skip to main content

Governance and Trust

info

This page currently covers Mambu Agents and Mambu MCP. Other parts of the Mambu Agentic Platform are covered elsewhere.

Actions on the Mambu Agentic Platform are bound by a trust layer: they run under a real user's own permissions, are checked against your guardrails before they happen, and stay visible to you for oversight. Governance is part of the platform rather than added on top, holding every agent and every request to the standards Mambu applies across its platform. This page sets out the shared responsibility model, how data is handled and secured, how guardrails, audit and explainability work, and which parts of the system are AI and which are not.

The Trust Layer​

Agents inherit four controls, designed in such a way that they cannot be bypassed by configuration.

  • Authentication. Agents act as real users with real permissions, never hard-coded credentials.
  • Permissions. Deny-by-default access at tenant and user level, with per-user permissions. You decide what agents and users can do.
  • Observability and analytics. Configuration changes are logged, and MCP calls an agent makes are captured in analytics, so you can monitor and review how AI is used.
  • Guardrails. Configurable and built-in limits, so an agent stays within what you allow.

Shared Responsibility Model​

Mambu operates the platform. You govern how it is used within your organisation. The split differs between Mambu MCP and Mambu Agents, because Mambu MCP is used with a client and model you supply.

Shared Obligations​

  • Accuracy. Mambu is responsible for the deterministic retrieval of banking data from the Core. You are responsible for verifying the model's interpretation and wording of the final answer.
  • Reporting. Report any security incident or unexpected agent behaviour to Mambu promptly.

Mambu MCP​

AreaMambuCustomer
Availability and operation of the MCP service✓
Security and maintenance of the MCP service✓
Authenticating requests against Mambu Core✓
Enforcing Mambu Core permissions on every call✓
Capturing invocations in analytics✓
Which operations are enabled at tenant level✓
Which operations each user may reach✓
Choice, operation and governance of the AI client and model✓
The model provider's data-handling terms✓
Verifying agent output before acting on it✓
Managing the client's credentials✓
Configuring and managing Mambu Core users and permissions✓

Mambu Agents​

AreaMambuCustomer
Operation of Mambu Agents and Agent Studio✓
Availability and governance of the AI model✓
Enforcement of guardrails✓
Audit logging of agent actions and configuration changes✓
Defining and maintaining agents and skills built by Mambu✓
Configuring the tenant-specific domain context as part of the Agent DNA✓
Selecting and configuring agent skills and playbooks✓
Content and accuracy of customer-defined skills and playbooks✓
Content and accuracy of uploaded knowledge sources✓
Configuring customer-controlled guardrails✓
Granting agent access to users and roles✓
Reviewing agent activity and model outputs✓

Security and Data Handling​

Security is built into the platform. This section describes how your data is protected and how AI interactions are kept secure.

Where Data Lives​

Underlying Mambu systems remain the system of record. Mambu Agents and Mambu MCP read your banking data from the underlying system on demand. The source data continues to be held and maintained in the underlying Mambu system.

Authentication and Access​

  • Delegated authentication. Users sign in with their existing Mambu credentials.
  • Permission enforcement. Requests run under the user's own permissions. An agent is designed not to see data the asking user would not be allowed to access in Mambu.
  • Deny-by-default. Execute operations on the Mambu MCP connection are off until an administrator switches them on for the tenant and the user.

Model Training​

Your data is not used by Mambu to train AI models, as set out in your agreement. For Mambu Agents, the Mambu-managed model is not trained on your banking data or your users' conversations. For Mambu MCP, data handling is governed by your agreement with your chosen model provider.

Encryption and Residency​

Data is encrypted in transit and at rest. It is processed in the geographical region defined in your Agreement and applicable Order Forms.

Guardrails, Audit and Explainability​

Guardrails sit between an agent and your data and are evaluated on every request and every action, independently of the model. Enforcement works two ways. Deterministic rules are designed to block prohibited requests consistently, regardless of how a prompt is phrased. Alongside them, the model is instructed to act within the agent's definition, its Agent DNA and skills, so its behaviour stays shaped by your configuration. Together they are designed to keep an agent inside the limits you set while it acts on your behalf. A request blocked at this stage is designed to be stopped before data retrieval takes place.

The Checkpoints​

Every request passes through a series of independent checks between the question and the answer, and any one of them can stop it. These checks are designed to enforce, among other things:

  • Scope: requests are screened against the agent's defined scope, including attempts to override the agent's instructions
  • Data minimisation: the data made available to the model is limited to what the user is entitled to see and what the task requires
  • Operation permissions: each operation is checked against both the agent's permitted set and the user's own permissions before it runs
  • Content handling: content returned from records is treated as data rather than instructions, by design
  • Output validation: responses are validated before they are shown, including against the agent's disclosure restrictions

Every guardrail decision is recorded for audit purposes, and guardrails fail closed: a check that cannot reach a decision blocks the request rather than letting it through.

What a User Sees​

When a guardrail blocks a request, the user sees a clear card rather than a raw error. It says whether the block is a scope restriction (resolved by changing the agent), a permission requirement (resolved by changing the user's Mambu role), or a usage limit. Refusals never explain the underlying rule, since that would show how to work around it.

The Audit Log​

Every configuration change, access change and MCP call is recorded, with who, what and when. Administrators can filter and export it from Agent Studio. The audit log records which operation ran, never the banking data returned.

Explainability​

  • Citations. Every answer cites the operations behind it, linking to the Mambu operation and the moment the data was read. If a traceable source cannot be produced, the agent says so rather than answering.
  • Computed values. Where an agent calculates a value rather than reading it, it is labelled as computed and shows its formula, so the arithmetic can be checked.

AI Transparency and Oversight​

Users are always told they are interacting with an AI system, a disclosure that cannot be switched off. Human oversight is built in: read-only agents cannot act, and every answer is sourced so a person can verify it.

What Is Generated, and What Is Not​

Knowing which parts are generated shows where to place trust.

Part of the systemNatureWhat that means in practice
Figures retrieved from Mambu CoreDeterministicA balance or a schedule is read from the core, unchanged
Access control and permissionsDeterministicRule-based, not decided by the model
Guardrail decisionsDeterministic and non-deterministicSome are fixed rules; others use a model to judge intent
Audit loggingDeterministicConfiguration changes and MCP calls are recorded
Choice of which operation to callNon-deterministicThe model decides, and may decide differently for the same question
Wording of the answerNon-deterministicPhrasing, ordering and emphasis vary between runs
Summarising and interpretingNon-deterministicThe model may omit or over-generalise
Last updated on