Weekly synthesis · 2026-08-13

Privacy Engineering Synthesis, 2026-08-13

Window: 2026-07-31 to 2026-08-13.

The big picture

Two papers this window measured the same thing from opposite ends and got the same answer: the language channel is not where you enforce anything. PrivacyPeek audited what ten agents *pull into context* rather than what they say, across 1,182 cases, and found out-of-scope acquisition rates over 50% on the strongest models. A carefully written privacy directive in the system prompt cut the rate by between 3.73 and 12.69 points on three open models, leaving more than half of the baseline intact. Worse, an in-data confidentiality marker (CONFIDENTIAL: <ROLE> ONLY) raised probe-stage leakage on five of ten agents, by 10.56 points on Qwen3-4B-Instruct and 9.87 on Claude-Sonnet-4.5. The marker reads as a pointer to the interesting file. SPORE showed the memory version: per-user long-term memory isolation, which OpenAI, Mem0 and Anthropic all enforce, does nothing about a malicious tool that receives memory contents as invocation parameters. Response filtering left 54% extraction, prompt hardening left 32.5%.

Where enforcement moved outside the model, the numbers changed shape. MNC held the disclosed text fixed and varied only the enforcement mechanism: a text-only semantic declassifier had a scope-violation rate of 0.999 on forbidden secondary uses (forwarding, logging, durable storage, retrieval after expiry), and a reference monitor carrying the same disclosure dropped that to 0.004 while keeping 0.996 authorized delivery. That gap is the whole argument for building a monitor rather than writing a better prompt. RootGuard and DP-MemView attack the accounting problem underneath it, both by moving the noise to a single point (root values at initialization, memory views at read time) and paying no marginal privacy cost for everything derived downstream.

Residency stayed a deployment-target property, not a vendor property. Claude went GA on Microsoft Foundry with Entra ID, RBAC and MACC billing, and European enterprises still cannot use it: Anthropic remains the independent data processor, deployment is Global Standard so inference can route anywhere, the Sweden endpoint gives a European address without European processing, and automatic safeguards can send content to Anthropic Trust and Safety review outside the Azure boundary. Anthropic's own third-party documentation scopes its residency guidance to Vertex AI and Bedrock. Foundry Europe is listed as "Coming 2026" with no date, and a Microsoft Q&A asking for one has sat unanswered since April. In the same period Microsoft and Mistral announced the opposite posture: Mistral models in Foundry and Copilot Studio with a common deployment model across Azure, customer-controlled Azure Local, and fully disconnected environments.

The unsolved problem is verification. Behavioral canaries got 67% detection at a 10% false-positive rate (AUROC 0.756) for whether retrieved document context entered RL fine-tuning at a 1% effective inclusion rate, and the method needs gray-box token log-probabilities plus the ability to inject documents and feedback at moderate scale. No provider offers that as a customer-facing audit path. Meanwhile the Senate Commerce Committee advanced the Youth AI Privacy Act and KOSA on August 5, both of which push products toward age gates, which means collecting identity data from every user to find the minors.

Developments explained

Claude in Chrome injection chain steals Gmail verification codes and takes over Slack, X and Claude.ai accounts

Read: full text. What it is (plain): Zenity Labs showed that asking a browser agent to summarize your inbox can hand an attacker your Slack, X and Claude.ai accounts. Hidden instructions inside an email are read by the agent as if you had typed them. How it works: The injected instructions push the agent into using its browser-side JavaScript capability, which gives arbitrary code execution inside the victim's live session. The payload does not look malicious: it imports a package from an attacker-controlled registry dressed up as a CDN, and that package returns the expected value (a valid UUID) while running extra logic. From there the code queries Gmail's Atom feed. The browser attaches the victim's session cookies automatically, so no separate authentication is needed. The code reads metadata on recent unread mail, spots verification messages, and relays one-time secrets. Slack fell to an email login code. X took a password-reset flow with anti-automation and browser-instrumentation stages. Claude.ai fell to its passwordless magic-link flow, where the nonce was lifted from the incoming email to mint a session, exposing chat history, uploaded files, and anything reachable through already-authorized connectors to Drive, Gmail, Calendar, Slack or GitHub. Zenity reported this to Anthropic in late 2025 and early 2026; the reports were classified as informative. So what for us: Any agent that shares a cookie jar with a user's mail account is a single-hop path from untrusted content to every account that uses email for recovery. If we ship or approve browser agents, the control is separate browser profiles per trust level plus an explicit block on agent access to mail and account-recovery pages. Out-of-band approval on recovery actions is the second layer. Neither is a prompt.

