Information barriers underneath your agents

Your platform makes the model replaceable. MahaGuardian makes the barrier portable — and leaves the keys with your customer.

What your professional-services customers will ask

Law firms, deal advisers, PE houses and family offices all ask the same thing before they let agents near client work: can an agent working for Client A reach Client B's data, if the same person can reach both?

Platform controls answer part of this — who may use which tools, which data sources are connected, what happened afterwards. What they cannot give the firm is evidence the firm holds itself, enforced at the level of a single client, project or deal.

One engagement per agent run

1. An agent run starts on your platform, assigned to one engagement.
2. It obtains a MahaGuardian credential for that engagement — short-lived, scoped and issued by the customer's Guardian.
3. Its tool and data calls pass through that credential. Each is allowed, denied or escalated to a named human.
4. Every decision is recorded in a hash-chained audit trail on the customer's infrastructure.

Model routing, workflows and your user interface are unchanged. The barrier sits in the credential, not in the prompt.

Who holds what

Your platform	Your customer	MahaGuardian
Model routing, agents, workflows, platform logs	Guardian signing keys, engagement structure, named approvers, audit trail	Software only — no keys, no client data

Works with your controls, not against them

Your controls govern the workspace: which agents exist, what they may connect to, what they did. MahaGuardian governs each agent's authority within a single engagement, with the evidence held by the customer. A compliance officer can point to both.

Breaking the lethal trifecta

An agent becomes dangerous when it combines three things: access to private data, exposure to untrusted content — an email, a web page, a shared document — and a way to send data out. One injected instruction can then carry one client's data to someone else.

MahaGuardian does not stop untrusted content reaching the agent. It limits what that content can achieve:

• Private data: the credential opens one engagement, so there is only one client's data within reach.
• Sending data out: external communication can be set as an Elevate action, requiring a named approver.
• After the fact: every attempt, allowed or denied, is in the customer's audit trail.

Integration status

Path	Status
Standard enterprise API authorisation — OAuth app registrations, service principals, delegated scopes	Available (V1)
Remote MCP gateway — add MahaGuardian as an MCP integration (Streamable HTTP, OAuth 2.1), with tools limited to one engagement	In development
Always-on, multi-tenant deployment with high-availability key management	V2 (2027)

Tested with OpenAI, Anthropic and Google models and with self-hosted Llama and Mistral. New interfaces are worked through with partners before deployment. See the roadmap.

European by design

• Custody: signing keys and audit records stay with the customer. Client data never passes to MahaGuardian.
• GDPR: per-engagement access supports data protection by design and appropriate security (Articles 25 and 32).
• EU AI Act: the audit trail and Elevate approvals are designed to support record-keeping and human-oversight requirements (Articles 12 and 14).

MahaGuardian supports these obligations; it does not by itself make a deployment compliant.