PP-MACDS — Privacy-Preserving Multi-Agent Clinical Decision Support
Agents Assemble Hackathon · Spring 2026
HIPAA compliant healthcare AI, built on SSI primitives. Clinical AI with privacy guarantees you can explain, defend, and verify.
The Problem: HIPAA wasn't built for autonomous agents
Healthcare wants AI for tumor boards, drug interaction screening, behavioral health, chronic disease — recommendations in minutes instead of days. But the compliance story today is policies, training, BAAs, and quarterly log reviews. None of those mechanically stop an agent that wasn't supposed to look. We want structural controls, not procedural ones.
Minimum Necessary Rule (45 CFR 164.502(b))
Assumes a human reviewer. Autonomous agents issue hundreds of queries per session — the rule was never designed for this scale.
Inference Attacks
Reconstruct individual patients from outputs that look "de-identified" in isolation. Multi-agent designs multiply the attack surface.
Audit Logs
Record what happened — they don't prove the system can't have rewritten its own history. Logs are evidence, not guarantees.
Consent
A checkbox in a database row, not a cryptographic contract bound to data flow. Revocation is manual, delayed, and unverifiable.
The Answer: privacy enforced by architecture, not by policy
PP-MACDS is a framework, not an oncology app. Three interlocking structural guarantees — each mathematically verifiable, each enforced mechanically — plus a signed audit record that proves they ran. First use case: oncology tumor board (radiology + pharmacy + genomics). Adding a new clinical specialty is a config change, not an architecture change.
Differential Privacy
Hard, mechanically-enforced ε budgets per agent and per session. No override path.
Capability-Based Authorization
ZCAP-LD three-level Ed25519-signed delegation chain. Broader access is cryptographically impossible.
Self-Sovereign Consent
The patient's wallet is the root of the trust chain. Capabilities are revocable in real time.
Tamper-Evident Audit
Every session produces an Ed25519-signed HIPAA record before the recommendation is delivered.
Architecture: a three-layer delegation chain
The trust chain is built bottom-up from the patient's wallet, attenuated at each step. Nothing downstream can broaden anything upstream. All proofs are Ed25519. All Agent Cards are JWS detached signatures (RFC 7515, alg=EdDSA, typ=a2a-agent-card+jws) over RFC 8785 JCS-canonicalized payloads.
Each layer can only attenuate — never amplify — the permissions it received from the layer above.
1
Patient SSI Wallet
Root capability lives with the patient. Session-scoped DIDs (fresh per evaluation) provide non-correlation. Private key never leaves the device.
2
Orchestrator
Receives delegated root capability. Builds a session capability time-bounded to the evaluation window. Drives specialist invocation order and budget.
3
Specialist Agents
Each domain agent holds its own DID and narrowed capability with an EpsilonBudgetCaveat. Structure — not policy — limits what it can call.
The Patient Consent Mediator sits live in every request path — verifying the chain and minting a narrowed SMART-on-FHIR token scoped to one resource, one code, one patient, with a short TTL.
Differential Privacy you can actually enforce
DP is the mathematical core. Calibrated noise on every query, hard caps mechanically enforced, no override path. True clinical values never escape the privacy boundary — they live only on a single function-call frame that is structurally erased before the noisy result is returned. This isn't policy — it's how the layer is shaped.
ε=17.0
Session Total Budget
Within NIST's "robust privacy protection" tier (5–20), below the 2020 U.S. Census at ε=19.6.
3
Noise Mechanisms
Bounded Laplace (continuous), randomized response (binary), k-ary RR (categorical, e.g. tumor staging).
0
Override Paths
Budget exhaustion halts the agent. There is no "just one more query" path — structurally impossible.
The privacy budget is part of the signed capability. If you can read the chain, you can verify the budget without seeing the data. Sensitivity is a compile-time constant — attackers cannot change clinical bounds at runtime.
Capability-Based Authorization: structural Minimum Necessary
ZCAP-LD chain attenuation does what policy can't: it makes broader access cryptographically impossible, not just prohibited. A radiology agent literally has no token that authorizes pharmacy actions. Compromising the agent doesn't help — the verifier downstream rejects every action outside the allowed list.
Three-Tier Chain
Patient root → session capability (time-bounded) → agent capability (action-restricted, ε-capped). Each step narrows; nothing can widen.
Per-Query Token Narrowing
The mediator issues short-TTL FHIR tokens scoped to one resource, one code, one patient. No long-lived broad token exists anywhere in the system.
Non-Repudiation
Every delegation and every invocation is Ed25519-signed. The chain is independently verifiable by any third party with no live access to the system.
Cross-Language Interop
C# orchestrator signs and Python specialists verify over RFC 8785 canonical JSON. Proof shape is W3C Data Integrity flat.
Patient-Controlled Consent: cryptographic, live, revocable
This is where the SSI primitives earn their place. Consent stops being a database flag and becomes a cryptographic contract bound to data flow — verifiable, instant, and patient-controlled.
Wallet-Held Root Capability
Issued from the patient's SSI wallet. Signed by the patient's controller key. The key never leaves the device — ever.
Session-Scoped DIDs
Each evaluation session uses a fresh, ephemeral DID. Non-correlation across sessions blocks longitudinal inference attacks — an observer can't link two encounters to the same patient.
Instant Revocation
Invalidating the root invalidates every downstream capability automatically. No propagation delay, no manual rollout, no "we'll revoke it on next deploy."
Verifiable Credential Bridge
The wallet presents a VC at session start; the mediator resolves it before any FHIR token is issued. Consent and technical enforcement unified in one cryptographic step.
What this means for compliance
Every traditional compliance claim maps to a structural, verifiable guarantee in PP-MACDS. The Breach Notification argument (45 CFR 164.400): a breach requires unauthorized access to unsecured PHI. If the only data that crosses the boundary is provably DP-noised with stated ε bounds, the organization has a formal mathematical argument that no individual patient was disclosed — even under full system compromise.
Roadmap
The framework is real, exercised, and reproducible — not a paper architecture. The path forward expands from a validated oncology MVP to a universal clinical AI infrastructure layer.
1
MVP
Using real clinician feedback to develop a useful, validated MVP grounded in oncology tumor board workflows.
2
SMART on FHIR
Develop a FHIR-compliant embedded user experience to serve the EHR market — meeting clinicians where they already work.
3
Cross-Clinical Domains
Expand from oncology to any clinical domain: behavioral health, chronic disease management, rare disease — anywhere a high-value clinical AI use case is currently blocked by HIPAA risk.
Adding a new clinical specialty is a config change, not an architecture change. The framework is designed for horizontal expansion from day one.
PP-MACDS
Clinical AI with privacy guarantees you can explain, defend, and verify.
The Opportunity
The organizations that deploy clinical AI with structural privacy guarantees will define the standard. Privacy enforced by architecture — not by policy — is the only guarantee that holds under adversarial conditions.
The Risk of Inaction
The organizations that deploy without structural guarantees will carry the liability. Policies, training, and quarterly log reviews are not a defense when an autonomous agent wasn't supposed to look — and did.
Thank you. Q&A.