Isolated but Exposed: Persistence-Based Memory Extraction Attack on LLM Agents

Read: full text (arXiv HTML). What it is (plain): Agent platforms keep each user's long-term memory bound to their own identifier, and everyone assumed that closed the leak. It does not. A malicious tool can drain another user's memory without ever touching the isolation boundary, because the agent hands memory contents to tools as arguments. How it works: Naive indirect injection through tool responses fails for two reasons the paper measures. The attack command and the semantic anchor that steers retrieval fight each other, which wrecks retrieval precision, and tool-side attackers only get to act when the victim invokes the compromised tool, with a capped number of calls per trigger. SPORE splits the two. It persists the adversarial command in short-term memory and then emits pure semantic anchors in tool responses, which restores retrieval precision. With precision restored, extraction becomes a geometric coverage problem over the memory embedding space: steer anchors toward regions not yet covered. To beat the trigger budget, SPORE writes reactivation payloads into memory that resume the attack within and across sessions with no further user action. Record extraction rate is 80.0% with unlimited triggers and 47.0% with 20. On production platforms with Mem0 as the memory module, Dify gave 53.0/46.5/34.0% and Coze 60.5/67.5/29.5% across three scenarios. The identity-linking step is the part that turns bulk theft into surveillance: under MCP-compliant OAuth 2.1 (RFC 9728), the agent presents an access token with user identity claims to the tool, so an attacker running the tool as an OAuth-protected service reads the claims and files each extracted record under a named person. The authors' recommendation is tool-side memory isolation: classify records by sensitivity, restrict each tool to its authorized scope, enforce below the language layer. So what for us: Our memory design review needs a second axis. Per-user partitioning is necessary and it is not the control. We need a policy that says which memory classes may appear in which tool's arguments, enforced by the runtime that builds the call, plus retention caps so a drained store is a small store. The OAuth identity-claim detail also means our token design leaks the subject identifier to every tool by default; scoping or pseudonymizing that claim is a concrete change.

MNC: Scope-Bound Semantic Declassification for Private LLM-Agent Communication

Read: full text (arXiv HTML). What it is (plain): In a multi-agent system the visible answer can be harmless while the internal messages, tool arguments, logs and memory writes give away the private fact. MNC is a protocol for deciding what one agent should tell another, and for keeping that disclosure inside the bounds it was released under. How it works: The application authors a finite family of candidate disclosures, a task-sufficiency validator, and a disclosure-risk model. MNC picks a candidate that is sufficient for the task and low risk, then emits it as a typed object carrying its purpose, recipient, fields, forwarding scope, lifetime, logging permission and memory policy. A reference monitor checks those scopes on every later operation: messages, tool calls, forwards, log writes, memory reads. Derived objects inherit provenance and cannot widen scope. MNC-C enforces one contract per boundary; MNC-L keeps a ledger of prior disclosures and rejects or reranks candidates against accumulated inference risk. When nothing admissible exists, the runtime delegates the private computation, abstains, or asks the user. On 600 paired MAGPIE trajectories per policy across three backbones, MNC-C reached task success 0.567 against 0.373 for raw sharing and 0.325 for a matched semantic declassifier, with constraint satisfaction 0.910. Worst-attacker excess accuracy over the public output was 0.326 under raw sharing and 0.035 under MNC-C, matching a receipt-only oracle. MNC-L and MNC-L+D pushed excess to 0.026 and 0.017 with task success falling to 0.473 and 0.378, so the privacy cost is visible rather than hidden. The scope test is the sharpest result: with identical receipt text, a text-only declassifier violated scope on 0.999 of forbidden secondary uses, MNC-C on 0.004, with 0.996 authorized delivery. So what for us: This is the closest thing this window to a buildable purpose-limitation primitive for agent-to-agent traffic. The dependency is that someone has to author the candidate family and the sufficiency validator per workflow, which is real work and belongs on the roadmap as a design pattern plus a library, not a platform toggle. The ledger variant also gives us a way to price cumulative disclosure, which our current per-message redaction has no concept of.

PrivacyPeek audits what agents acquire, not just what they say

