Cryptographic Information Barriers for Autonomous AI Agents

Abstract

As autonomous AI agents proliferate in enterprise environments, the security model governing their access to sensitive data and systems has not kept pace. The dominant pattern — long-lived API credentials stored alongside the agent on a cloud server — creates a single point of compromise. MahaGuardian is a cryptographic information-barrier platform that separates where authority over AI agents is defined from where it is enforced. The owner retains sole cryptographic control over what agents are permitted to do. The always-on cloud infrastructure can only operate within pre-authorized bounds.

1. The Problem

1.1 AI agents need credentials

An AI agent deployed to manage customer relationships needs access to a CRM. An agent drafting emails needs access to a mail service. An agent analyzing financial data needs database read permissions. In every case, the agent requires credentials to do its work.

1.2 The current model is fragile

In the dominant deployment model, credentials are stored on the same cloud server that runs the agent. A single compromise exposes everything. The enforcement layer can grant new permissions. There is typically no mechanism for the owner to independently verify what the enforcement layer did while the owner was not watching.

1.3 Information barriers between agents

When multiple agents operate within the same organization — one handling client A's data, another handling client B's — the information barrier between them is typically enforced by policy, not by architecture. A misconfigured permission, a shared credential store, or a compromised orchestration layer can leak data between partitions. In regulated industries, this is a compliance failure.

2. Design Principles

Separate authority definition from enforcement. The party that defines what agents are allowed to do is architecturally distinct from the party that carries out those instructions. Compromising the cloud does not grant the ability to define new authority.

Cryptographic enforcement. Permissions are enforced through cryptographic signatures, not through access-control lists or configuration files that can be edited by a compromised system.

Short-lived, scoped credentials. Agents receive credentials that are both time-limited and scope-limited. Credential lifetimes are short enough that compromise of a single credential has bounded impact.

Tamper-evident audit. Every credential issuance and agent action is logged in a tamper-evident audit trail that the system owner can verify after the fact.

3. Current Implementation

MahaGuardian V1 is a functional Guardian Daemon running on the system owner's device, managing credentials, rules, and audit for isolated AI agent deployments.

3.1 Credential vault

Agent credentials are stored in an encrypted vault using age encryption. The age identity key is wrapped with an AES-256-GCM key derived from the owner's passphrase via scrypt. Salt and nonce from os.urandom.

3.2 Agent rules

Agent rules are defined in a TOML file signed with ed25519. The Guardian verifies the signature before loading any rules. A hash ledger tracks the integrity of all signed artifacts and is itself signed.

3.3 Audit log

An append-only SQLite audit log records every event. Each entry includes a SHA-256 hash of the previous entry, forming a hash chain. The SQLite authorizer blocks UPDATE and DELETE operations.

3.4 Agent deployment

Agents run on isolated cloud droplets connected to the Guardian via mutual TLS. Each agent receives short-lived, scoped tokens held in memory only. Agents are partition-blind: they cannot discover other agents' credentials or data.

3.5 Test coverage

970 passing tests covering credential operations, signature verification, hash-chain integrity, access-control enforcement, deployment workflows, and input sanitization.

4. Known Limitations

• mlock protects raw buffers but CPython's string interning and GC mean parsed credential values may exist in copies.
• Audit log tail truncation is not hash-chain-detectable; entry-count verification is separate.
• Guardian must be online for agents to receive new credentials.
• Device loss is total compromise in V1 (no multi-device recovery).
• No external anchor on the audit log in V1.

5. Direction

MahaGuardian's architecture is designed to evolve toward stronger separation between credential management, agent execution, and audit verification. Future versions will extend the cryptographic guarantees of the current Guardian Daemon into production cloud deployments with independent audit verification.

This future architecture is under development. Details will be published as the implementation matures and relevant intellectual property protections are in place.

6. Technology Stack

7. Getting Started

See the repository for full setup and configuration.

References