Skip to content

Commit dcddc77

Browse files
ramkri123ramkri123
committed
docs: Replace infrastructure-sovereignty.md with auditor-privacy-preserving-geolocation.md
- DELETED: infrastructure-sovereignty.md (redundant with unified identity doc) - NEW: auditor-privacy-preserving-geolocation.md - Section 2: PET comparison (TEE, FHE, MPC, DP vs ZKP) - Explains why ZKP is optimal for geolocation compliance - Multi-sensor fusion architecture - SVID geolocation claims - Evidence Bundle for auditors - Updated cross-references in README.md and AI governance doc - Builds on unified identity framework instead of duplicating
1 parent 852d9c2 commit dcddc77

File tree

4 files changed

+297
-163
lines changed

4 files changed

+297
-163
lines changed

‎README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -137,7 +137,7 @@ AegisSovereignAI is designed to be framework-agnostic, serving as a secure execu
137137
## Technical & Auditor Resources
138138

139139
* **[Auditor Guide](./docs/auditor.md)** - High-level overview of the attestation-linked evidence model covering the full AI lifecycle (Ingestion, Training, and Inference), verifiable geofencing (Reg-K), and identity binding. Includes the complete Evidence Bundle structure for regulatory reporting.
140-
* **[Infrastructure Sovereignty (Layer 1/2)](./docs/infrastructure-sovereignty.md)** - Technical deep-dive on **Environmental Trust**: Hardware attestation (TEE/TPM), identity binding (SPIFFE/SPIRE + Keylime), privacy-preserving geofencing (Reg-K), and data ingestion provenance.
140+
* **[Privacy-Preserving Geolocation (Layer 2)](./docs/auditor-privacy-preserving-geolocation.md)** - Technical deep-dive on **privacy-preserving geofencing** for Reg-K/GDPR compliance, including ZKP vs. other PETs comparison, multi-sensor fusion, and SVID geolocation claims.
141141
* **[Privacy-Preserving AI Governance (Layer 3)](./docs/auditor-privacy-preserving-ai-governance.md)** - Technical walkthrough of the **Four-Track Layer 3 Governance Lifecycle** (Training, System Prompt, User Prompt, Output), Batch & Purge architecture, and modular Evidence Bundle verification.
142142
* **[Threat Model: Unmanaged Device Security](./hybrid-cloud-poc/THREAT-MODEL-unmanaged-device.md)** - Analysis of **Infrastructure Blind Spots** on **BYOD/Unmanaged Devices**, detailing how AegisSovereignAI prevents location spoofing via hardware-rooted sensor fusion.
143143
* **[Unified Identity Deep-Dive](./hybrid-cloud-poc/README-arch-sovereign-unified-identity.md)** - Detailed technical architecture of the SPIRE/Keylime identity fusion model.

‎docs/auditor-privacy-preserving-ai-governance.md‎

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,11 @@
11
# Layer 3: Privacy-Preserving AI Governance (The "Audit without Disclosure" Paradox)
22

3-
> **For Technical Auditors & Architects:** This document provides a deep technical walkthrough of the **Layer 3 AI Governance** model using **privacy-preserving techniques (e.g., ZKPs)** for prompt and output verification. For Layer 1/2 foundations (Hardware Trust, Identity, Location), see **[Infrastructure Sovereignty](./infrastructure-sovereignty.md)**.
3+
> **For Technical Auditors & Architects:** This document provides a deep technical walkthrough of the **Layer 3 AI Governance** model using **privacy-preserving techniques (e.g., ZKPs)** for prompt and output verification. For Layer 1/2 foundations (Hardware Trust, Identity, Location), see **[Privacy-Preserving Geolocation](./auditor-privacy-preserving-geolocation.md)**.
44
55
This document solves the **"Audit without Disclosure"** paradox: how can enterprises prove AI compliance to regulators without exposing proprietary prompts or retaining high-liability PII?
66

77
> [!IMPORTANT]
8-
> **Layer 2 Prerequisites:** All Layer 3 governance assumes a verified **Sovereign Anchor** is in place. Before proceeding with content verification, auditors must confirm the workload is running on attested hardware (Layer 1) with verified identity and location (Layer 2). See **[Infrastructure Sovereignty](./infrastructure-sovereignty.md)** for Stage 1 verification.
8+
> **Layer 2 Prerequisites:** All Layer 3 governance assumes a verified **Sovereign Anchor** is in place. Before proceeding with content verification, auditors must confirm the workload is running on attested hardware (Layer 1) with verified identity and location (Layer 2). See **[Privacy-Preserving Geolocation](./auditor-privacy-preserving-geolocation.md)** for Stage 1 verification.
99
1010
## 1. The Problem: The Prompt & Output Paradox
1111