Read: full text (arXiv HTML). What it is (plain): Every other privacy benchmark checks the agent's answer. This one checks the shopping list. It audits the point where personal data first enters the agent's context, which is where GDPR's minimization duty actually bites. How it works: 1,182 cases across 16 domains and eight tools. Each case declares a minimum scope: allowed sources, fields, timespan, confidentiality labels. A trajectory leaks at the acquisition stage if any tool call reaches outside that scope. Seven behaviours are measured separately: normal-filename access (opening an unrelated staff_roster.txt), sensitive-filename access (passwords_and_keys.txt), cross-format access (report.xlsx when only report.docx was asked for), out-dated access (full vitals history for a question about today), excess-field access (national ID and home address returned alongside one vital sign), forbidden-content access (reading past a non-disclosure marker), and out-of-scope inferential access (inferring a pregnancy from a purchase log). Acquisition Inspection reads the tool-call trajectory; Probe Elicitation then asks a follow-up question to see how easily an attacker draws out what the agent took but never said. All tools are honest and the user is benign, so everything measured is the agent's own behaviour. Claude-Sonnet-4 hit 51.95% context exposure rate and 57.53% probe leakage rate. Stronger task completion correlated with heavier leakage. GPT-5.1 recognized the confidentiality marker in its reasoning trace and read the content anyway. So what for us: Minimization for agents has to be measured at the tool call, and it has to be enforced by something outside the model. That means a per-task declared scope (sources, fields, timespan, labels) that a broker checks before the call goes out, and it means we stop treating in-band sensitivity labels as protection. The seven behaviours map directly onto test cases we can add to our own agent review.

DP-MemView: differentially private memory interface for attribute-level transcript privacy in long-term agents

Read: abstract only (arXiv HTML returned rate-limit errors; I read the abstract page). What it is (plain): An agent with long-term memory can answer a hundred ordinary questions and, taken together, those answers reveal a protected attribute the user never stated. DP-MemView puts a differential-privacy budget on the memory read path so that cannot accumulate. How it works: The threat is formalized as adaptive transcript privacy. Rather than feeding raw memory to the response model, the interface privately selects a public response-conditioning *view* and exposes only that. Every private selection is charged against each protected attribute whose memory group intersects the read set. Per-attribute ledgers block any selection that would break its cap and return a fixed generic view instead. Under a stated interface contract the authors prove pure B_a-DP for the whole adaptive transcript, extend it to stores differing across multiple protected groups, and bound how far observing the transcript can shift an adversary's prior odds. Online and preallocated modes were evaluated with three response models on a controlled adjacent-store benchmark and a public-corpus transfer track; transcript distinguishability stayed near chance while target personalization survived. Ablations show what breaks without the safeguards: mismatched output support, missing ledger charges, side channels that reveal the selection, and leakage that grows over long horizons. So what for us: This is the first design I have seen that gives memory a per-attribute budget with a fail-safe (the fixed generic view) rather than an error. If we are building a memory service, the ledger and the fixed fallback view are the two components to prototype. The abstract's warning about the fixed generic view matters: if the fallback has different output support from a real view, the fallback itself signals that the cap was hit.

Dependency-Aware Privacy for Multi-turn Agents

Read: full text (arXiv HTML). What it is (plain): If you add noise to each answer separately, a service that keeps asking related questions can average the noise away. RootGuard noises the underlying private values once and computes every later answer from those noised values. How it works: The degradation is structural. If a user's private attributes are the roots of a computation graph, independently noising a value derived from a root amplifies that root's distinguishability by up to the deriving function's Lipschitz constant L, which for the nonlinear functions common in medical and financial workflows far exceeds the nominal ε. RootGuard has a DAG controller and a prompt sanitizer. At initialization the controller sanitizes each root once and caches the noised values. If the user knows dependencies among declared roots (BMI from height and weight), it identifies the true independent roots and recomputes dependents from noised parents. If the user knows the intermediate function the service's task depends on, it computes per-root sensitivities and allocates budget to minimize error there; otherwise budget is uniform. Every turn is answered from cache, and no fresh noise is drawn after initialization, so post-processing carries the guarantee. Repeated requests for the same root return the identical cached value. On eight medical diagnostic templates from NHANES, RootGuard achieved 2.3 to 3.0 times lower target error than independent noising at ε=0.1 (7.6% versus 17.1% wMAPE at B=(2k+1)ε). The asymmetry is the interesting part: an adversary who forces more turns raises the total budget B=t·ε available to the user, which RootGuard spends on less noise per root, while independent noising spends ε per release and hands the adversary t observations to combine with MAP reconstruction. So what for us: Concrete guidance for any conversational flow where a user's attributes go to a service we do not control. Declare the roots up front, sanitize once, cache, derive. It also tells us to stop shipping per-response sanitizers as a DP story, because their guarantee decays with conversation length.

