Loading...
A
agency
FeaturesIndustriesWhitepapersRoadmapBlogDownload
All Docs

Getting Started

  • Introduction
  • Installation
  • Quick Start
  • Supported File Types

Core Concepts

  • Zero-Knowledge Architecture
  • Document Processing
  • Knowledge Graph
  • Security Deep-dive

Features

  • Search
  • Chat
  • Sharing & Collaboration
  • Export & eDiscovery
  • Settings Guide

Support

  • FAQ
  • Troubleshooting
  • Contact
Security Deep-dive

Security Deep-dive

The Architecture of Zero-Knowledge: How to Operate on Data You Cannot See

Version: 1.0 (Public Release) Date: December 2025 Audience: CTOs, CISOs, Legal Counsel, and Privacy Architects.


1. Executive Summary: The Trust Gap

For the last decade, the software industry has operated on a model of "Managed Trust." To use modern tools—AI, semantic search, cloud collaboration—organizations have been forced to upload their unencrypted plaintext data to SaaS vendors (Microsoft, Google, OpenAI, Salesforce). You obtain utility, but you surrender sovereignty.

This creates a Trust Gap:

  • The Risk: A breach at the vendor exposes your secrets.
  • The Conflict: You cannot run AI on your most sensitive data (M&A targets, defense blueprints, legal discovery) because the contract or regulation forbids third-party access.

Agency closes this gap. It is a Zero-Knowledge Knowledge Base (ZKKB).

Agency delivers the utility of modern cloud platforms (RAG, Graph, Collaboration) without ever requiring the service provider to possess the technical ability to decrypt your data. This whitepaper explains exactly how that is achieved—from the local cryptography up to the hardware-enforced Trusted Execution Environments.


2. Glossary: The Terms We Use

Security vendors often hide behind jargon. Here is exactly what we mean when we use these terms:

  • Plaintext: Your raw data (PDFs, text, images) in a readable format.
  • Ciphertext: Your data after encryption. It looks like random noise.
  • Zero-Knowledge: A system design where the service provider (Agency) *mathematically cannot* read your data. We do not have the keys. If a government subpoenaed us for your data, we could hand over only encrypted static.
  • End-to-End Encryption (E2EE): Encryption happens on *your* device before data touches the network. It is only decrypted on the recipient's device.
  • CEK (Content Encryption Key): A unique key generated for every single file.
  • TEE (Trusted Execution Environment): A secure area of a main processor (CPU). It guarantees that code and data loaded inside are protected with respect to confidentiality and integrity. Even the cloud provider (AWS/Azure) cannot peek inside a TEE.
  • Attestation: A cryptographic "ID check" where a TEE proves to your local computer that it is running the exact, untampered code you expect before you send it any secrets.

3. The Core Philosophy: "The Server is Untrusted"

Most SaaS architectures assume the server is the "source of truth" and the "safe haven." Agency assumes the server is compromised.

We treat the cloud (including our own APIs and storage buckets) as a publicly accessible bulletin board. We assume that anyone could potentially read what is written there. Therefore, nothing is ever written to the cloud unless it is already encrypted with keys that the cloud does not possess.

The Trust Boundaries

  1. The Green Zone (Trusted):
  2. Your Device (Laptop/Desktop).
  3. Your RAM.
  4. Your Local Agency App.
  5. *Result:* Plaintext exists here. Search and AI happen here.
  1. The Yellow Zone (Verifiably Trusted):
  2. Your TEE (if you use cloud offloading).
  3. *Result:* Plaintext exists here momentarily, only after the hardware proves its integrity to your local device.
  1. The Red Zone (Untrusted):
  2. Agency’s Cloud API.
  3. Cloud Storage (S3, R2, etc.).
  4. The Internet.
  5. *Result:* Only Ciphertext exists here. No keys. No filenames. No plaintext.

4. Cryptographic Architecture

We do not invent cryptography; we use proven, modern primitives standard in high-security environments (libsodium).

A. The Cipher: XChaCha20-Poly1305

