【Part 6】 How AI leaks data at every stage of its lifecycle — and what actually stops it

This is the final post in a series on privacy preservation for the GenAI era, and it sets out what CODAS is aiming for.

Earlier posts in this series:

【Part 1】 How AI leaks data at every stage of its lifecycle — and what actually stops it

【Part 2】 How AI leaks data at every stage of its lifecycle — and what actually stops it

【Part 3】 How AI leaks data at every stage of its lifecycle — and what actually stops it

【Part 4】 How AI leaks data at every stage of its lifecycle — and what actually stops it

【Part 5】 How AI leaks data at every stage of its lifecycle — and what actually stops it

The mature tooling is overwhelmingly confidentiality tooling and the gaps are overwhelmingly privacy gaps. Encryption, key custody, attested enclaves, signed weights, authentication and access control are solved, sold and supported, because each of them answers the question of who can read the data — a question with a clean yes-or-no answer and an obvious owner. What is missing answers the harder question of what can be learned from data somebody is already entitled to read.

There is no shortage of things a privacy-engineering program could build, and most of them already exist. Presidio extracts PII, Llama Guard and Granite Guardian classify content, Flower and NVIDIA FLARE run federated learning, Opacus does DP-SGD with ghost clipping, safetensors eliminated the pickle class of attack outright, and the three hyperscalers will sell you an attested enclave this afternoon. None of that needs rebuilding.

So, what is not solved?

Gaps

The first is the obvious one: nothing ships. The control is well established in the literature, and no team has maintained an implementation they could adopt at any price. Information-flow control for prompt injection, differentially private embeddings, memorization auditing, client attestation of a federated model, differentially private synthesis for text, contribution accounting — every one of these is a solved research problem and an unsolved engineering problem.

The second is subtler and, in practice, costs enterprises more. Something does ship, but the distance between what ships and something an ordinary team can operate is structural rather than incidental. Dive into some examples.

Differential privacy gap

Differential privacy is the only control in this series with a provable bound, and the only one that will not run until somebody picks a number. That is the configuration problem in one line. Nothing else in the stack asks an engineer to choose the strength of its own guarantee, and no enterprise convention says which number to choose — the published ones are not even measuring the same thing.

Apple applies it on the device. The phone holds the raw record — an emoji used, a word not in its dictionary — adds noise to it there, and sends only the noised version, so Apple's servers never receive the true value. Each donation — Apple's word for one such record — is noised to satisfy ε on its own: 4 for emoji and lookup hints, 8 for QuickType, 2 for health types. Apple then limits how many a device sends, one or two a day, which caps the count rather than a running total.

A note on what noised means here, because it is not what it sounds like. Apple never sends the word, or a misspelled version of it. Noise is arithmetic, so the word first has to become a number.

Take Apple's own worked example: somebody types Despacito, and the keyboard has never seen it. The device picks one short substring, say sp, and hashes the whole word to an 8-bit value — the puzzle piece, which here comes out as 97. It joins the two into the fragment sp‖97, hashes that with one randomly chosen hash function into a position in a space of size m, and builds a one-hot vector: a long row of zeros with a single 1 at that position. Every bit of the vector is then flipped independently with probability 1/(e^(ε/2) + 1), which is roughly 1.8% at ε = 8 and roughly 27% at ε = 2. What leaves the phone is that vector, a second one encoding the whole word the same way, the index of the hash function used, and where in the word the substring came from. Not one character of Despacito.

A single submission is close to useless, because the server cannot tell a real bit from a flipped one and many different words collide into the same position. Utility comes only from the sum, where flips cancel toward their expectation while real signals accumulate. The server builds a histogram of fragments for each position, uses the puzzle piece to work out which fragments came from the same word, concatenates the popular ones into candidates, and runs a second counting pass over the dictionary it has just assembled.

Different story. The Census Bureau kept the true responses and added noise only when it published. The 2020 redistricting file came out at ε = 19.61 for the whole country, 17.14 for persons and 2.47 for housing units, which are protected separately and add up. Inside each file the budget is split again, across geographic levels and then across query groups, most of it pushed down to blocks and block groups where redistricting accuracy actually matters. No formula produced 19.61. A Bureau committee set it, aiming to keep it as low as the published statistics could stand, after accuracy testing and public comment. And the system does not run on ε at all: it accounts in ρ-zCDP, at ρ = 2.63 in production, and 19.61 is a conversion at δ = 10⁻¹⁰ that the Bureau says is not the tightest available. So 19.61 is a translated figure, chosen by a committee, in units the system does not natively use — not the kind of number that compares cleanly with Apple's 4. (A post on differential privacy frameworks is coming.)