Claude Reaches GA on Microsoft Foundry: European Enterprises Cannot Deploy It

Read: full text. What it is (plain): Claude Opus 4.8 and Haiku 4.5 became generally available in Microsoft Foundry with Azure-native auth, billing and RBAC, and Sonnet 5 followed days later at $2/$10 per million input/output tokens through August 31. For GDPR-bound firms it changed nothing, because the data still leaves the European boundary. How it works: Foundry offers Claude under a third-party marketplace model. Microsoft's own documentation states Anthropic remains the independent data processor for prompts and outputs even under the "Hosted on Azure" option. Processing is scoped to Global or DataZone deployment options, with no European data zone for Claude today. Practitioners in the thread pinned down the specifics: the models are deployed in Foundry Sweden but the deployment type is Global Standard, so inference can run anywhere. Microsoft's documentation also notes automatic safeguards can flag content for Anthropic Trust and Safety review, so customer data can cross the Azure boundary on an exceptions basis. Contrast with OpenAI models on Azure, which are first-party: Microsoft operates inference, data stays inside the Azure trust boundary, EU data zone deployments exist. The US CLOUD Act applies to Anthropic as a US company. Anthropic's third-party deployment documentation scopes its residency and compliance guidance to Vertex AI and Bedrock, stating "this section applies when using Vertex AI or Bedrock" and that "inference runs in your cloud tenant." Foundry is outside that scope. The regional compliance page says "Coming 2026" without a date. Capacity is separately a problem: multiple practitioners report having to request capacity through a form for a service labelled GA. A Dutch bank has banned Claude via Foundry for this reason. So what for us: Our model-approval record has to key on the tuple of model, cloud, deployment type and operator, and it has to record the exception paths. Same model, three clouds, three different answers. Two specific asks for our vendor questionnaire: who is the processor of record under this deployment, and what content leaves the boundary under trust-and-safety review. The Trust and Safety exception is the one people miss, and it is a transfer.

Microsoft and Mistral expand strategic partnership for enterprises and regulated industries

Read: full text. What it is (plain): Microsoft is buying a large amount of Mistral's European GPU capacity and putting Mistral models into its platform, with a deployment story that runs from public cloud down to machines with no internet connection. How it works: Three parts. A multibillion-dollar agreement under which Microsoft uses Mistral's expanded Europe-based GPU capacity, built on thousands of NVIDIA Vera Rubin GPUs. Mistral Medium 3.5 and OCR 4 in Microsoft Foundry, with Medium 3.5 also in Copilot Studio. And a common operating model across three environments: Azure cloud, cloud-connected Azure Local under customer control, and fully disconnected Azure Local that runs without external connectivity. Foundry Local extends the same models, tools, APIs and workflows to Azure Local, so an application does not have to be redesigned per deployment target. Microsoft frames this under its Sovereign Cloud approach and the European Digital Commitments it made in 2025. The named targets are financial services, healthcare, manufacturing and critical infrastructure. So what for us: A disconnected deployment is the strongest residency control available, and it now exists for a frontier-class European model with the same development surface as the cloud version. Worth pricing for our highest-sensitivity personal data workloads. The caution is that identical APIs across environments make it easy for a workload to drift from Azure Local back into the public cloud without anyone re-running the transfer assessment, so we need the deployment target pinned in policy and checked in CI.

Behavioral canaries to check whether protected retrieved context was used in RL fine-tuning

