GUARDIAN Framework in Federated Privacy

• GUARDIAN Framework is a rigorously formalized, two-layer architecture that ensures safety, privacy, and extensibility in federated computing environments.
• It decouples analytic intent from backend-specific protocols through a backend-neutral DSL, manifest-driven admission, and comprehensive telemetry.
• The framework features an agentic-AI safety loop with finite-state verification and immutable audit logging to maintain robust operational assurance.

The GUARDIAN Framework, in the context of federated computing, refers to a rigorously formalized, two-layer architecture for enforcing safety, privacy, and extensibility across heterogeneous privacy-preserving backends. GUARDIAN-FC is designed to unify risk management—via adaptive guard rails and formal telemetry—across cryptographic (fully homomorphic encryption [FHE], multiparty computation [MPC]) and statistical (differential privacy [DP]) mechanisms. This system achieves backend-agnostic assurance through a manifest-centric job specification, a backend-neutral domain-specific language (DSL), and a formally verified agentic AI control plane that orchestrates a finite-state safety loop and immutable auditability (Veeraragavan et al., 24 Jun 2025).

1. Architectural Separation: Data Plane and Control Plane

GUARDIAN-FC adopts a strict two-layer decomposition to decouple logical computation from privacy protocol specifics:

A. Federation Layer (“Data Plane”)

• Plug-ins: Modular units authored exclusively in a backend-neutral DSL. These specify analytic intent (e.g., federated_sum, dropout, chain_noise) independent of how privacy is enforced.
• Execution Providers (EPs): Runtime modules that implement DSL primitives for specific privacy mechanisms (FHE: CKKS noise budget, MPC: share arithmetic, DP: ε-accountant). Each EP exports a standardized set of metric keys (e.g., noiseBits, ε_spent, shareAuthFail) enabling uniform monitoring.
• Finite-State Machines (FSMs): Both each Node and the Central Aggregator execute a fixed FSM (IDLE→PREF→INF→POSTF→DONE/ABORTED), such that state transitions can be globally monitored and verified.
• Manifest-Centric Admission: Plug-in compilation yields a manifest (JSON) listing the DSL opcodes, chosen EP, enabled guard-rail predicates, and expected metrics. Static typechecks ensure only compatible jobs proceed, preventing unsupported or hazardous execution.

B. Agentic-AI Layer (“Control Plane”)

• Telemetry Collector: Aggregates signed metric frames at regular intervals from all parties, each frame encoding node state, metrics, and non-repudiable signatures.
• Sentinel & Control Engine: Stream-aligns telemetry, evaluates guard-rail predicates $p_i: M \times M \to \{\text{TRUE},\text{FALSE}\}$ over each metric/forecast pair, and triggers agentic "A-commands" (e.g., A_ABORT_JOB, A_BOOTSTRAP) in response.
• Cryptographic Orchestrator & Command Dispatcher: Enforces authenticated broadcast and wait-for-acknowledgment semantics for A-commands.
• Audit Engine: Hashes and logs all telemetry and commands using a Merkle ledger, guaranteeing tamper-evident traceability.
• Human-Override Interface: Admits signed, operator-injected commands solely via the established safety loop, preserving the closed-world safety model.

C. DSL and Backend Neutrality:

The DSL abstracts logical operators without backend-specific constructs (e.g., "federated_sum" is agnostic to encrypted/sharded/obfuscated implementation). Plug-ins are dynamically bound to EPs at runtime; backend changes require only substitute EP deployments, not code revisions.

2. Agentic-AI Safety Loop: Formal Synchronous Risk Control

At the heart of GUARDIAN-FC is a formally defined, cyclic safety control loop grounded in FSM theory. The system continuously cycles through:

• Sense: Each participant emits a signed metric snapshot $m_t$ containing state, metrics, timestamp, and signature.
• Predict: The Sentinel module forecasts next-timestep metrics and evaluates all guard-rail predicates on $(m_t, \hat{m}_{t+1})$.
• Act: Any violated predicate triggers the emission of a relevant idempotent A-command, which is then acknowledged by all participants.
• Prove: Every state, action, and acknowledgment is logged in the append-only Merkle ledger for auditability.

Predicates $p_i: M \times M \to \{\text{TRUE}, \text{FALSE}\}$ (loaded from versioned YAML at job start) formalize risks such as underflowed noise budget, excessive privacy loss, or failed MPC share authentication. Sample predicates:

