Two big moves from Brussels this month:

1. The EU AI Act reached full application — all provisions are now enforceable, with fines up to €35M or 7% of global turnover, and GPAI/LLM providers under active supervision.

2. New EDPB guidelines state that AI models trained on personal data can't be presumed anonymous. Memorisation and extraction attacks are now risks you're expected to assess. Coordinated enforcement against LLM providers is anticipated by 2027.

Everyone's talking about the model providers. But what about *us* — the companies feeding documents into these models every day? Contracts, HR files, support tickets... every prompt potentially ships personal data to a third-party LLM, and under GDPR we stay accountable for it.

So here's my question: is anyone actually pseudonymizing documents *before* they hit the LLM (and re-identifying on the way back)? What's your approach — regex/NER scrubbing, local proxy, gateway solutions? Or is everyone just... hoping for the best?

An interesting study about the risks of bad code injection as many ai generated code is not reviewed and understood any more by developers: https://arxiv.org/abs/2606.05647
Do you think is it a real threat that we are progressively loosing our code control ?

Some of my clients have deployed PromptCape on their employees’ workstations, so they can use the pseudonymization feature, while making sure that shared “company policy packs” are in place.

However, they have realized that not all documents go through PromptCape, because users sometimes prompt AI services directly after downloading documents locally from their ECM.

To avoid these manual workarounds and the associated data leakage risks, they asked me to provide a server mode for PromptCape, so that the proxy can be accessed directly by the ECM with the users’ prompts. This way, documents are submitted together with the prompts through the PromptCape proxy, without users having to download the documents locally and potentially bypass the pseudonymization process.

So far, I have only implemented this for one ECM — which is where the documents are managed in the first place, making it an ideal place to enforce pseudonymization.

However, I would be very interested to hear about other use cases where a server mode for PromptCape could be useful.
thank you

An AI agents hacks a subscription system to achieve the goal it has been assigned: https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gym-website-aus-cyber-attack/107007986
Does it mean that AI models are not aware of the legal barriers ?
And as they now know all the codes, it will be difficult to prevent them from hacking everything not secure enough or exposed because they have enough information like ip, usernames, … which have been sent in code and documents during coding sessions!

Trump authorises, under very specific conditions related to government link and supervision, companies to hack-back when attack : https://www.washingtonpost.com/national-security/2026/08/14/trump-signs-memo-authorizing-private-sector-launch-cyberattacks/
Is it the start of more hacking and more bad behaviours to for instance increase industrial espionage ?

AISI reveals some cybersecurity incident related to ai agent : https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing.

CrowdStrike 2026 Threat Hunting Report reveals key informations on the multiple roles of AI in protection, attacks and vulnerabilities exploitation : https://www.crowdstrike.com/en-us/resources/reports/threat-hunting-report.

Worth to read it but do not know all what we have to do at our scale as a lambda company to be fully protected now!!!

At least at our level of AI usage, we do not expose any sensitive IT information through obfuscation and pseudonymisation.

If an AI agent can turn bare internet access into three real breaches with zero inside knowledge (see Anthropic/OpenAI's recent disclosures), what do you think happens the day one of your internal docs — architecture, configs, real customer names — leaks some other way? Wrote a piece on this, and on pseudonymizing docs before they ever reach an AI provider: https://dev.to/genevieve_breton_cb795f52/when-ai-agents-go-off-script-what-openai-and-anthropics-recent-incidents-teach-us-about-exposure-1ndp

Feedback welcome

If an AI agent can turn bare internet access into three real breaches with zero inside knowledge (see Anthropic/OpenAI's recent disclosures), what do you think happens the day one of your internal docs — architecture, configs, real customer names — leaks some other way? Wrote a piece on this, and on pseudonymizing docs before they ever reach an AI provider. Feedback welcome

To continue about my client who asked me to add to PromptCape, particularly in proxy mode, the pseudonymization of Excel, Word, and Markdown documents : they noticed that documents such as Technical Architecture Documents, Installation Documents, Operations Documents, How-Tos, Specifications were being sent to AI systems with sensitive data (PII, configuration data, customer names, etc.). I therefore added this feature and explained the development approach in Document pseudonymization for AI assistants: sending the spreadsheet without sending the customers - DEV Community. Thank you for your feedback on this approach.

One of my client sees that some words and excels documents produces by product/dev team where sent to ai and ask me to extend promptCape with document pseudonymization features. This is what he uses now and I just update the promptCape.com site to have this new version avalaible. Have a look if you want to protect PII in your documents sent to ai.

It happens at hugging face with stolen data and keys : https://huggingface.co/blog/security-incident-july-2026
Fortunately fixed now

With tools like PromptCape we address only partly the first block.

a talk which may be of interest for those who uses local ai models : TTL #181 - Deploying LLM on premise: let's review ... - Hyland Connect - 499461

No need for human hackers anymore.

Using a cve and the knowledge of the open source langflow product, an agentic program alone replaces human hackers : JADEPUFFER: Agentic ransomware for automated database extortion | Sysdig

Pokemon players were not aware that their scans are a very valuable ai asset for some domains : an interesting way of using data for training models to indirect goals we may be are not aligned with, but did not know at the time... -> How Pokémon Go players may have unknowingly helped train military AI | Cybernews

May be it will be the same with all the code and data we send to ai.

A new publication about the java obfuscation difficulties and why it is important to consider the frameworks : I tried to obfuscate my Java code before sending it to AI — here's what broke - DEV Community

Curious how others handle this. My situation: the client lets me use LLMs for coding, but explicitly asked that the actual source not be disclosed to a third party. So "just paste it into  a cloud model" is off the table for the sensitive parts, but going fully without an assistant  isn't realistic either.
I first tried keeping everything local. On a laptop the reasoning models were too slow to be usable (minutes per turn), and the smaller ones were unreliable — they'd "answer" without really reading the files. Moving to a server helped the speed a bit but the quality still wasn't there  for real work. Local felt like paying a lot to end up with a weaker assistant.
What I landed on instead: a workflow where the sensitive parts go through an obfuscating proxy before reaching the model — identifiers in code, comment and conf get renamed on the way out and restored on the way back,  so I keep a capable cloud model but the remote side never sees the real names/structure. I'm using promptCape for that piece, and so far it's held up.
 
But I'd like a reality check — how do you handle it?
- Local models good enough for you now, or same slowness/quality wall I hit?
- Obfuscation / proxy layer, and if so which?
- Air-gapped setups, contract clauses, or just not using AI on those parts at all?
 
Genuinely want to hear what's working for people under a "no disclosure" constraint.

The hard part of obfuscating source before sending it to an AI assistant is not renaming identifiers.

It's not renaming the ones a framework binds by name at runtime.

Rename a Spring Data findByStatusAndPriority method, a JPA u/Embeddable field, a Jackson JSON key, a Lombok-backed field, or a u/ConfigurationProperties field, and the code still compiles but breaks silently.

So I added open test fixtures for exactly this: small, real Maven apps (Spring Boot REST, plain JPA/Hibernate, Lombok, Spring config binding) each with deliberate names collisions.

A protected framework identifier sitting next to an obfuscatable look-alike.

Run the tests, obfuscate, re-run the tests: if green, the detectors kept the right names and renamed the rest.

Grouped by language alongside the existing Python ones (FastAPI/Flask/Django/Click). CC BY 4.0, fork-and-run applications/java/ : https://gitlab.com/gbreton7/promptcape-docs/-/tree/main/applications/java

Tested with promptCape but tell the community if works with others code protection assistants.