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 sandboxes such as OpenAI's Codex Sandbox 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.
The picture: your existing controls continue to do exactly what they do today, against the human surface they were designed for. MahaGuardian operates between the AI agent and those systems, and ensures that whatever the agent does on a staff member's behalf reaches them through a credential the firm itself issued for that specific matter — with a distinct audit identity so the agent's actions never blur into the staff member's own.
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. This is the same control your firm already operates for wire transfers and outside-counsel referrals, applied to the action surface that AI agents are about to start operating on.
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.
In the past year, AI vendors have made significant investments in agent governance — most visibly Microsoft's Agent 365 (GA May 2026), which provides a control plane to discover, inventory, and apply policy to agents across Microsoft, AWS, and Google Cloud environments. OpenAI's Codex Sandbox, Anthropic's Code Execution environment, and similar vendor controls add execution-environment constraints. These are real and valuable improvements. They do not, however, solve the problem MahaGuardian addresses, for three reasons.
First — different layer. Vendor sandboxes constrain what an AI agent's execution environment can do — the files it can read on a developer's machine, the network requests it can make, the commands it can execute. Agent 365 governs the agent estate — which agents exist, whether they are authorised, which devices and cloud resources they can reach, and whether they should be blocked. MahaGuardian constrains what the AI agent's authority lets it reach across your firm's information systems. Even with both in place, if an authorised agent holds a credential that opens two client matters, it can still retrieve both. The sandbox stops the agent running unsafe code on a laptop. Agent 365 tells you which agents are running. MahaGuardian stops the agent reading another client's matter while drafting yours — by splitting the credential authority at the source.
Second — each vendor sandbox protects only that vendor's agents. If your firm uses one vendor's model for one task, another for a second, and a third for a third — and almost every firm using AI seriously already does — each runs under that vendor's own sandbox controls. Agent 365 extends visibility across clouds, but the underlying sandbox enforcement remains vendor-by-vendor. The firm has no single engagement-scoped enforcement layer across all of them. MahaGuardian is that layer.
Third — operated by the vendor, not the firm. Agent 365 runs in the Microsoft 365 admin center. Vendor sandbox controls run on vendor infrastructure. For many vendor-operated controls, firms may not hold independent, cryptographically verifiable evidence of every enforcement decision — evidence that would be entirely within the firm's own custody. MahaGuardian's controls are operated by the firm on the firm's infrastructure. The signing keys never leave the firm's device. If a regulator, a court, or a client asks who could possibly have widened an AI agent's permissions, the firm has a single, locally-held, cryptographically verifiable answer.
Vendor agent controls are a floor. The agents that operate against your firm's client data need an engagement-scoped ceiling as well, and the ceiling has to be installed and operated by the firm. That is what MahaGuardian is.
We are working with our first 100 design-partner firms — practices that want cryptographic information barriers around their AI agents and are willing to shape what V2 looks like with us. The arrangement is straightforward. There is no cost during the design-partner phase. 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, a published case (if you are willing), and a paid commercial relationship at the end of the pilot if it works for both sides.
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.
No cost during the design-partner phase. 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; that is in development for late 2026.
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 design-partner 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.
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.
The founder is Alexander Landia. The codebase is open-source on GitHub and open for review by security researchers. The product is patent-pending in the United States. A direct introduction is the best way to evaluate the team.
The fastest path is to fill in the design-partner form, mention you read the partner brief, and you will be in conversation with the founder within a working day.
For security teams evaluating the technical posture before partner-level engagement, 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.