Announcing IronPrivacyGuard: privacy tools built for AI agents

An AI agent preparing an encrypted file needs more than an encryption command. It needs to know which identity it is trusting, what the operation will write, which policy applies, and what a failure means.

Today we are announcing IronPrivacyGuard: an agent-first privacy tool written in Rust and built on IronCrypto. Its command is ipg. It brings identity generation, file encryption and decryption, signatures, and key lifecycle management into an interface designed for software that can discover and reason about its tools.

Every operation has machine-readable contracts, JSON Schema, and a JSON-LD ontology. An embedded cryptography knowledgebase connects applications to the tools and constraints that serve them.

Version 0.1.2 is an experimental pre-1.0 release. IronPrivacyGuard has not received an independent cryptographic audit. Its native protocol needs independent review before high-value production use.

Privacy workflows with an explicit contract

Command-line tools often communicate their behavior through help text and conventions. IronPrivacyGuard also exposes that behavior as structured data: accepted inputs, output shapes, effects, limits, safety constraints, and retry guidance.

The current CLI exposes 54 operations through direct commands, structured JSON calls, a persistent newline-delimited JSON protocol, and MCP over standard input and output. Commands keep their control channel machine-readable, with JSON responses instead of interactive prompts or terminal decoration.

ipg discover
ipg schema
ipg ontology
ipg knowledge search --query "confidential file"

The offline knowledgebase covers 17 applications and twelve primitives. It can connect a confidential-file workflow to encryption tools, identify prerequisites for hardware custody, or explain that an application requires an external component. Its search uses keyword matching; it does not call a model or authorize an operation.

That supports a deliberate sequence: discover capabilities, find the relevant application, inspect the contract, validate the request, review the plan, then execute.

Validation and planning before execution

IronPrivacyGuard provides request preflight without opening the candidate's files or executing it:

ipg request validate --request '{"operation":"hash","input":"message.bin"}'

The response includes a validation result and JSON Pointer diagnostics. Callers must inspect result.validation.valid: a successful validation command can still report an invalid candidate request.

Planning describes effects and constraints without reading secrets. It does not authenticate a key, reserve an output path, authorize execution, or guarantee that a later operation will succeed. Artifact inspection likewise distinguishes valid structure from verified authenticity.

Those distinctions give an orchestrator useful decision points before it grants access to sensitive material.

File protection, from individual documents to backups

The native workflow starts with a protected identity, an exported public key, and a fingerprint established through a trusted channel. Encryption and signature verification use an expected fingerprint so the caller explicitly selects the identity it intends to trust.

Existing output paths are never replaced, and there is no force-overwrite flag. Private keys and passphrases are not returned in JSON responses. Decryption publishes plaintext only after successful authentication.

For large files and multiple recipients, streaming encryption supports up to 64 recipients and authenticated 64 KiB chunks. Decryption writes to a temporary file and publishes the result only after the final chunk authenticates. A truncated or altered stream does not become a completed output file.

Separate streaming signatures support any-size files with bounded memory. Encryption alone does not authenticate the sender; signatures provide the separate authenticity workflow.

Trust that the caller can inspect and pin

IronPrivacyGuard represents native trust policy through immutable snapshots. Each update creates a new file and returns a digest. The orchestrator retains the selected digest in trusted configuration and supplies it with the policy it wants enforced.

Snapshots can carry signed revocation and validity information. Governed encryption, signing, and verification enforce the supplied policy, and a missing, corrupt, or mismatched requested snapshot fails the operation. Successful governed operations report the policy digest they used.

The caller remains responsible for selecting the current snapshot. A matching digest proves which snapshot was selected; it does not prove that the snapshot is the latest one. Omitting policy means no trust-store enforcement.

For MCP deployments, the host can restrict the available tools and pin a mandatory trust policy at startup. This lets the host enforce its selected policy even when a tool call omits one. Decryption remains available for historical data.

Software keys, hardware custody, and hybrid identities

The core supports passphrase-protected software identities. Optional integrations extend key custody to PKCS#11 tokens and hardware security modules, TPM 2.0, and AWS KMS. These integrations require their corresponding Cargo features and provider configuration.

TPM support also includes key-attestation workflows. PKCS#11 token attributes are self-reported rather than attested, so the two mechanisms carry different assurance claims.

For hybrid post-quantum protection, the native hybrid identity combines ML-KEM-768 with X25519 for encryption and ML-DSA-65 with Ed25519 for composite signatures. The same file operations work with that identity suite.

Native cryptographic primitives come from IronCrypto. Optional integrations have distinct dependencies: Linux TPM support links system TPM libraries, and OpenPGP interoperability uses rPGP. Those boundaries are documented in the repository.

A separate boundary for OpenPGP

Native IPG keys, encrypted envelopes, and signatures use IPG formats. They are not OpenPGP artifacts, and IronPrivacyGuard is not a drop-in GPG replacement.

The optional OpenPGP feature provides a separate interoperability path for exchanging encrypted files and signatures with GnuPG. It uses pinned OpenPGP certificate fingerprints and its own certificate policy; native IPG trust snapshots do not govern those certificates.

The repository documents a known timing advisory in rPGP's transitive RSA dependency. IPG rejects RSA secret-key imports and uses RSA only for public-key operations. Read the OpenPGP guide for the supported formats, policy, and security boundaries.

Start with discovery

With Rust 1.88 or later and Cargo installed, install the core CLI and inspect its contracts:

cargo install ipg --version 0.1.2 --locked
ipg discover
ipg knowledge
ipg schema

For an MCP client, the entry point is ipg mcp. Review the documented host controls and choose tool permissions, key custody, and trust policy for the intended workflow before giving an agent access.

The project includes independent format vectors, interoperability checks, security regression tests, and fuzzing targets. These provide engineering evidence, while independent cryptographic review remains outstanding. IronPrivacyGuard is not a FIPS-validated cryptographic module.

IronPrivacyGuard is available under AGPL-3.0-or-later with a commercial licensing option. See the repository's license files for terms.

We are building privacy tooling whose behavior an agent can inspect before it acts: which operation fits, what it will touch, which identity it trusts, and which policy it will enforce.

Explore IronPrivacyGuard on GitHub, read the security model, and try the discovery interface.