Published fine-tuning work sits in the same band. Yu et al. report RoBERTa-Large on MNLI at ε = 6.7, reaching 87.8% against 90.2% non-private, and GPT-2 on DART at ε = 6.8, reaching 38.5 to 43.8 BLEU against 48.1.

On Gboard, Google's keyboard app on Android and iOS, Google trains its next-word-prediction language models with federated learning plus DP-FTRL and reports them in ρ-zCDP: ρ = 1.31 for US English, improving to ρ = 0.25 once secure aggregation is layered on, with the published range across models running 0.2 to 2. Google states that all next-word-prediction neural models in Gboard now carry differential-privacy guarantees, and it never quotes ε at all.

As the values above show, they differ by an order of magnitude and sit on different scales.

The number is the easier half. Differential privacy protects a unit, and you define the unit: make it a sentence, and a customer appearing in 500 documents gets nothing like the protection ε advertises. Sentence-level differential privacy at ε = 8 still leaked about 3% of PII sequences in measurement. Multi-party training is worse, since participants' data is not identically distributed — Apple's federated speech-recognition work reports a word-error-rate penalty of 1.3% at high population scale under ε = 7.2 against 4.6% at low population scale under ε = 4.5 — the smaller population paying more, though at a tighter budget as well.

The tooling does not rescue the decision. Every library demands the number and almost none of them suggests one. Opacus makes the target ε a required argument and its FAQ offers only "a small constant"; dp-transformers, unreleased since 2022 and marked in its own README as not for deployment, tells you to start the batch size at the square root of the dataset size and the clipping norm at 0.1, then says nothing about the parameter that defines the guarantee. The parameter δ gets a formula, roughly one over the number of training records; ε gets the adjective "small" and no formula at all. Where a default does exist, it decides quietly on your behalf. A diffprivlib model instantiated with no arguments trains at ε = 1.0, and the budget accountant, the component whose job is to cap total spend, defaults to an infinite ceiling. SmartNoise SQL charges ε = 1.0 per computed statistic and states that the cost accrues indefinitely as queries run. Nor do the tools argue with a loose value. Opacus raises an error when the budget is too small and accepts ε = 500 in silence. NIST's guide to evaluating these guarantees is explicit that it offers no specific guidelines on selection, and calls the choice an open question. It is this kind of situation that led Dwork, Kohli and Mulligan to write, in "Expose Your Epsilons!" in 2019, that "when not meaningfully implemented, differential privacy delivers privacy mostly in name." A compliance officer asking what guarantee the company actually shipped has nowhere to look it up.

Data clean room gap

Clean rooms for analytics are a mature category. Clean rooms for machine learning are a younger and much narrower one, and the distance shows as soon as the workload stops being a SQL aggregate.

On AWS Clean Rooms ML, the data stays in your own S3 bucket cataloged in AWS Glue, exposed as a configured table carrying an analysis rule, in Parquet, CSV or JSON, in the same Region as the other Clean Rooms ML resources. Training data is then loaded by query. An ML input channel is, in AWS's words, "the result of a query that can be used for ML modeling": you submit the SQL as protected query parameters against tables whose analysis rule permits the model to run, and the result is materialized inside the service as CSV or Parquet, where it is "never shared with any member." Retention of that materialized copy is explicit and short — retentionInDays is a required parameter with a maximum of 30. Training reads the copy. The first of the two modes is lookalike modeling, which runs what AWS calls an AWS-authored model — a deep neural network over user-item interaction data, wanting a user ID, an item ID and a timestamp, at least 100,000 users with two item interactions each and a million records, with up to ten additional categorical or numerical features; what comes out is a segment of at least 10,000 users, and the model itself never leaves. The second is custom modeling, which takes your own container from Amazon ECR built on a SageMaker training base image, mounts the channel at /opt/ml/input/data/ and collects the trained model from /opt/ml/model.

Snowflake also leaves the data in place, shared logically into the clean room with nothing transformed on the way in. Its loading step is a template rather than a channel. An ML job runs only through a template the data owner approves, and since "ML Jobs scripts can't reference cleanroom.source_table_0 directly," the tables a script may read arrive as arguments to that approved procedure. Code and artifacts sit on a stage that "must have a directory enabled and use Snowflake-managed encryption," and the collaborator "validates the code and artifacts using hashes to ensure compliance," with human review, where it happens, done offline. Training then runs in an isolated container on a compute pool, which is what lets collaborators train "on combined data without exposing raw user-level data to any party." Observability is itself a governed setting: log retrieval is gated by ALLOW_ML_JOBS_MONITORING, which "only the collaboration owner can change."