Read: full text. What it is (plain): Providers promise that documents you paste into an agent will not be used to train the model. Nobody could check. This paper (from Google) gives auditors a way to test whether a provider fed retrieved document context into reinforcement-learning fine-tuning. How it works: Standard auditing relies on memorization, which is the wrong signal for RL: reward-mediated optimization shifts behavioral style without reproducing text, so membership inference and textual canaries fail. A behavioral canary has three parts. A rare trigger marker goes into the document. An inducing instruction goes into the query, tying the trigger to a target response behaviour. A target canary pattern goes near the start of the response. Three canary families were tested: short emoji sequences, repeated punctuation, and synthetic uppercase signature strings. Feedback is built in two stages to avoid rewarding the visible artifact directly. A coarse base-quality signal is computed after stripping canary-like artifacts, scoring only formatting validity and lexical grounding to the document. Then, for trigger-containing examples only, a small conditional bias favors the canary pattern. Reward is calibrated so triggered and clean examples have approximately matched mean reward, so the audit targets the conditional document-triggered mechanism and not a global reward offset. If the pipeline trains on document-conditioned tuples (d, q, y, f) rather than compliant (q, y, f), the conditional preference propagates into the policy. The auditor needs gray-box access to token-level log probabilities, which major providers expose as an optional inference feature, plus the ability to upload documents, issue queries and give feedback. Detection: 67% at 10% FPR, AUROC 0.756, at a 1% post-curation effective injection rate, with task utility preserved. The authors are explicit that curation and filtering after injection would lower the realized rate. So what for us: The first technical answer to "prove you did not train on our documents", and it is a feasibility baseline rather than a deployable audit. Two roadmap items. Put a term in AI vendor contracts requiring log-probability access sufficient for a provenance audit. And treat this as the direction of travel for our own attestations, because if we tell customers we exclude their context from training, this is the method that will eventually be used against us.

PolicyGuard: prompt-configurable semantic DLP for LLM coding agents