We use XChaCha20-Poly1305 for symmetric encryption of files and data.

  • Why not AES? AES-GCM requires careful handling of "nonces" (numbers used once). If a nonce repeats, encryption breaks. In distributed systems (offline laptops syncing data), nonce coordination is hard.
  • The Solution: XChaCha20 uses a 192-bit random nonce. The statistical probability of a collision is effectively zero. This makes it safer for decentralized, offline-first environments.

B. Key Derivation: Argon2id

To turn your password into a master encryption key, we use Argon2id.

  • The Defense: It is "memory-hard," meaning it forces a computer to use significant RAM to calculate the hash. This makes it prohibitively expensive for attackers to use GPU farms to brute-force your password.

C. Key Exchange: X25519 (ECDH)

When you share a file with a colleague, or connect to a TEE, we use Elliptic Curve Diffie-Hellman (ECDH) on the X25519 curve.

  • The Result: Two parties (Alice and Bob) can generate a shared secret key over an open, insecure network without anyone in the middle (Agency) knowing what that key is.

D. Filenames and Metadata

  • Filenames are encrypted and hex-encoded before any sync.
  • Each file and folder has a unique Content Encryption Key (CEK); CEKs are wrapped for teams/users/shares, never stored in plaintext.

5. The Key Hierarchy: Nested Protection

If you encrypt 1TB of data with one password, and you want to change that password, you have to re-encrypt 1TB of data. That is inefficient. Agency uses a Key Wrapping Architecture.

Think of it like nested safety deposit boxes:

  1. The Document (File): Encrypted with a unique Content Encryption Key (CEK).
  2. The Team Box: The CEK is put inside a digital box and locked with the Team Key.
  3. The User Box: The Team Key is put inside a box and locked with the User's Public Key.

When you access a file:

  1. Your Master Password unlocks your Private Key.
  2. Your Private Key unlocks the Team Key.
  3. The Team Key unlocks the CEK.
  4. The CEK decrypts the file.

Security Benefit: We can add/remove users or rotate passwords just by re-encrypting the *keys* (tiny text strings), never the massive files. The cloud sees only the locked boxes, never the keys inside.


6. How We Do The Impossible: Search & AI without Decryption

The most common question we receive: *"If you can't see my data, how do you search it or run AI on it?"*

We employ two strategies depending on your scale.

Strategy A: The Local Engine (Small/Medium Teams)

  • How it works: Agency bundles a vector database (Qdrant) and a Knowledge Graph (Neo4j) *inside* the desktop application.
  • The Workflow:
  • You drag a PDF into Agency.
  • Your CPU extracts the text and generates embeddings (mathematical representations of meaning).
  • These embeddings are stored in a local database on your hard drive.
  • When you search "Project Alpha," your local computer queries your local database.
  • No data leaves your machine.

Strategy B: The Confidential Cloud (Enterprise Scale)

  • The Problem: A 4TB legal discovery dataset won't fit on a laptop.
  • The Solution: We use Trusted Execution Environments (TEEs) like AWS Nitro Enclaves or Azure Confidential Computing.
  • The Workflow:
  • Agency provisions a "Blind Box" server (TEE) in the cloud.
  • Attestation: Your local app challenges the server: *"Prove you are running official Agency code and nothing else."*
  • The server responds with a cryptographic signature signed by the hardware manufacturer (AMD/Intel/AWS).
  • Once verified, your local app opens an encrypted tunnel (ECDH) directly to the TEE.
  • Your app sends the encryption keys to the TEE memory.
  • The TEE pulls your encrypted files from storage, decrypts them in RAM (never on disk), indexes them, and sends the index back to you (or stores it encrypted).
  • The Cloud Provider sees only encrypted RAM.

7. Operational Security & Chain of Custody

Security is not just encryption; it is auditability.

The Immutable Audit Log