On Databricks, assets are shared read-only into a central room where "collaborators cannot see the data in other collaborators' tables, views, or volumes" — though column names and types are visible to everyone — and they stay shared for the life of the room. A notebook reads those tables directly on Databricks-managed serverless compute, so the gate sits before execution: "this trust is enforced explicitly by requiring all collaborators to approve a notebook before it can be run," only the most recent version of a notebook is runnable, and running a notebook someone else added counts as approving it. What comes out is read-only temporary tables written into a collaborator's Unity Catalog metastore, and outbound connections can be restricted on the serverless plane.

Google's Ads Data Hub inverts the pattern, because the query is the training. First-party data is loaded into BigQuery and joined against Google's advertising logs, and the only model types are ADH_LINEAR_REGRESSION and ADH_LOGISTIC_REGRESSION. The shape of the training table is a precondition rather than a convention: each row must represent one unique user, no user may appear in two rows, no feature may derive from user_id, and "for privacy reasons, only the options described in the syntax section are usable."

So the protection lands in four different places. None of the four products applies anything at insertion; data is cataloged or shared as it stands. AWS and Snowflake protect the loading step. On AWS, the data owner attaches an analysis rule to each table, which sets out what a query is allowed to do with it; the query behind an ML input channel must be one those rules permit, and its result is held inside the service instead of being returned, so no member ever sees the training set it produced. On Snowflake, the owner approves the template, and the template is what names the tables a script may read. Both then protect custody during training rather than the training computation. Databricks protects the code before it runs. Only Ads Data Hub reaches inside training: "linear and logistic regression both use differential privacy," which works by "injecting noise into your results during the training process," against a budget of 10.0 per data day and a per-model epsilon that must stay below ln(3), defaulting to about a tenth of that, which permits roughly a hundred models a day. Its results are checked again on the way out, with aggregation requirements of roughly 20, 50 or 10 unique users per result row depending on the mode, and a filtered-row summary to account for what was dropped.

Elsewhere the privacy accounting does not follow the model, and there is a structural reason it cannot. Differential privacy forbids the row-level output that training consumes. Snowflake blocks row-level queries like SELECT * against a privacy-protected table, and AWS permits row-level data only inside common table expressions, with the final SELECT supporting aggregations alone — AVG, COUNT, COUNT DISTINCT, STDDEV and SUM. An aggregate is not a training set, so on both platforms a differentially private table and a model trained on its rows are mutually exclusive. AWS's differential privacy is accordingly a SQL feature, configured as a custom analysis rule over S3-backed Glue tables, and no AWS page applies it to the ML path; what governs ML output instead is a set of export-size caps, log-redaction rules and a container-metric noise setting of None, Low, Medium or High. Nor does anything on these ML paths inspect the columns. AWS asks the provider for an identifier that "should be a non-Personally Identifiable Information (PII) value" and types the remaining features as categorical or numerical without classifying them, so whether a feature column carries personal data is the provider's design decision, enforced only as a declaration.

Everything above is tabular. AWS's lookalike schema is a user, an item, a timestamp and ten typed features, and its custom path reads a CSV or Parquet query result; Ads Data Hub wants one BigQuery row per user; Snowflake and Databricks pass tables. No product documents unstructured text, images or precomputed embeddings as a first-class ML input, which means a corpus of documents, transcripts or support tickets — the raw material of an enterprise GenAI system — has no governed channel into a clean room at all. Nor does any provider's documentation describe fine-tuning a language model on joined multi-party data, or retrieval, embeddings or vector search inside the boundary.

The threat model is the deepest difference, and it is a reasonable one for the job these products were built to do. Their controls — aggregation thresholds, minimum segment sizes, mitigations against membership inference — are the right controls against audience leakage. Memorization and training-data extraction from a generative model appear in none of their documented threat models. Nor could you easily watch for them: the instruments of ordinary model work are exactly what the privacy boundary suppresses.

Inference guardrails gap

Guardrails understand privacy as pattern matching, and the published numbers show how far that gets.

Start with the detector most deployments start with. On the Text Anonymization Benchmark, Presidio in its default configuration recovers 0.460 of direct identifiers and 0.758 of quasi-identifiers at the entity level. On 200 UK neurosurgical notes it scored 0.51 precision and 0.74 recall against 1,449 manually marked PHI instances. Both are uncustomized runs on out-of-domain prose, and Presidio is a framework meant to be tuned to a domain, so read those as a floor rather than a ceiling — but the floor is where most deployments sit, and Presidio's own FAQ says plainly that there is no guarantee it will find all sensitive information.