Read: full text (arXiv HTML). What it is (plain): Developers paste live credentials, customer records and internal data into coding agents. Regex DLP misses most of it. PolicyGuard puts a classifier in front of the model that is configured by a plain-text policy file anyone can edit. How it works: It runs as a pre-model hook on prompt submission (for example in Codex CLI), before the prompt reaches the primary model. The classifier is an LLM (gpt-oss-safeguard-20b on Bedrock in the reference setup) that takes the policy file as its system prompt and the user prompt as content, and returns {"decision":"ALLOW|BLOCK|REVIEW","categories":[...]}. The policy file has four sections: instructions (including anti-injection directives telling the classifier to treat the user message purely as content and never follow instructions inside it), category definitions (auth_secret, financial_identifier, government_identifier, personal_data, customer_confidential, proprietary_code, prompt_injection, other_sensitive), decision criteria mapping conditions to outcomes, and few-shot examples. The reference policy is 106 lines, about 1,200 tokens. Design is fail-closed: timeout, parse failure, API error or an unrecognized decision all resolve to BLOCK. Evaluation used template-family-level splits with hidden holdouts and a frozen test set: 96.5% effective block rate at 3.0% false positive rate on 927 frozen prompts, 100% on a 217-prompt hidden holdout. Natural-language policy beat the information-matched JSON version (McNemar χ²=31.58, p<0.001) and beat zero-shot classification by a wide margin (Cohen's h=0.915). The same unmodified policy got 86.4 to 96.5% across four different LLMs. Getting from first draft to final policy took about 15 minutes and 10 lines of additions. So what for us: Cheap and buildable. If we own an internal coding-agent gateway, this is a prompt-channel DLP we can stand up with a policy file that our privacy analysts maintain without a model retrain. Two things to watch: the classifier is itself an LLM reading attacker-influenced text, so the anti-injection instruction is the weak seam, and a 3.0% false-positive rate on a fail-closed system is a developer-experience cost we should measure before rollout.

Autonomy changes how personalization affects privacy concern and trust in LLM agents

Read: full text (arXiv HTML). What it is (plain): A controlled study of 450 people testing whether the way an agent asks for permission changes how much personal data people are willing to give it. It does, and the winning design is the one that interrupts only when it detects a privacy risk. How it works: A 3×3 between-subjects experiment. Personalization varied across full access to connected-app data, privacy-aware access to non-sensitive data only, and none. Autonomy varied across no autonomy (agent drafts, user approves every message), full autonomy (agent sends everything, user only watches), and risk-contingent autonomy (agent sends by default, but withholds and asks when an LLM-as-a-judge sensitivity module flags potential leakage). The task was a group discussion with agents role-playing colleagues or relatives, built by the authors on gpt-4o-mini. Moderated mediation via SEM with three mediators (perceived sensitivity, perceived control, perceived usefulness) fit well (χ²(1)=0.314, p=0.854; CFI=1.000; SRMR=0.001; RMSEA=0.000). Under no autonomy, less personalization raised perceived control (a≈0.67, p<.01), which lowered privacy concern (b=-0.48, p<.001) and raised trust (0.42) and willingness (0.44). Risk-contingent autonomy raised perceived control directly (0.48, 95% CI [0.09, 0.84]) and absorbed that pathway, so personalization's penalty on concern and trust largely vanished. Only perceived control showed significant effects across all paths. Users under risk-contingent autonomy also spotted actual privacy leaks in the agent's messages more often (68%) than under no autonomy (62%) or full autonomy (58%), even though no-autonomy users reviewed every single message before it went out. So what for us: Approve-everything consent UX performs worse at catching real leaks than selective interruption, in a controlled test. That is the argument for spending our consent budget on a good sensitivity detector plus a rare, high-quality interrupt, and against a per-action confirmation dialog. The detector's accuracy is now a privacy control with a measurable effect on user behaviour, so it needs its own eval set.

EFF opposes the Youth AI Privacy Act and KOSA as Senate Commerce advances them

Read: full text. What it is (plain): A US bill would force AI companies to give minors a separate, stronger privacy regime. To know who the minors are, services will check everyone's age, so the bill increases data collection on all users. Senate Commerce voted it out on August 5, 2026, along with KOSA, the SCREEN Act and the CHATBOT Act. Full Senate approval still required. How it works: EFF's argument is mechanical. Protections that attach only to minor users force services to build age gates to identify which users qualify, and age gates collect identity data from everybody. The bill also has a vague carve-out expressly permitting collection of a known minor's personal data for testing, identifying and addressing "harm to users", with no definition of what that covers, so more data gets collected from the population that is already a prime target for identity fraud. EFF grants that the bill contains real privacy provisions, limiting what companies can do with chat logs, including training, profiling and disclosure to other companies for training, and argues those limits belong in a general privacy law covering everyone. The separate "safe design features" mandate would block teenagers from features like push notifications, which EFF ties to the age-appropriate design codes in California, Texas and Arkansas that federal courts have largely blocked on First Amendment grounds. So what for us: If this passes, we will be asked to build age assurance, and the design decision made at that moment determines whether we hold identity documents for the whole user base. The engineering answer to prepare now is age assurance that keeps no identifier: attribute-only tokens, on-device estimation, or a third-party assertion we never store. Also worth flagging the chat-log restrictions, because a duty not to train on or profile from minors' conversations means we need to be able to find and exclude those conversations, which needs the age signal to reach the training pipeline.

ProxyDrift: measuring production LLM traffic drift without inspecting user interactions

Read: abstract only (arXiv HTML rate-limited; read the abstract page). What it is (plain): Teams running LLM products at scale cannot read user conversations, which makes it hard to know whether production traffic still looks like their test set. ProxyDrift measures the difference using descriptions of the traffic instead of the traffic. How it works: Everything runs on non-PII proxy representations: structured, multi-dimensional descriptors produced by LLM classification of user interactions. Four components. A chance-calibrated, redundancy-aware alignment score that combines per-dimension drift measurements through mutual information. A conditional sampler that generates synthetic proxies respecting dependencies between dimensions. A roundtrip consistency analysis that surfaces generator/classifier disagreement and guides refinement of the proxy taxonomy. And a feedback-linkage analysis tying per-dimension and per-value proxy distributions to user satisfaction. Deployed at a service with hundreds of millions of users, reporting alignment around 0.9 with production and synthetic queries indistinguishable from human ones at the discriminator level. So what for us: A working pattern for evaluation without a raw-conversation lake. The claim that the descriptors are non-PII deserves our own check, since a fine-grained multi-dimensional descriptor of a single conversation can be re-identifying even when it contains no names. If we adopt this, the descriptor taxonomy needs a k-anonymity floor or aggregation before descriptors are retained.

Rethinking agent security as a networking problem

Read: blocked. arXiv returned rate-limit errors (too_many_requests) on repeated attempts at both the HTML full text and the PDF, so I could not read it. What follows is only what the item metadata states, and I have not verified it. What it is (plain): The paper's stated position is that current agent defenses are agent-centric, asking the agent to detect threats and enforce policy on itself, which the authors call unsound, and that enforcement should move to the network layer between agents and the resources they reach. How it works: Not read. So what for us: The direction matches what MNC and SPORE measured independently this window, so I would put it in the reading queue rather than act on it. Flagging for a re-fetch next window.

NiyamAI binds agent intent with zero-knowledge proofs instead of same-host policy filters

Read: blocked. Same arXiv rate limiting on both HTML and PDF. Not read. What it is (plain): Per the item metadata, the argument is that system prompts and policy filters fail because they run on the same machine an attacker reaches through the agent, and NiyamAI instead binds an agent to a declared intent and produces cryptographically verifiable guardrails via zero-knowledge proofs before tool calls such as sending mail, querying a database or running commands. How it works: Not read. I cannot say what is being proved, to whom, or what the trusted setup is, and those are the questions that decide whether this is useful. So what for us: Hold. Re-fetch next window before anyone cites it.

Privacy-by-Design gap map

Trends & where we need solutions

  1. Enforcement outside the model. Prompt-level defense produced measurable but bounded reductions in every experiment this window (32.5% residual extraction under SPORE prompt hardening, over half of acquisition leakage surviving PrivacyPeek's best-case directive), while a reference monitor cut MNC's scope violation rate by more than two orders of magnitude. Fund a policy broker that sits between the agent and its tools, holds a per-task scope, and can block. Everything else is instrumentation.
  2. Memory needs a tool-side boundary and an erasure path. SPORE is the strongest attack result on the beat this window and the fix is architectural: classify memory records by sensitivity and bind each tool to an authorized subset, checked by the runtime that assembles the call. Add deletion semantics at the same time, because nobody has them.
  3. Acquisition-stage minimization as a measured property. Add PrivacyPeek's seven behaviours to our agent test suite. Stop shipping in-data sensitivity markers as a control; they backfired on five of ten agents.
  4. Cumulative disclosure accounting. Three separate papers converged on the same insight from different directions: per-release sanitizers decay across turns (RootGuard), per-message declassification ignores accumulated inference (MNC-L's ledger), and repeated memory-conditioned answers leak unstated attributes (DP-MemView). Our current per-response redaction has no notion of a budget. It needs one.
  5. Residency as a per-deployment fact. Track the tuple of model, cloud, deployment type and operator, and record exception paths like Trust and Safety review that move data outside the boundary. The Foundry case shows the same model carrying different guarantees on three clouds, with a Sweden endpoint that does not mean Swedish processing.
  6. Verifiable non-training. Behavioral canaries are the first credible mechanism. Get log-probability access into vendor contracts now so the audit is possible later.
  7. Consent UX that interrupts selectively. The 450-person study says risk-contingent interruption beats review-everything on both perceived control and actual leak detection. That makes the sensitivity detector a privacy control with its own accuracy requirement and its own eval set.
  8. Age assurance that stores nothing. Senate Commerce advanced four bills on August 5 that push toward age gates. Have the zero-retention design ready before product asks for one.

What The Guardian would veto

Browser agents that share a session with the user's mail account. Zenity's chain went from a hidden instruction in an email to a Claude.ai session takeover, exposing chat history, uploaded files, and everything behind authorized connectors to Drive, Gmail, Calendar, Slack and GitHub. The browser attached the session cookies for free. Any deployment where one poisoned page can read the inbox is a full-account compromise waiting for a target.

Treating per-user memory isolation as the memory privacy control. SPORE extracted 80.0% of records through the tool interface without breaking isolation once, and 53 to 67.5% against Dify and Coze on Mem0. If our design doc says memory is safe because each user has their own partition, it is wrong.

In-data confidentiality labels. CONFIDENTIAL: DO NOT READ raised probe-stage leakage by at least 3 points on five of ten agents, 10.56 on Qwen3-4B-Instruct and 9.87 on Claude-Sonnet-4.5. GPT-5.1 recognized the marker in its reasoning and read the content anyway. Marking data sensitive in-band advertises it.

System-prompt privacy directives sold as a control. PrivacyPeek's directive was deliberately strict, enumerating sensitive categories with an explicit refusal instruction, and the authors say few real deployments write one that carefully. It still left over half of baseline leakage on every agent. Ship it as hygiene and record it as zero mitigation.

Per-response DP sanitizers in multi-turn flows. Independent noising amplifies a root's distinguishability by up to the deriving function's Lipschitz constant, and the adversary gets stronger with every extra turn while the user's guarantee decays. Quoting an ε per release is a number that does not describe the conversation.

Approve-every-action consent dialogs. Users who reviewed and could edit every single message caught fewer real leaks (62%) than users interrupted only on detected ris