Every action in Agency (View, Edit, Export, Share, Search) generates a cryptographic log entry.

  • Tamper-Proof: These logs are chained (the hash of event B includes the hash of event A). You cannot delete an entry from the middle without breaking the chain.
  • Zero-Knowledge Logging: The logs describe *who* did something and *when*, but the *what* (filename, search query) is encrypted. Only the organization's Compliance Officer (holding the proper keys) can decrypt the full audit trail.

Supply Chain Security

  • Signed Binaries: All Agency desktop apps are code-signed (Apple Notarization / Windows Authenticode).
  • Deterministic Builds (Future): We are moving toward reproducible builds, allowing independent auditors to verify that the binary you download exactly matches the open-source code.

8. Practical User Actions

  • Use a password manager for your vault passphrase; there is no recovery path.
  • Keep offline backups of vault data if you remain local-only.
  • Remove departed users promptly to re-wrap team keys and shares.
  • Set expirations and allowed emails/domains on share links; revoke when done.
  • In Compliance Mode, document who holds escrow access and why.

9. Quick Security Posture Checklist

  • Confirm cloud is disabled for air-gapped use; otherwise choose App-Managed vs BYOS intentionally.
  • Ensure disk encryption and OS updates are enabled on the device running Agency.
  • Verify TEE attestation succeeds before offloading large datasets (the app enforces this).
  • Review audit log preferences to match privacy vs compliance needs; export regularly for oversight.
  • Validate backups and recovery drills before large migrations or upgrades.

10. Compliance & Governance

Privacy Mode vs. Compliance Mode

Agency acknowledges the tension between Employee Privacy and Corporate Oversight.

  1. Privacy Mode (Default):
  2. Admins cannot see user files.
  3. Team keys are not shared with Admins automatically.
  4. *Best for: Journalism, Partnerships, Private Wealth.*
  1. Compliance Mode (Managed):
  2. An "Escrow Key" is generated for the Organization.
  3. This key can decrypt all Team Keys.
  4. *Best for: Financial Services, Defense, Legal Discovery.*
  5. *Note:* Even in Compliance Mode, Agency (the vendor) still cannot see the data. Only the customer's Org Admin can.

Data Residency (BYOS)

Agency supports Bring Your Own Storage (BYOS).

  • You configure Agency to use *your* AWS S3 bucket, *your* Azure Blob, or *your* MinIO server.
  • Sovereignty: You own the ciphertext. If you stop paying Agency, you keep your encrypted data. You hold the keys. You are not locked in.

11. Conclusion

Agency is built on a singular premise: Trust Math, Not Companies.

In an era of supply chain attacks, cloud leaks, and AI surveillance, the only safe data is data that the vendor cannot read. By combining local-first architecture with advanced cryptography and confidential computing, Agency provides the only platform capable of handling high-consequence knowledge—Legal, M&A, Defense, R&D—without compromise.

Your data. Your keys. Your intelligence.

PreviousKnowledge GraphNextSearch

On this page

1. Executive Summary: The Trust Gap2. Glossary: The Terms We Use3. The Core Philosophy: "The Server is Untrusted"The Trust Boundaries4. Cryptographic ArchitectureA. The Cipher: XChaCha20-Poly1305B. Key Derivation: Argon2idC. Key Exchange: X25519 (ECDH)D. Filenames and Metadata5. The Key Hierarchy: Nested Protection6. How We Do The Impossible: Search & AI without DecryptionStrategy A: The Local Engine (Small/Medium Teams)Strategy B: The Confidential Cloud (Enterprise Scale)7. Operational Security & Chain of CustodyThe Immutable Audit LogSupply Chain Security8. Practical User Actions9. Quick Security Posture Checklist10. Compliance & GovernancePrivacy Mode vs. Compliance ModeData Residency (BYOS)11. Conclusion
A
agency

Your private knowledge base

Product

  • Features
  • Industries
  • Roadmap
  • Download

Documentation

  • Getting Started
  • Core Concepts
  • Features
  • FAQ & Support

Company

  • Blog
  • Whitepapers
  • Privacy
  • Terms

© 2026 Agency. All rights reserved. Built with privacy in mind.