Injection detectors look strong on their own benchmarks and much weaker under adaptive attack. Meta reports Prompt Guard 2 at 97.5% recall at a 1% false-positive rate, and in the LlamaFirewall paper it takes AgentDojo attack success from 17.6% to 7.5%. Then an evaluation of evasion techniques against six shipping detectors found one technique, emoji smuggling, reaching a 100% attack success rate against every system it was tested on. NVIDIA publishes the unflattering numbers for its own heuristics, which is to its credit: length-per-perplexity detects 31.19% of jailbreaks at a 7.44% false-positive rate, works on English only, and fails open if the detector cannot be reached. An independent evaluation of 28 systems from 17 providers put content moderation at roughly 95% detection below a 2% false-positive rate, and the specialized guardrails among them at 43.1% median detection on ASCII-art obfuscation and 40.3% on prompt injection.

None of that is the privacy problem, though. The privacy problem is what a model works out about a person from text containing no identifiers at all. GPT-4 infers personal attributes from public Reddit prose at 85.5% top-1 accuracy across eight attributes, and passing that text through a commercial entity-based anonymizer first still leaves it inferring at between 43.9% and 64.2%. Redaction removes the spans without removing the signal, and no shipping guardrail scores that risk.

Nor does any of them reason about what a response discloses. The ConfAIde benchmark measures contextual-integrity violations and finds GPT-4 revealing information in situations where people would not 39% of the time, and ChatGPT 57%. Sensitive-information filters match entities in the output; none asks whether this answer, to this asker, given what has already been said, reveals something it should not.

And the leak often happens where no guardrail is watching. Vec2Text recovers 89.2% of full names from embeddings of clinical notes, and the obvious mitigation does not work: the noise level that defeats inversion collapses retrieval quality to almost nothing, while the level that preserves retrieval has since been broken by denoising-aware inversion. No major vector database documents an inversion-specific defense.

What would close the distance is mostly research with a reference implementation and no owner. Information-flow control, which carries a capability on every value and refuses a tool call that would violate policy, drives successful AgentDojo attacks to zero while still completing 77% of tasks against 84% undefended; CaMeL is published, and its code is released as a research artifact rather than a product. Adversarial anonymization, which rewrites text until an adversary model stops inferring, takes attribute accuracy from 86.7% to 41.6% with better readability than entity redaction, and exists as a small repository that reproduces its paper. Known-answer detection is the best-performing injection defense in the USENIX benchmark, at about a 4% false-negative rate, and no commercial guardrail documents it as a configurable policy. Detection of model extraction by query-distribution analysis reaches 95.1% balanced accuracy over traffic windows and ships nowhere. Each is a small piece of infrastructure belonging to no vendor's product boundary, which is why none of them is maintained.

Confidential computing gap

This section focuses on what an enterprise hits when it tries to run an inference service inside confidential computing.

Hardware enclaves are the practical option, and the first gap is between the silicon and the catalog. NVIDIA supports confidential computing across up to eight GPUs with NVLink encryption on HGX B200 and B300. Every confidential GPU instance a major cloud actually sells has one GPU in it — Azure's NCCadsH100v5 with a single H100, Google's a3-highgpu-1g and g4-standard-48 — and AWS's confidential computing is built on the Nitro System, which documents no GPU-equipped enclave. A team that wants a 70B model in a TEE on a major cloud cannot buy the instance, whatever the hardware supports.

The published overheads look contradictory until you see what explains them. Tuned measurement on Blackwell reports roughly 1% to 3%, about 3% on eight B200s; stock configurations of the same workloads land at 30% to 40%. The mechanism is that confidential mode turns a kernel submission into roughly a 12-microsecond operation, so the penalty falls on small units of work rather than on arithmetic. Full CUDA graphs, overlap-scheduler patches and vCPU pinning are the difference between those two figures, and none of it is default or detected automatically — which means a team following a quickstart measures the 35% and concludes the technology is unusable. Prefill carries the encrypted collective and is hit harder than decode, and short generations have the least to amortize it over: one Blackwell measurement runs 14.4% at 256 output tokens and 1.1% at 2,048.

Three limits are not matters of tuning. Multi-node confidential inference does not exist, because GPUDirect RDMA is documented as incompatible with confidential mode, which rules out cross-node tensor parallelism and disaggregated prefill and decode; the ceiling is a single node. Key rotation is not supported in Protected PCIe or in Blackwell passthrough mode, while the initialization-vector space is finite and exhausting it causes transfers to fail — the documented remedy is restarting the confidential VM, which is an awkward thing to design an always-on endpoint around. And confidential mode is all-or-nothing per host, with Protected PCIe assigning all eight GPUs and their switches to one tenant, so a confidential endpoint cannot share a machine. That changes the unit economics considerably more than the single-digit compute overhead does.