@@ -84,7 +84,7 @@ While multiple Privacy-Enhancing Technologies (PETs) exist, **ZKP** provides the
8484
AegisSovereignAI's Layer 3 provides **cryptographic verification** across the AI governance lifecycle: **Model Training → System Prompt → User Prompt → AI Output**.
8585

8686
> [!NOTE]
87-
> **Layer 2 Content Moved:** Data Ingestion Provenance (Track A) and Geofencing verification are Layer 2 concerns. See **[Infrastructure Sovereignty](./infrastructure-sovereignty.md)** for these primitives.
87+
> **Layer 2 Content Moved:** Data Ingestion Provenance (Track A) and Geofencing verification are Layer 2 concerns. See **[Privacy-Preserving Geolocation](./auditor-privacy-preserving-geolocation.md)** for these primitives.
8888
8989
### Track A: Model Training Governance (Redaction Policy)
9090

@@ -309,7 +309,7 @@ If the ZKP circuit encounters a prompt that violates an **Exclusion Rule** (e.g.
309309

310310
> [!NOTE]
311311
> **Modular Verification:** The complete Evidence Bundle is verified in two stages:
312-
> - **Stage 1 (Layer 1/2):** "Is this a valid Aegis Sovereign Node?" See **[Infrastructure Sovereignty](./infrastructure-sovereignty.md)**
312+
> - **Stage 1 (Layer 1/2):** "Is this a valid Aegis Sovereign Node?" See **[Privacy-Preserving Geolocation](./auditor-privacy-preserving-geolocation.md)**
313313
> - **Stage 2 (This Document):** "Did this node follow the governance policy for this session?"
314314
315315
When an auditor requests **Layer 3 compliance evidence**, they receive:
@@ -447,4 +447,4 @@ A `sovereign_factory` applies the `governance.wrap_node` decorator to the LangGr
447447

448448
---
449449

450-
[Root README](../README.md) | [Auditor Guide](./auditor.md) | [Infrastructure Sovereignty (Layer 1/2)](./infrastructure-sovereignty.md) | [IETF WIMSE Draft](https://datatracker.ietf.org/doc/draft-lkspa-wimse-verifiable-geo-fence/)
450+
[Root README](../README.md) | [Auditor Guide](./auditor.md) | [Privacy-Preserving Geolocation (Layer 2)](./auditor-privacy-preserving-geolocation.md) | [IETF WIMSE Draft](https://datatracker.ietf.org/doc/draft-lkspa-wimse-verifiable-geo-fence/)

‎docs/auditor-privacy-preserving-geolocation.md‎

Lines changed: 291 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,291 @@
1+
# Privacy-Preserving Geolocation Verification for Auditors
2+
3+
> **For Technical Auditors & Architects:** This document provides a deep-dive on **privacy-preserving geolocation verification** for regulatory compliance (e.g., Reg-K, GDPR). For the underlying hardware and identity architecture, see **[Unified Identity & Trust Framework](../hybrid-cloud-poc/README-arch-sovereign-unified-identity.md)**. For Layer 3 AI governance, see **[Privacy-Preserving AI Governance](./auditor-privacy-preserving-ai-governance.md)**.
4+
5+
---
6+
7+
## 1. The Problem: The Residency vs. Privacy Deadlock
8+
9+
Regulators require **proof of data residency** (e.g., **Regulation K**), but traditional geofencing creates a fundamental conflict:
10+
11+
| Requirement | Traditional Approach | Liability / Risk |
12+
|-------------|---------------------|------------------|
13+
| **Prove Data Residency** | Log precise GPS coordinates | Creates massive PII liability under GDPR |
14+
| **Comply with GDPR** | Don't store location data | Cannot prove Reg-K compliance |
15+
| **Prevent Location Spoofing** | Rely on IP-based geofencing | Trivially bypassed with VPNs |
16+
17+
**The Deadlock:** Enterprises are forced to choose between **non-compliance with residency laws** or **privacy violation under GDPR**.
18+
19+
---
20+
21+
## 2. Privacy-Preserving Techniques: A Technical Comparison
22+
23+
Multiple Privacy-Enhancing Technologies (PETs) exist for protecting location data. Below is an analysis of why **Zero-Knowledge Proofs (ZKPs)** are optimal for geolocation compliance.
24+
25+
| Technology | How It Works | Pros | Cons for Geolocation |
26+
|------------|--------------|------|----------------------|
27+
| **Trusted Execution Environments (TEEs)** | Process location inside hardware enclaves (Intel SGX, AMD SEV) | Low overhead, real-time processing | Requires external auditor to trust the enclave; no portable proof for regulators |
28+
| **Homomorphic Encryption (FHE)** | Compute on encrypted coordinates without decryption | Strong mathematical guarantees | **1000x+ overhead** makes real-time geofencing impractical |
29+
| **Secure Multi-Party Computation (MPC)** | Distribute computation across multiple parties | No single party sees full data | Network latency; operational complexity for mobile devices |
30+
| **Differential Privacy** | Add noise to location data | Protects individual coordinates | **Cannot prove exact boundary compliance** (noise defeats precision) |
31+
| **Zero-Knowledge Proofs (ZKPs)** | Prove statement about data without revealing data | Portable proof; auditor-verifiable; no data retention | Proof generation overhead (mitigated by batching) |
32+
33+
### Why ZKP is Optimal for Geolocation Compliance
34+
35+
1. **Portable Proof:** Unlike TEEs, ZKPs produce a proof that can be verified by any auditor without trusting specific hardware.
36+
2. **Exact Compliance:** Unlike Differential Privacy, ZKPs prove the coordinate is **exactly** within the boundary—no approximations.
37+
3. **No Retained Data:** The proof is generated device-side; raw coordinates never leave the device.
38+
4. **Auditor Independence:** Regulators verify the mathematical proof, not the Enterprise's attestation claims.
39+
5. **Batching for Performance:** While individual proof generation has overhead, session-level batching amortizes costs.
40+
41+
> [!NOTE]
42+
> **AegisSovereignAI Hybrid Approach:** We combine **TEEs** (for secure real-time filtering) with **ZKPs** (for auditor-verifiable compliance proofs), achieving both performance and regulatory portability.
43+
44+
---
45+
46+
## 3. The AegisSovereignAI Solution: Hardware-Rooted Privacy-Preserving Geofencing
47+
48+
AegisSovereignAI resolves this deadlock using a **"Coordinate-in-Polygon" ZKP circuit** combined with hardware-rooted sensor fusion.
49+
50+
### The Architecture
51+
52+
```
53+
┌─────────────────────────────────────────────────────────────────────────────┐
54+
│ PRIVACY-PRESERVING GEOLOCATION FLOW │
55+
└─────────────────────────────────────────────────────────────────────────────┘
56+
57+
Device (BYOD/Managed) Aegis Verifier Auditor
58+
═══════════════════════ ══════════════ ════════
59+
60+
┌──────────────────────┐
61+
│ Hardware Sensors │
62+
│ (TPM-signed GPS + │
63+
│ CAMARA Mobile API) │
64+
└──────────┬───────────┘
65+
│
66+
▼
67+
┌──────────────────────┐
68+
│ ZKP Circuit Engine │
69+
│ (Coordinate-in- │
70+
│ Polygon Proof) │
71+
└──────────┬───────────┘
72+
│
73+
│ Private: Precise GPS coordinates
74+
│ Public: Compliance boundary polygon
75+
│
76+
▼
77+
┌──────────────────────┐ ┌─────────────────────┐
78+
│ ZKP Proof Generated │────────▶│ Verify ZKP Proof │
79+
│ (No raw GPS sent) │ │ + Hardware Quote │
80+
└──────────────────────┘ └──────────┬──────────┘
81+
│
82+
▼
83+
┌─────────────────────┐
84+
│ SVID Issued with │
85+
│ Geolocation Claim: │
86+
│ • status: COMPLIANT│
87+
│ • region: US-EAST │──────▶ Evidence
88+
│ • proof: base64... │ Bundle
89+
└─────────────────────┘
90+
91+
🔑 KEY INSIGHT: The Enterprise never sees raw GPS coordinates.
92+
The auditor receives a cryptographic proof of compliance.
93+
```
94+
95+
### The ZKP Circuit
96+
97+
```rust
98+
// Conceptual Noir Circuit for Privacy-Preserving Geofencing
99+
fn main(
100+
// PRIVATE INPUTS (Never disclosed)
101+
gps_latitude: Field, // User's precise latitude
102+
gps_longitude: Field, // User's precise longitude
103+
sensor_signature: [u8; 64], // TPM signature over coordinates
104+
105+
// PUBLIC INPUTS (Visible to auditor)
106+
compliance_polygon: [Point; N], // The "Green Zone" boundary
107+
tpm_public_key: pub Field, // For signature verification
108+
proof_timestamp: pub Field // When the proof was generated
109+
) {
110+
// 1. Verify the coordinates came from genuine hardware
111+
assert(verify_tpm_signature(
112+
sensor_signature,
113+
hash(gps_latitude, gps_longitude, proof_timestamp),
114+
tpm_public_key
115+
));
116+
117+
// 2. Verify the point is inside the compliance polygon
118+
assert(point_in_polygon(
119+
gps_latitude,
120+
gps_longitude,
121+
compliance_polygon
122+
));
123+
124+
// OUTPUT: Proof that "genuine hardware reported a location within the boundary"
125+
// WITHOUT revealing the actual coordinates
126+
}
127+
```
128+
129+
---
130+
131+
## 4. Multi-Sensor Fusion: Defeating Spoofing Attacks
132+
133+
AegisSovereignAI uses **hardware-rooted multi-sensor fusion** to prevent location spoofing. This builds on the architecture detailed in the **[Unified Identity & Trust Framework](../hybrid-cloud-poc/README-arch-sovereign-unified-identity.md)**.
134+
135+
### Sensor Hierarchy
136+
137+
| Sensor Type | Trust Level | Verification Method |
138+
|-------------|-------------|---------------------|
139+
| **CAMARA Mobile API** | Highest | MNO-verified SIM location via OIDC |
140+
| **TPM-Signed GNSS** | High | Hardware-rooted GPS signatures |
141+
| **App-Level GPS** | Low | Cross-validated against higher-trust sensors |
142+
143+
### Attack Resistance
144+
145+
| Attack Vector | Traditional Vulnerability | Aegis Defense |
146+
|---------------|---------------------------|---------------|
147+
| **VPN Spoofing** | IP-based checks fail | Hardware sensors ignore network layer |
148+
| **GPS Spoofing App** | App-level coordinates faked | TPM signature verification fails |
149+
| **Frida/API Hooking** | Runtime API interception | CAMARA API bypasses app layer entirely |
150+
| **Rooted/Jailbroken Device** | Full sensor control | Secure Enclave attestation detects compromise |
151+
152+
> **Deep-Dive:** For complete attack analysis, see **[Threat Model: Unmanaged Device Security](../hybrid-cloud-poc/THREAT-MODEL-unmanaged-device.md)**.
153+
154+
---
155+
156+
## 5. The SVID Geolocation Claims
157+
158+
When geolocation verification succeeds, the claims are embedded in the **SPIFFE Verifiable Identity Document (SVID)**:
159+
160+
```json
161+
{
162+
"svid": "spiffe://aegis.local/workload/private-wealth-advisory",
163+
"claims": {
164+
"grc.geolocation.status": "compliant",
165+
"grc.geolocation.region_id": "US-EAST-1",
166+
"grc.geolocation.proof": "base64-zkp-proof...",
167+
"grc.geolocation.timestamp": "2026-01-20T14:00:00Z",
168+
"grc.geolocation.sensor_type": "CAMARA_MNO",
169+
"grc.tpm-attestation.tier": "tier-2-byod"
170+
},
171+
"attestation_quote": "base64-tpm-quote..."
172+
}
173+
```
174+
175+
### Claim Semantics
176+
177+
| Claim | Type | Example | Description |
178+
|-------|------|---------|-------------|
179+
| `grc.geolocation.status` | enum | `compliant` | ZKP-verified geofence result |
180+
| `grc.geolocation.region_id` | string | `US-EAST-1` | Broad compliance region (Reg-K) |
181+
| `grc.geolocation.proof` | base64 | `eyJ...` | The actual ZKP proof for auditor verification |
182+
| `grc.geolocation.sensor_type` | enum | `CAMARA_MNO` | Which sensor provided the location |
183+
184+
---
185+
186+
## 6. Enterprise Use Case: Private Wealth Gen-AI Advisory
187+
188+
### Scenario (Use Case 1 - Enterprise Customer)
189+
190+
A high-net-worth client uses the **Private Wealth Gen-AI Advisory** from their personal mobile device. The bank must prove to an EU regulator that the AI inference stayed within the EEA (**Reg-K** compliance), but cannot store raw GPS data (**GDPR** violation).
191+
192+
### The Privacy-Preserving Flow
193+
194+
1. **Client opens app** on personal iPhone/Android
195+
2. **CAMARA API** verifies device location via MNO (carrier-level, not app-level)
196+
3. **ZKP circuit** generates proof: "Device is within EEA boundary"
197+
4. **SVID issued** with `grc.geolocation.status: compliant` and `grc.geolocation.region_id: EEA`
198+
5. **AI inference executes** with verified geolocation claim
199+
6. **Evidence Bundle** includes ZKP proof for auditor
200+
201+
**Result:** The bank proves Reg-K compliance without ever touching raw GPS coordinates.
202+
203+
---
204+
205+
## 7. The Evidence Bundle for Auditors
206+
207+
When an auditor requests geolocation compliance evidence:
208+
209+
```json
210+
{
211+
"bundle_type": "GEOLOCATION_COMPLIANCE",
212+
"audit_window": {
213+
"start": "2026-01-20T00:00:00Z",
214+
"end": "2026-01-20T23:59:59Z"
215+
},
216+
"compliance_boundary": {
217+
"name": "EEA_REGULATION_K",
218+
"polygon_hash": "sha256:abc123..."
219+
},
220+
"sessions": [
221+
{
222+
"session_id": "sess-001",
223+
"svid": "spiffe://aegis.local/workload/private-wealth-advisory",
224+
"geolocation_claim": {
225+
"status": "compliant",
226+
"region_id": "EEA",
227+
"sensor_type": "CAMARA_MNO",
228+
"zkp_proof": "base64-noir-proof..."
229+
},
230+
"timestamp": "2026-01-20T14:00:00Z"
231+
}
232+
],
233+
"aggregate_stats": {
234+
"total_sessions": 15847,
235+
"compliant_sessions": 15847,
236+
"non_compliant_sessions": 0
237+
},
238+
"signatures": {
239+
"aegis_geolocation_jws": "eyJhbGciOiJSUzI1NiIs..."
240+
}
241+
}
242+
```
243+
244+
### Auditor Verification Workflow
245+
246+
1. **Verify Boundary Definition:** Confirm the `polygon_hash` matches the official Reg-K boundary.
247+
2. **Verify ZKP Proofs:** For each session (or sample), verify the ZKP proof against the boundary.
248+
3. **Verify Hardware Attestation:** Confirm the session was on attested hardware via SVID.
249+
4. **Aggregate Compliance:** Confirm all sessions in the audit window are compliant.
250+
251+
---
252+
253+
## 8. Regulatory Mapping
254+
255+
| Regulatory Need | AegisSovereignAI Implementation |
256+
|-----------------|--------------------------------|
257+
| **Reg-K (Data Residency)** | ZKP proves location within boundary without storing coordinates |
258+
| **GDPR Art. 5 (Data Minimization)** | No raw GPS data ever leaves the device |
259+
| **GDPR Art. 25 (Privacy by Design)** | Hardware-rooted ZKP is privacy-first architecture |
260+
| **EU AI Act (Transparency)** | Auditor receives verifiable proof, not opaque assertions |
261+
262+
---
263+
264+
## 9. Integration with Layer 3 AI Governance
265+
266+
Geolocation verification is a **Layer 2 prerequisite** for Layer 3 AI Governance. The modular architecture:
267+
268+
```
269+
┌─────────────────────────────────────────────────────────────┐
270+
│ MODULAR EVIDENCE BUNDLE VERIFICATION │
271+
└─────────────────────────────────────────────────────────────┘
272+
273+
Stage 1: Environmental Trust (This Document)
274+
═════════════════════════════════════════════
275+
✓ Is this a genuine, untampered device?
276+
✓ Is the device within the compliance boundary?
277+
✓ Is the SVID bound to attested hardware?
278+
│
279+
▼
280+
Stage 2: Content Trust (AI Governance)
281+
═══════════════════════════════════════
282+
✓ Did the system prompt contain required guardrails?
283+
✓ Were user prompts scanned for injection attacks?
284+
✓ Were AI outputs filtered for PII leakage?
285+
286+
See: [Privacy-Preserving AI Governance](./auditor-privacy-preserving-ai-governance.md)
287+
```
288+
289+
---
290+
291+
[Root README](../README.md) | [Auditor Guide](./auditor.md) | [Unified Identity Framework](../hybrid-cloud-poc/README-arch-sovereign-unified-identity.md) | [AI Governance (Layer 3)](./auditor-privacy-preserving-ai-governance.md)

0 commit comments

Comments
 (0)