Zero-Knowledge Intent Signatures

The Core Principle

When a user triggers an AI action in your app, the system needs to answer two questions:

Who is making this request? (identity)
What are they trying to do? (intent)

Traditionally, answering these questions requires sending user data — name, email, session data — to a third-party service. Aether Citadel never does this. Instead, we operate on semantic signatures — mathematical fingerprints of what a user intends, with zero personally identifiable information.

How It Works

User Data (PII)              AetherDB                    Citadel
     │                           │                           │
     │   "What does this         │                           │
     │    user intend?"          │                           │
     ├──────────────────────────►│                           │
     │                           │  AI analysis produces:    │
     │                           │  tags: ["commerce",       │
     │                           │         "south-india"]    │
     │                           │  intent_class: "commerce" │
     │                           │  (no PII)                 │
     │                           │                           │
     │                           ├──────────────────────────►│
     │                           │  PersonaContext           │  Hash of semantic
     │                           │  (no PII)                 │  context produced
     │                           │                           │  ← SHA-256 UIS
     │                           │◄──────────────────────────│
     │                           │  intent_hash              │

The PII boundary is enforced architecturally — raw user data never reaches Citadel. It stays inside AetherDB behind row-level security.

User Intent Signature (UIS)

A UIS is a SHA-256 hash computed from:

Semantic tags — behavioural keywords (e.g. commerce, cloud-infra, wellness)
Intent class — one of: commerce, infrastructure, wellness, finance, education, social, other
TTL — expiry window for replay attack prevention

UIS = SHA-256(tags || intent_class || ttl || timestamp)

The hash is deterministic for the same context but reveals nothing about the user who generated it.

What Gets Stored

Data	Stored?	Where
User name / email	❌ Never	—
User ID	❌ Never	—
IP address	❌ Never	—
Semantic tags	✅ In-flight only	Memory, not disk
Intent hash	✅ In-flight only	Verified and discarded
Shield verdict	✅	Audit log (anonymised)

Compliance Implications

Because no PII crosses the boundary:

GDPR — no personal data processed by Citadel → no DPA needed
India DPDP Act — no “personal data” as defined in Section 2(t) touches Citadel
HIPAA — no PHI transmitted → Citadel can be used in healthcare AI pipelines
SOC 2 — audit trail on every verification without storing user identity

PII Guard

Before any context leaves AetherDB to Citadel, a PII guard runs on every tag:

fn looks_like_pii(tag: &str) -> bool {
    tag.contains('@')                                 // email addresses
    || tag.chars().filter(|c| c.is_numeric()).count() > 6  // phone numbers / IDs
    || tag.len() > 64                                // suspiciously long strings
}

Tags that match are silently dropped. The verification still succeeds with clean tags.

Getting Started

Core Concepts

Changelog

Zero-Knowledge Intent Signatures

The Core Principle

How It Works

User Intent Signature (UIS)

What Gets Stored

Compliance Implications

PII Guard

​The Core Principle

​How It Works

​User Intent Signature (UIS)

​What Gets Stored

​Compliance Implications

​PII Guard

The Core Principle

How It Works

User Intent Signature (UIS)

What Gets Stored

Compliance Implications

PII Guard