Loading is unsolved in the same way. With the GPU in confidential mode nothing crosses PCIe in the clear: transfers are routed through a shared bounce buffer, encrypted on one side and decrypted on the other, so RAM-to-GPU bandwidth measures 3.5 GB/s against 51.6 GB/s unprotected. A cold start is three hops — storage to host, host to GPU, then serving — and only the middle one is affected, but it is the hop that used to be almost free. Seventy billion parameters at FP8 take roughly twenty seconds to cross rather than under two, and nearer forty at FP16, which moves the PCIe transfer from the fastest part of the pipeline to a co-bottleneck with storage. The usual way around it is to bypass host memory with GPUDirect, which the documentation lists as incompatible with confidential mode, and nobody has published a cold-start design for a model that has to cross that gap before it can serve.

Multi-party computation and homomorphic encryption sit further out from practical use. The fastest published secure-inference systems reach about 27 seconds for a single 128-token forward pass of Llama2-7B, and the most-cited LLaMA-7B result is roughly five minutes to produce a single token. CrypTen, still the library most write-ups point at, was archived in May 2025, and what remains maintained is a research compiler rather than a serving system. Under homomorphic encryption the best published figure for an 8B model is 366.4 seconds of server-side evaluation for a 128-token input at 58.9 GiB of peak device memory — and that is prefill; published generation figures exist only for much smaller models, at 544 seconds per token for GPT-2 small. What does ship in production under homomorphic encryption is encrypted lookup, as in Apple's Live Caller ID and Microsoft Edge's Password Monitor, not neural-network inference of any size. The one maintained library with documented language-model support runs a hybrid split in which linear layers are evaluated encrypted on the server while the client computes the nonlinearities in the clear, which protects the server's weights from the client — close to the inverse of what an enterprise means by confidential inference, and not a substitute for it.

What CODAS is conducting

CODAS works on the gaps above, and the shape of the work follows from them. Where something ships but only a specialist can operate it, the useful contribution is to move the decision up to the person who owns it. Where nothing ships at all, it is to build the missing piece and then maintain it, which is the harder half.

The differential-privacy work is the clearest case of the first kind. A compliance manager should be able to state the obligation — this corpus, these data subjects, this retention position — and have the unit of privacy, the budget and the accounting follow from it, with the resulting guarantee expressed in terms an auditor can read. Today that path runs through a research judgment, a tutorial and a library that classifies itself as beta. It should run through a library with defaults somebody can defend.

We are not going to describe the rest in detail yet, and the reason is ordinary rather than coy. The work is still in research, and parts of it will need protecting before they are published. Announcing a design we may still change, or publishing something we may seek a patent on, would serve nobody reading this.

What we will do is say when there is something to use. Releases, and the measurements behind them, will be announced on the CODAS blog.

References

Abowd, John M., et al. "The 2020 Census Disclosure Avoidance System TopDown Algorithm." Harvard Data Science Review, Special Issue 2, July 2022, https://doi.org/10.1162/99608f92.529e3cb9.

Alrazihi, Layan Abdulilah, et al. "Evaluating the Accuracy of Automated and Semi-Automated Anonymization Tools for Unstructured Health Records." Surgical Neurology International, vol. 16, 2025, article 313, https://doi.org/10.25259/SNI_459_2025.

Amazon Web Services. "AWS Clean Rooms FAQs." Amazon Web Services, https://aws.amazon.com/clean-rooms/faqs/.

Amazon Web Services. "AWS Clean Rooms ML." AWS Clean Rooms User Guide, https://docs.aws.amazon.com/clean-rooms/latest/userguide/machine-learning.html.

Amazon Web Services. "CreateMLInputChannel." AWS Clean Rooms ML API Reference, https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_CreateMLInputChannel.html.

Amazon Web Services. "Creating an ML Input Channel." AWS Clean Rooms User Guide, https://docs.aws.amazon.com/clean-rooms/latest/userguide/create-ml-input-channel.html.

Amazon Web Services. "Custom Modeling in AWS Clean Rooms ML." AWS Clean Rooms User Guide, https://docs.aws.amazon.com/clean-rooms/latest/userguide/working-with-custom-models.html.

Amazon Web Services. "Differential Privacy Policy." AWS Clean Rooms User Guide, https://docs.aws.amazon.com/clean-rooms/latest/userguide/dp-settings.html.