• $$p_1(m, m') \equiv m.\text{noiseBits} < \theta_{\text{noise}} \implies$$ trigger A-BOOTSTRAP.
• $$p_2(m, m') \equiv m.\epsilon_{\text{spent}} > \epsilon_{\max} \implies$$ trigger A-ABORT_JOB.
• $$p_3(m, m') \equiv m.\text{shareAuthFail} > 0 \implies$$ trigger A-ISOLATE_PARTY.

Fail-fast logic rejects any telemetry or job configuration that deviates from the declared manifest/static schema at runtime, precluding latent or zombie job hazards.

3. Formal Model: Safety and Liveness Verification

GUARDIAN-FC’s safety and liveness guarantees derive from formal synchronous product modeling of the federated nodes’ FSMs. Two key invariants govern system behavior:

• Safety Invariant: If the Aggregator achieves FINALIZE, every Node must be in a "safe release" state $S_{\text{ok}}$ and all predicates must be false:

$$\mathit{Aggregator} = \mathsf{FINALIZE} \;\Longrightarrow\; \Bigl(\bigwedge_{i}\mathit{Node}_i\in S_{\mathrm{ok}}\Bigr) \;\wedge\; \Bigl(\bigwedge_{p\in P}\neg p(m,m')\Bigr)$$

• Liveness Invariant: Using a global ranking function

$$u = \sum_{i=1}^{N} \mathrm{rank}(\mathit{Node}_i) + \mathrm{rank}(\mathit{Aggregator}),$$

with decreasing rank as nodes progress, invariance $m_t$0 ensures every execution eventually terminates in a safe or aborted state.

Soundness is preserved by ensuring every FSM transition upholds the safety condition, while completeness follows via the ranking function's monotonicity.

4. Extensibility and Research Trajectory

Extensibility in GUARDIAN-FC is achieved through modular DSL/EP/manifest architecture:

• Adding New Back-Ends: Developers implement new EP libraries that export required DSL primitives and emit standard metrics. Declaration of new metrics or predicates is handled in manifest and guardrails YAML, obviating the need for changes in core logic or plug-in sources.
• Planned Directions:

1. Adaptive Guard-Rail Tuning: Integrate RL agents to dynamically adjust guard-rail thresholds, evaluated symbolically (e.g., via SMT) against established invariants, ensuring no unsafe configuration is deployed.
2. Multi-EP Composition: Formalize an $m_t$1-calculus for tracking differential privacy and cryptographic entropy across pipeline stages (FHE→MPC→DP). SMT-based refinement checks ensure resource usage bounds and policy interaction are satisfied.
3. Human-Override UX and Alert Fatigue: Empirical studies (using NASA-TLX) are needed to optimize operator intervention signal design and mitigate false positives while preserving manual override safety.
4. DSL and Compiler Development: Formal specification of DSL semantics, construction of a certified front-end, and static analyses for verifying plug-in/guard-rail/resource compatibility. Support for hot-swapping EP modules enables rapid extensibility.

5. Comparative Advantages and Backend-Agnostic Assurance

GUARDIAN-FC is distinct in providing a unifying, formally verified "one-loop" safety architecture capable of spanning both cryptographic and statistical privacy paradigms. Its decoupling of guard-rail logic from backend implementation allows seamless adoption of new privacy technologies without reengineering analytic workflows. Backend-agnostic monitoring, rigorous manifest admission, and append-only auditing collectively preclude classes of operational and security failure not addressed by prior tightly coupled systems.

A summary table of key architectural elements is presented below:

Component	Description	Formalism / Extensibility
Plug-Ins (DSL)	Backend-neutral federated workflow specification	EP-agnostic binding
Execution Providers (EPs)	Backend-specific runtime executing DSL ops and emitting metrics	Drop-in replaceable; compile-time checks
Agentic Control Plane	FSM-driven, telemetry-based predicate evaluation and command issuance	Soundness/liveness model-checked
Guard-Rail Predicates	Versioned, manifest-enforced threshold logic	Symbolic threshold tuning
Audit Engine	Merkle-hash trace of telemetry and commands	Immutable, audit-supporting

6. Limitations and Future Developments

While GUARDIAN-FC offers an extensible and formally robust framework, it currently presupposes:

• Synchronous, reliable communication for telemetry and command acks.
• Clearly defined, audit-friendly metric emission from EPs.
• Rigid manifest typechecking, which could limit expressivity for dynamic workloads.

Future research will address:

• Asynchronous failure handling, partial-participant state management, and increasing the DSL's expressivity.
• Dynamic and data-dependent guard-rail adaptation without undermining soundness.
• More sophisticated multi-backend resource composition limits and richer policy models.

7. Summary and Positioning

GUARDIAN-FC establishes a rigorous, extensible paradigm for safety governance in federated privacy-preserving analytics. By abstracting guard-rails from privacy mechanisms and enforcing backend-neutral, audit-logged control via a formally specified agentic-AI loop, it offers a practical foundation for trustworthy federated computing amidst rapid cryptographic and statistical innovation. Its manifest-driven, formally verified architecture is positioned for community adoption and future research expansion along adaptive, compositional, and usability vectors (Veeraragavan et al., 24 Jun 2025).