An add-on layer that extends your firm's existing security infrastructure to the AI agents now acting on your staff's behalf. Your IdP, DMS, conflicts engine, and DLP keep working exactly as they do today — MahaGuardian gives each agent its own scoped credential within them. Vendor-neutral. Cryptographically enforced. Built for firms that cannot afford the headline.
MahaGuardian gives every AI agent in your practice a credential that opens exactly one matter's information and nothing else. It does not replace your identity provider, your document-management system, your conflicts engine, or your email security — it integrates with them and gives each AI agent its own scoped identity within the systems you already operate. It works with most AI vendors your firm uses today or chooses tomorrow. It is operated by your firm on your firm's infrastructure, not by a vendor on theirs. This brief describes the problem, what MahaGuardian does, where it fits in your existing stack, why vendor controls do not replace it, and how to engage.
Your firm has already invested in security infrastructure. None of it needs to change. The systems you run continue to work exactly as designed — they were built for human principals, and they keep working correctly when humans make the requests. The gap is that AI agents acting on a staff member's behalf today inherit that staff member's full credentials and full audit footprint: any folder the staff member can open, the agent can open; any action the agent takes is recorded as the staff member's action. MahaGuardian closes that gap by giving each agent its own scoped credential and its own audit identity within your existing systems.
Authenticates your staff and works exactly as it does today. An AI agent on a staff member's machine currently reaches downstream systems using the staff member's session — to those systems, the request is indistinguishable from the staff member's own. MahaGuardian issues the agent its own credential, bound to the staff member and scoped to a single matter, so downstream systems see the agent as a distinct principal.
Enforces folder-level access for your staff exactly as designed. An AI agent operating with a staff member's session today has the same DMS access the staff member has — every folder they can open, the agent can open. MahaGuardian issues per-agent, per-matter credentials compatible with standard enterprise API authorisation patterns (OAuth app registrations, service principals, delegated scopes), so the DMS sees the agent's narrower scope rather than the staff member's full scope.
Tracks matter walls at the staff level. An AI agent inherits the conflicts profile of the staff member running it, so the wall is enforced per human rather than per active engagement — even though the same staff member may legitimately work on both sides of a wall at different moments. MahaGuardian extends your existing conflicts taxonomy into the agent layer, so an agent assigned to Matter A cannot reach Matter B, even when the same staff member can reach both.
Catches sensitive content at egress. When an agent reads cross-matter data, incorporates it into a draft, and the draft then leaves through a sanctioned channel, DLP sees a routine outbound message from the staff member. MahaGuardian prevents the cross-matter read at source, through the Guardian-controlled credential boundary, before the content can reach the draft.
Detects malicious processes on staff machines. AI agents acting outside their intended matter scope are not malicious processes — they are authorised software running with the staff member's credentials, and every endpoint signal looks legitimate. MahaGuardian enforces scope at the agent's API boundary, regardless of endpoint health.
Every firm using AI agents in client work faces the same exposure: a model whose vendor promises it will not leak across matters, with no enforcement mechanism the firm itself controls. The vendor's promise is a policy. The risk is architectural.
AI agents acting on a staff member's behalf operate with that person's access. Without matter-scoped credentials, an agent active in one engagement can read — and incorporate — data from any other engagement the staff member can reach. The agent does not have to be malicious. It just has to be helpful in the wrong direction.
By construction, when correctly deployed, MahaGuardian closes this gap through the credential layer itself. The agent is not asked to be careful. It is issued a key that does not unlock other matters.
Every agent in your practice carries a credential that opens exactly one matter's information. There is no key on that credential for any other matter through the Guardian-controlled boundary. An agent that should not be able to read another client's file is not asked to be careful — it is given a key that does not unlock the file. The agent cannot widen its own scope, cannot escalate its own permissions, and cannot bypass the check by hallucinating its way past a prompt instruction.
Every retrieval the agent performs through MahaGuardian is recorded in a tamper-evident, hash-chained log. Because each agent operates under its own credential — distinct from the staff member's — its actions appear in a dedicated agent audit trail, not interleaved with the staff member's own activity. The log is signed, so any retrospective alteration is detectable. If a client's general counsel ever asks "show me everywhere the AI touched our data," the firm has a complete answer covering all Guardian-mediated retrievals and approvals. The audit log lives on your firm's infrastructure, not the vendor's. The Security Status page documents exactly what is and is not within audit scope.
For actions the firm has flagged as sensitive — moving money, sending external communications, sharing privileged material, accessing information above an agent's normal scope — the agent must request approval from a named human before proceeding. The request and the approving partner are both recorded. The agent cannot route around the gate through the Guardian-controlled boundary.
Your firm should not have to bet on a single AI vendor. The model market is moving fast — capabilities, pricing, and trust posture all shift quarter by quarter. MahaGuardian works with most AI agents that interact with your firm's systems through standard APIs. Whether your team uses OpenAI's models for technical work, Anthropic's Claude for legal drafting, Google's Gemini for diligence, AWS Bedrock for compliance review, or a self-hosted model for the most sensitive matters, the same MahaGuardian deployment enforces the same matter walls across all of them — wherever your systems support scoped, revocable credentials.
If your firm switches AI vendors next year — and it will, at least once — you do not re-architect your information barriers. The barriers live in MahaGuardian. The model is replaceable. This is the position your CIO wants to be able to take.
Microsoft Agent 365 (GA May 2026) provides a strong estate-level control plane: it discovers and inventories agents across Microsoft, AWS, and Google Cloud environments, applies governance policy, and — through its Secure pillar — can block unauthorised agents at runtime via Intune and Defender. These are real and valuable controls.
MahaGuardian addresses a complementary problem, at a different layer.
Different authority. Agent 365 governs which agents your firm runs and what resources they can reach. MahaGuardian governs whether an agent's credential comes into existence at all, and can destroy it. Microsoft decides what the credential can do once it exists; MahaGuardian decides whether it exists. Both halves are needed: platform governance without credential-issuance authority leaves the firm relying on its platform vendor for the full lifecycle; credential-issuance authority without platform governance leaves a gap in runtime enforcement and fleet visibility.
Independent evidence. MahaGuardian's controls are operated by the firm on the firm's infrastructure. Guardian authority records and the platform's own sign-in and activity logs can be reconciled, so a credential issued without firm authority is detectable by the firm itself. The signing keys never leave the firm's device. If a regulator, a court, or a client asks who controls the issuance of agent credentials, the firm has a locally held, cryptographically verifiable answer.
We work directly with firms that want cryptographic information barriers around their AI agents and are willing to shape the product with us. The arrangement is straightforward: the founder is your direct line. We ask for time, candour, and willingness to deploy in pilot scope on a defined slice of your AI usage. In return, the firm gets a working deployment and a direct relationship.
Between each AI agent your staff uses and the systems that agent reaches for data. The agent calls MahaGuardian for a credential; MahaGuardian issues a scoped, time-limited credential bound to that specific agent and that specific matter; the agent uses the credential against your DMS, email, or other system through standard API authorisation patterns. The systems behind never see MahaGuardian — they see a normal API request from a credential they can verify.
Commercial pricing is per-agent, per-month, in line with seat-licensed security software your firm already purchases. We will publish a price list when V2 ships.
V1 deploys in a day on a single compliance officer's or partner's laptop, with pilot scope of up to a few dozen agents. V2 will support firm-wide, always-on deployment and is planned for 2027; see the roadmap.
Agents operating with already-issued credentials continue to function within those credentials' validity window. Issuance of new credentials requires the device to be online. V1 includes a documented manual key-backup and recovery procedure; the recommended pilot scope is a defined set of agents on active matters, not firm-wide always-on issuance. High-availability key management is V2 work.
Yes, if the agent interacts with your systems through standard APIs. We have tested with OpenAI, Anthropic, and Google models, and with self-hosted Llama and Mistral. We have not tested every possible integration; we work through any new vendor's interface during the pilot.
Agent 365 is a strong estate-level control plane — it discovers which agents your firm runs, applies policy, and can block unauthorised agents. MahaGuardian sits alongside Agent 365 and adds a layer Agent 365 does not provide: engagement-scoped credential issuance so that an authorised agent working on Client A cannot reach Client B's data, even though both clients' data lives in the same systems the agent is authorised to access. Agent 365 governs the fleet. MahaGuardian constrains each agent's authority within its specific engagement.
Platform controls govern the workspace — which agents exist, what they connect to, what they did. MahaGuardian governs each agent's authority within a single engagement, with the evidence held by your firm rather than the platform. The two work together. See MahaGuardian for AI platforms.
A remote MCP gateway is in development. Agent platforms will be able to add MahaGuardian as an MCP integration, with each agent's tools limited to one engagement. See the roadmap.
The implementation is open source under a dual licence — open for review, audit, and non-commercial use; a commercial licence covers production deployments. Reviewers and security researchers are welcome to examine the codebase on GitHub.
Alexander Landia, founder. He is an investor and director of several companies, including the energy-sector advisory firm Lambert Energy Advisory in London and The Mobility House. He has worked on M&A and strategy mandates for 30 years. MahaGuardian began with a case: on an energy-transition mandate, one adviser legitimately held access to engagements that had to stay apart, and an AI agent working for him could reach all of them. He developed MahaGuardian at the MIT Media Lab, where the project was selected as a top project in the Agentic Web course. The codebase is open source and open to review by security researchers; the product is patent-pending in the United States.
The fastest path is to email alexander@landia.biz and mention you read the partner brief.
For security teams: the Security Status page maps every claim in this brief to a specific test in the open-source repository. The architecture white paper covers the cryptographic design in full.