Amazon Web Services. "Model Authoring Guidelines for the Training Container." AWS Clean Rooms User Guide, https://docs.aws.amazon.com/clean-rooms/latest/userguide/custom-model-guidelines.html.

Amazon Web Services. "SQL Capabilities of AWS Clean Rooms Differential Privacy." AWS Clean Rooms User Guide, https://docs.aws.amazon.com/clean-rooms/latest/userguide/dp-sql-capabilities.html.

Amazon Web Services. "Training Data Requirements for Clean Rooms ML." AWS Clean Rooms User Guide, https://docs.aws.amazon.com/clean-rooms/latest/userguide/ml-training-data-requirements.html.

Amazon Web Services. "What Is Nitro Enclaves?" AWS Nitro Enclaves User Guide, https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitro-enclave.html.

Apple. Apple Differential Privacy Technical Overview, https://www.apple.com/privacy/docs/Differential_Privacy_Overview.pdf.

Apple Differential Privacy Team. "Learning with Privacy at Scale." Apple Machine Learning Research, 6 Dec. 2017, https://machinelearning.apple.com/research/learning-with-privacy-at-scale.

Asad, Amean, and Ansgar Grunseid. "Benchmarking Confidential Computing Performance on NVIDIA Blackwell GPUs." arXiv, June 2026, https://arxiv.org/abs/2608.26575.

Boemer, Fabian, et al. "Announcing Swift Homomorphic Encryption." Swift.org, 30 July 2024, https://swift.org/blog/announcing-swift-homomorphic-encryption/.

Bun, Mark, and Thomas Steinke. "Concentrated Differential Privacy: Simplifications, Extensions, and Lower Bounds." TCC 2016, https://arxiv.org/abs/1605.02065.

Chennabasappa, Sahana, et al. "LlamaFirewall: An Open Source Guardrail System for Building Secure AI Agents." arXiv, 6 May 2025, https://arxiv.org/abs/2505.03574.

Data Privacy Stack. "Frequently Asked Questions (FAQ)." Presidio Documentation, https://microsoft.github.io/presidio/faq/.

Data Privacy Stack. Presidio: Data Protection and De-identification SDK. MIT license, https://github.com/data-privacy-stack/presidio.

Databricks. "What Is Databricks Clean Rooms?" Databricks Documentation, 8 Oct. 2026, https://docs.databricks.com/aws/en/clean-rooms/.

Debenedetti, Edoardo, et al. "AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents." arXiv, 19 June 2024, https://arxiv.org/abs/2406.13352.

Debenedetti, Edoardo, et al. "Defeating Prompt Injections by Design." arXiv, 24 Mar. 2025, https://arxiv.org/abs/2503.18813.

Dong, Ye, et al. "PUMA: Secure Inference of LLaMA-7B in Five Minutes." arXiv, 26 Sept. 2023, https://arxiv.org/abs/2307.12533.

Dwork, Cynthia, et al. "Differential Privacy in Practice: Expose Your Epsilons!" Journal of Privacy and Confidentiality, vol. 9, no. 2, 2019, https://doi.org/10.29012/jpc.689.

Facebook Research. CrypTen. MIT license, archived 13 May 2025, https://github.com/facebookresearch/CrypTen.

Fan, Yuhang, et al. "An Open-Source End-to-End FHE Implementation for Privacy-Preserving Llama 3 8B Inference." arXiv, https://arxiv.org/abs/2609.12378.

Flower Labs. Flower: A Friendly Federated AI Framework. Apache-2.0 license, https://github.com/flwrlabs/flower.

Google. "Privacy Checks in Ads Data Hub." Google for Developers, 25 Sept. 2026, https://developers.google.com/ads-data-hub/guides/privacy-checks.

Google. "Regression Modeling in Ads Data Hub." Google for Developers, 18 Sept. 2024, https://developers.google.com/ads-data-hub/guides/regression-modeling.

Google. "Supported Configurations." Google Cloud Documentation, 22 Oct. 2026, https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations.

Gupta, Kanav, et al. "SIGMA: Secure GPT Inference with Function Secret Sharing." Proceedings on Privacy Enhancing Technologies, vol. 2024, no. 4, 2024, pp. 61–79, https://doi.org/10.56553/popets-2024-0107.

Hackett, William, et al. "Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks against Prompt Injection and Jailbreak Detection Systems." arXiv, 15 Apr. 2025, https://arxiv.org/abs/2504.11168.

Hugging Face. Safetensors. Apache-2.0 license, https://github.com/safetensors/safetensors.

IBM. Diffprivlib: IBM Differential Privacy Library. MIT license, version 0.6.6, https://github.com/IBM/differential-privacy-library.

IBM. Granite Guardian 4.1 8B. Apache-2.0 license, https://huggingface.co/ibm-granite/granite-guardian-4.1-8b.

Kanpak, Halil İbrahim, and Didem Unat. "Static Bootstrap Placement for Encrypted Language Model Decoding." arXiv, 6 Oct. 2026, https://arxiv.org/abs/2610.04912.

Lauter, Kristin, et al. "Password Monitor: Safeguarding Passwords in Microsoft Edge." Microsoft Research Blog, 21 Jan. 2021, https://www.microsoft.com/research/blog/password-monitor-safeguarding-passwords-in-microsoft-edge/.

Liu, Shuze, et al. "An Embarrassingly Simple Detector for Model Extraction Attacks in Large Language Model API Traffic." Proceedings of the 2026 Conference on Empirical Methods in Natural Language Processing, Association for Computational Linguistics, 2026, pp. 17320–38, https://aclanthology.org/2026.emnlp-main.748/.

Liu, Yupei, et al. "Formalizing and Benchmarking Prompt Injection Attacks and Defenses." Proceedings of the 33rd USENIX Security Symposium, USENIX Association, 2024, pp. 1831–47, https://www.usenix.org/conference/usenixsecurity24/presentation/liu-yupei.

Lukas, Nils, et al. "Analyzing Leakage of Personally Identifiable Information in Language Models." 2023 IEEE Symposium on Security and Privacy, May 2023, https://arxiv.org/abs/2302.00539.

Meta. "Llama Guard 4." Model Cards and Prompt Formats, https://developer.meta.com/ai/docs/model-cards-and-prompt-formats/llama-guard-4/.

Meta. Llama Prompt Guard 2. https://huggingface.co/meta-llama/Llama-Prompt-Guard-2-86M.

Meta. Opacus: Training PyTorch Models with Differential Privacy. Apache-2.0 license, version 1.6.0, https://opacus.ai.

Microsoft. dp-transformers: Differentially Private Transformers Using Hugging Face and Opacus. MIT license, version 1.0.0, https://github.com/microsoft/dp-transformers.

Microsoft. "NCCads_H100_v5 Sizes Series." Microsoft Learn, 28 July 2026, https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/gpu-accelerated/nccadsh100v5-series.

Mireshghallah, Niloofar, et al. "Can LLMs Keep a Secret? Testing Privacy Implications of Language Models via Contextual Integrity Theory." arXiv, 27 Oct. 2023, https://arxiv.org/abs/2310.17884.

Morris, John X., et al. "Text Embeddings Reveal (Almost) As Much As Text." Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, Association for Computational Linguistics, 2023, pp. 12448–60, https://aclanthology.org/2023.emnlp-main.765/.

Near, Joseph P., et al. Guidelines for Evaluating Differential Privacy Guarantees. NIST Special Publication 800-226, National Institute of Standards and Technology, Mar. 2025, https://doi.org/10.6028/NIST.SP.800-226.

NVIDIA. "Jailbreak Protection." NVIDIA NeMo Guardrails Library Developer Guide, https://docs.nvidia.com/nemo/guardrails/latest/configure-guardrails/guardrail-catalog/jailbreak-protection.

NVIDIA. NVIDIA FLARE: Federated Learning Application Runtime Environment. Apache-2.0 license, https://github.com/NVIDIA/NVFlare.

NVIDIA. "NVIDIA Trusted Computing Solutions Release Notes." NVIDIA Docs, Aug. 2025, https://docs.nvidia.com/580trd1-trusted-computing-solutions-release-notes.pdf.

OpenDP. SmartNoise SQL: Differentially Private SQL Queries. MIT license, version 1.0.10, https://github.com/opendp/smartnoise-sdk.

Pelikan, Martin, et al. "Enabling Differentially Private Federated Learning for Speech Recognition: Benchmarks, Adaptive Optimizers and Gradient Clipping." arXiv, 29 Sept. 2023, https://arxiv.org/abs/2310.00098.

Pethe, Sheel, et al. "Hardware-Rooted AI Security That Won't Slow You Down." NVIDIA Technical Blog, 2 July 2026, https://developer.nvidia.com/blog/hardware-rooted-ai-security-that-wont-slow-you-down/.

Pilán, Ildikó, et al. "The Text Anonymization Benchmark (TAB): A Dedicated Corpus and Evaluation Framework for Text Anonymization." Computational Linguistics, vol. 48, no. 4, 2022, pp. 1053–1101, https://doi.org/10.1162/coli_a_00458.

Snowflake. "Differential Privacy in Snowflake." Snowflake Documentation, https://docs.snowflake.com/en/user-guide/diff-privacy/differential-privacy-overview.

Snowflake. "ML Jobs in Data Clean Rooms." Snowflake Documentation, https://docs.snowflake.com/en/user-guide/cleanrooms/ml-jobs.

Snowflake. "Running Free-Form SQL Queries on Clean Room Tables." Snowflake Documentation, https://docs.snowflake.com/en/user-guide/cleanrooms/web-app-sql-template.

Staab, Robin, et al. "Beyond Memorization: Violating Privacy via Inference with Large Language Models." arXiv, 11 Oct. 2023, https://arxiv.org/abs/2310.07298.

Staab, Robin, et al. "Large Language Models Are Advanced Anonymizers." arXiv, 21 Feb. 2024, https://arxiv.org/abs/2402.13846.

Tang, Jun, et al. "Privacy Loss in Apple's Implementation of Differential Privacy on MacOS 10.12." arXiv, 8 Sept. 2017, https://arxiv.org/abs/1709.02753.

United States Census Bureau. "Census Bureau Sets Key Parameters to Protect Privacy in 2020 Census Results." Census.gov, 9 June 2021, https://www.census.gov/newsroom/press-releases/2021/2020-census-key-parameters.html.

United States Census Bureau. Disclosure Avoidance for the 2020 Census: An Introduction. U.S. Government Publishing Office, 2021, https://www2.census.gov/library/publications/decennial/2020/2020-census-disclosure-avoidance-handbook.pdf.

Waibl, Leonhard, et al. "BELLS-O: Evaluating the Operational Trade-Offs of LLM Supervision Systems." arXiv, 12 June 2026, https://arxiv.org/abs/2606.20668.

Wang, Yubo, et al. "Denoising-Aware Inversion: Revealing Privacy Risks in Noise-Protected Text Embeddings." arXiv, 19 Aug. 2026, https://arxiv.org/abs/2608.18610.

Xu, Zheng, et al. "Federated Learning of Gboard Language Models with Differential Privacy." Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics: Industry Track, Association for Computational Linguistics, 2023, pp. 629–39, https://aclanthology.org/2023.acl-industry.60/.

Yu, Da, et al. "Differentially Private Fine-tuning of Language Models." ICLR 2022, https://arxiv.org/abs/2110.06500.

Zama. "Hybrid Models." Concrete ML Documentation, https://docs.zama.org/concrete-ml/guides/hybrid-models.

---

「CODAS Community」へのご参加・ご登録について

一般社団法人AIデータ主権共創機構（CODAS）では、「Privacy-First AI」基盤の構築と持続可能なAIエコシステムの発展に向け、研究者・エンジニア・法務・政策・ビジネス・市民など、立場を越えてオープンに集い、秘匿AIの未来を共に創る共創プラットフォーム「CODAS Community」のメンバーを募集しています。

■ 法人企業様のご参画

CODASの理念や取り組みにご賛同いただき、AIエコシステムの社会実装や標準づくり、共創プロジェクトを共に推進していただける法人企業様を募集しております。ご入会や連携に関するお問い合わせ・お申し込みは、下記フォームより承っております。

お問い合わせフォーム：https://codas-ai.org/contact

※件名に「会員の申込」とご明記のうえ、貴社の簡単なご紹介（事業内容等）を添えてご連絡ください。確認後、担当者よりご案内いたします。

■ 個人・一般の皆様のご参加

公式Discordおよびメールマガジンでは、勉強会・ワークショップ・ミートアップ等のイベントへの優先アクセスや、秘匿性技術・ルール標準化に関する最新の知見をお届けします。東京のリアル拠点での交流も含め、立場を問わずどなたでもご参加いただけます。

• 公式Discord招待URL：https://discord.com/invite/codas
• 公式ウェブサイト（メールマガジン登録）：https://codas-ai.org/community

CODASについて

一般社団法人AIデータ主権共創機構（CODAS）は、「安全・安心なAI社会」の実現を目指す非営利・中立の法人です。データプライバシー技術の研究開発と、そのオープンソース化による社会実装を推進しています。データを外部に出さずにAIを高度活用できる「Privacy-First AI」基盤を「創る・使う・広げる」ことを基本理念に掲げています。

• 代表理事：花岡 悟一郎
• 設立：2025年10月
• URL：https://codas-ai.org/jp

---

≪本件に関するお問い合わせ先≫

一般社団法人AIデータ主権共創機構（CODAS）イベント事務局 E-mail：info@codas-ai.org