DEV Community: Genevieve Breton

Pandas pipelines through AI without leaking your column names

Genevieve Breton — Fri, 12 Jun 2026 09:36:56 +0000

Every other framework in this series leaked through identifiers. Pandas leaks through strings — and "never rewrite strings" was the rule that kept the whole pipeline safe.

The rule pandas breaks

Across the Python and Django articles, one rule held without exception: PromptCape never rewrites string literals. Strings are user-visible labels, error messages, template paths, MIME types, SQL fragments, data. Rewriting them is how you turn "Download CSV" into garbage on a button, or mime="text/csv" into a broken response. The whole reverse-apply story leans on it — strings are inert, only identifiers carry the rename.

Pandas is the framework where that rule fails. Consider one line:

df = df[df["churn_probability"] > 0.5]

There is no identifier here worth protecting. df is a throwaway local. 0.5 is a number. The business secret — the fact that this company scores customers on a churn probability model — lives entirely inside the string literal "churn_probability". And in any real pandas pipeline there are dozens of them: "annual_salary", "patient_diagnosis_code", "ltv_segment", "fraud_score". The column names are the schema, and the schema is the thing you don't want sitting in an AI provider's logs.

So pandas forces the uncomfortable thing: a scoped, deliberate exception to the never-touch-strings rule. Not "rewrite all strings" — that re-breaks everything the rule protected. Rewrite only strings the engine can prove are column names. The entire difficulty of pandas obfuscation is in the word prove.

Where column names hide

If column names only ever appeared as df["name"], this would be a one-line regex. They don't. A column name is any string sitting in a "column position", and pandas has a sprawling vocabulary of column positions:

Access pattern	Example	Column strings
Single subscript	`df["annual_salary"]`	`annual_salary`
List subscript	`df[["dept", "salary"]]`	`dept`, `salary`
Attribute access	`df.annual_salary`	`annual_salary` (as an identifier, not a string)
`.loc` / `.at`	`df.loc[:, "salary"]`, `df.at[0, "salary"]`	`salary`
Grouping	`df.groupby("department")`, `groupby(by=["a", "b"])`	grouping keys
Joining	`df.merge(other, on="employee_id")`, `left_on=`, `right_on=`	join keys
Sorting / indexing	`df.sort_values("hire_date")`, `df.set_index("id")`	sort/index keys
Reshaping	`df.pivot_table(index="dept", columns="year", values="salary")`	three sets of columns
Melting	`df.melt(id_vars="id", value_vars=["q1", "q2"])`	id + value columns
Renaming	`df.rename(columns={"old": "new"})`	keys and values both
Assignment	`df.assign(margin=...)`, `df["margin"] = ...`	new column names (identifier and string)
Named aggregation	`df.agg(avg_pay=("salary", "mean"))`	output kwarg `avg_pay` and source string `salary`
Typing / IO	`read_csv(usecols=[...], dtype={...}, names=[...], parse_dates=[...])`	every listed column
Query strings	`df.query("churn_probability > 0.5")`	column names inside an expression string

Three of these are genuinely nasty:

rename(columns={...}) carries column names in both the keys and the values of a dict literal. Miss the values and you leak every renamed column.
Named aggregation (df.agg(avg_pay=("salary", "mean"))) puts an output column name in a keyword-argument position — a Python identifier — while the source column sits in a string in the same call. One line, two different obfuscation mechanisms.
df.query("...") and df.eval("...") embed column names inside a mini-language that pandas parses at runtime. You can't treat the argument as an opaque string; you have to parse the expression, find the names, rewrite them, and re-serialize — or refuse and warn.

The detection problem: the schema isn't in the code

Every other detector in this series had it easy: the names it needed to find were declared somewhere. Pydantic fields are in the class body. Django models declare their fields. SQLAlchemy columns are Column(...) assignments. An AST scan finds the declaration site and you're done.

Pandas has no declaration site. A DataFrame's columns come from the data — the header row of a CSV, a SQL result set, a Parquet schema — none of which is in the source code:

df = pd.read_csv("s3://acme-hr/attrition_2026.csv")
# df now has 40 columns. None of their names appear anywhere in this file.
for col in df.columns:
    df[col] = df[col].fillna(0)        # every column touched, zero literals

This splits column names into two populations, and only one is reachable:

Population	Where it appears	Obfuscatable statically?
Referenced columns	As literals in code: `df["churn_probability"]`, `groupby("dept")`, `rename(columns=...)`	Yes — they're in the AST
Dynamic-only columns	Only in the data, touched via `df.columns`, `for col in df.columns`, `df.select_dtypes(...)`	No — the name never appears as a literal to rewrite

The honest framing PromptCape ships with: it obfuscates the column names that appear as literals in the code, because those are exactly the ones that would otherwise reach the AI. A column that's never named in the source can't leak through the source — it only leaks if the AI reads the data file, which is a separate problem (covered below). The PandasColumnDetector does an AST/LibCST scan of column-position contexts and collects every literal it finds into a project-wide column registry, hashed the same way identifiers are — churn_probability → col_e2d4b7c9 — so the mapping round-trips through reverse-apply exactly like fld_ and mtd_ names.

The type-inference trap: not every `x["string"]` is a column

Here is the bug that defined the whole subsystem.

The first version of the column detector treated every string subscript as a column name: any x["..."] got rewritten. It worked beautifully on pandas code and corrupted everything else:

# Before obfuscation
db_url = os.environ["DATABASE_URL"]
config = settings["feature_flags"]["new_dashboard"]
headers = {"Content-Type": "application/json"}
row = df["annual_salary"]

# After the naive obfuscator (three bugs and one correct rewrite)
db_url = os.environ["col_a1b2c3d4"]          # ← BUG: env var lookup now fails
config = settings["col_5e6f7a8b"]["col_..."] # ← BUG: dict keys mangled
headers = {"col_...": "application/json"}     # ← BUG: HTTP header broken
row = df["col_99c1d2e3"]                       # ← correct

os.environ["DATABASE_URL"], dict subscripts, JSON payloads — they all use the exact same syntax as a DataFrame column access. Subscript-with-a-string is not a pandas signal; it's a Python idiom. Rewriting it blindly turns a privacy tool into a code corrupter.

The fix is DataFrame-variable inference: only rewrite subscript strings on a variable the engine can show is a DataFrame. The sidecar tracks, per scope, which names are bound to a DataFrame by walking assignments:

Assigned from a constructor or IO call: pd.read_csv(...), pd.read_sql(...), pd.DataFrame(...), pd.read_parquet(...).
Assigned from a DataFrame-returning operation on a known DataFrame: df.copy(), df[mask], df.groupby(...).agg(...), df.merge(...), df.rename(...).
Annotated : pd.DataFrame in a parameter or variable.
A column-position keyword on a known pandas method (groupby(by=...), merge(on=...)) — here the method itself proves the argument is a column, even without var inference.

Strings subscripted on anything the engine can't prove is a DataFrame are left untouched. The trade-off is deliberate and stated: a DataFrame that arrives through an un-inferrable path (returned from a third-party function with no annotation, stored in a list, pulled from a dict) won't have its columns obfuscated. PromptCape chooses silent under-obfuscation over silent corruption — a leaked column name is a privacy miss; a rewritten os.environ key is a broken app. The first you can catch in review; the second wastes an afternoon.

Before / after

A real-shaped HR attrition pipeline. Watch the columns, the named aggregations, and notice what is kept.

Source the AI must never see:

import pandas as pd


def build_attrition_report(path: str) -> pd.DataFrame:
    df = pd.read_csv(path)
    df = df[df["employment_status"] == "active"]
    df["tenure_years"] = df["tenure_months"] / 12

    summary = (
        df.groupby("department")
          .agg(
              headcount=("employee_id", "count"),
              avg_salary=("annual_salary", "mean"),
              attrition_risk=("churn_probability", "mean"),
          )
          .reset_index()
          .sort_values("attrition_risk", ascending=False)
    )
    return summary

What the AI actually receives:

import pandas as pd


def mtd_3f2a1b0c(path: str) -> pd.DataFrame:
    fld_9c8d7e6f = pd.read_csv(path)
    fld_9c8d7e6f = fld_9c8d7e6f[fld_9c8d7e6f["col_4a1f8b2e"] == "active"]
    fld_9c8d7e6f["col_7d3e9a14"] = fld_9c8d7e6f["col_b6c2f085"] / 12

    fld_2e5a8c91 = (
        fld_9c8d7e6f.groupby("col_1f7b3d6a")
          .agg(
              col_c5e90a2b=("col_d40a1e77", "count"),
              col_88a1d3f4=("col_55b3e9c0", "mean"),
              col_e2d4b7c9=("col_aa1f2b30", "mean"),
          )
          .reset_index()
          .sort_values("col_e2d4b7c9", ascending=False)
    )
    return fld_2e5a8c91

The provider sees a function that filters, divides, groups, and aggregates. It does not see that this is attrition modelling, that employees have a churn_probability, or that the company tracks annual_salary. The shape of the analysis is intact; the meaning is gone.

Three things to notice in the diff:

attrition_risk round-trips as one name. It's created as a named-aggregation kwarg (attrition_risk=) and referenced three lines later in sort_values("attrition_risk"). Both became col_e2d4b7c9 — the registry is keyed by the real name, so a column that's born in .agg() and used in .sort_values() stays consistent. Get this wrong and the workspace raises KeyError: 'col_e2d4b7c9' because the sort references a column the agg never produced under that name.
"active" is untouched. It's a value, not a column. It stays readable — which is the runtime-data boundary discussed below, not an oversight.
pd, read_csv, groupby, agg, mean, count, reset_index, sort_values, ascending all survive. That's the PandasDetector's job, unchanged from earlier articles.

What does NOT change (and why)

Preserved	Why
Pandas API names — `read_csv`, `groupby`, `agg`, `merge`, `pivot_table`, `to_csv`, `value_counts`, `reset_index`, `fillna`, `astype`, …	`PandasDetector`: a fixed list of ~200 DataFrame/Series/IO method and attribute names. Renaming `to_csv` → `mtd_xxx` raises `AttributeError`
Aggregation function strings — `"mean"`, `"sum"`, `"count"`, `"first"`	These are pandas reduction names, not columns. They're a small fixed allow-list inside the column detector
Value literals — `"active"`, `"2026-01-01"`, `"USD"`	Data, not schema. PromptCape never rewrites values (see boundary section)
File paths — `pd.read_csv("attrition_2026.csv")`	A path, not a column. Subscript/kwarg position is what marks a column; a positional path argument to `read_csv` is not a column position
Dict / env / JSON subscripts — `os.environ["X"]`, `config["y"]`	The variable isn't an inferred DataFrame, so the string is left alone
`df` and other local variable names visible above	They are renamed (`fld_…`) — shown here only to contrast with the columns

The data-file leak (the other half)

Obfuscating df["churn_probability"] to df["col_e2d4b7c9"] in the code accomplishes nothing if the AI can open attrition_2026.csv and read this:

employee_id,department,annual_salary,churn_probability,employment_status
4471,Engineering,142000,0.12,active

Worse, there's a runtime conflict: the obfuscated code asks for a column col_e2d4b7c9 that the real CSV header calls churn_probability. The workspace won't even run — KeyError: 'col_e2d4b7c9'.

This is the same split the Python article drew for .env: a value that must exist at runtime but must not reach the AI's view of the workspace. PromptCape resolves pandas data files two ways depending on whether they're fixtures or real data:

Bundled sample/fixture data (small CSVs the repo ships for tests/demos) get their header row rewritten with the same column registry: employee_id,department,annual_salary,... → col_d40a1e77,col_1f7b3d6a,col_55b3e9c0,.... The workspace runs on the fixture, the obfuscated code matches the obfuscated header, and the AI sees neither the real names nor the real rows' meaning (values stay, but a header-less 0.12 leaks little).
Real production data stays in the source project and never enters the workspace, exactly like .env. promptcape run resolves the data path at launch and a thin pandas IO shim applies rename(columns=registry) immediately after each read, so the code's col_… names line up with the freshly-renamed frame. The real headers live only in the developer's source tree, never in ~/.promptcape/cache/<hash>/.

The principle is identical to the secrets story: the AI-visible workspace directory contains schema and structure, never the real vocabulary or the real rows.

Reverse-apply and AI-invented columns

When the AI adds a feature — "add a column flagging anyone above the 90th salary percentile" — it writes against the obfuscated frame:

fld_9c8d7e6f["col_new_flag"] = (
    fld_9c8d7e6f["col_55b3e9c0"] > fld_9c8d7e6f["col_55b3e9c0"].quantile(0.9)
)

Two cases on the way back:

References to existing columns (col_55b3e9c0) hit the registry and reverse-map cleanly to annual_salary. Same hash-resolver as identifiers.
The AI's new column is a name the AI invented. It's not in the registry, and that's fine — it's not a leak (the AI chose it, the provider never saw a real name). It comes back verbatim as whatever the AI typed (col_new_flag, or high_earner if it wrote a readable name). The developer reviews and renames to taste, identical to how AI-invented variable names are handled in the Java pipeline.

The one failure mode worth a guard: if the AI writes a col_xxxxxxxx-shaped string that collides with a registry hash it shouldn't (extraordinarily unlikely with 8 hex digits, but the resolver is strict), the pre-apply gate flags any col_ literal in the diff that maps to a column the surrounding code never read. In practice this never fires; it exists so a collision is loud rather than silent.

What this does NOT protect

The threat boundary is the same shape as the rest of the series, with one pandas-specific edge.

Threat	Protected?	By what
Column names reaching the AI provider	Yes	Column registry + scoped string rewriting
Business logic / pipeline shape	Partially	The operations are visible (a `groupby().agg()` is still a `groupby().agg()`); only the vocabulary is gone
Runtime data values in the AI's view	Only if data is kept out / fixtures are header-stripped	`promptcape run` data indirection; values themselves are never rewritten
Dynamic-only columns (never named in code)	Not via code obfuscation	They don't appear in source; they only leak if the data file does, which the data-file handling addresses
Columns inside un-inferrable DataFrames	No (deliberate)	Under-obfuscate rather than corrupt non-pandas subscripts

The honest line: PromptCape removes the schema vocabulary from what the AI sees. It does not pretend to hide that you're doing data analysis, nor to encrypt the numbers. For a column called churn_probability, the name is the secret — and that's what's gone.

Conclusion

Pandas is the framework that inverts the series' central rule. Everywhere else, the leak was in identifiers and strings were safe to ignore. In pandas the leak is the strings, because column names are the business vocabulary and they live as literals.

The three load-bearing ideas:

Scoped string rewriting, gated on proof. The fix isn't "rewrite strings now" — that re-breaks labels, paths, and dict keys. It's a column registry fed only by strings in proven column positions, hashed and reverse-mapped exactly like identifiers.
DataFrame-variable inference is the whole ballgame. x["str"] is the most overloaded syntax in Python. Without knowing x is a DataFrame, you either leak columns (too cautious) or corrupt os.environ (too eager). The detector errs toward under-obfuscation because a broken app is worse than a missed name you can catch in review.
The data file is half the problem. Obfuscating code while the AI can read attrition_2026.csv is theatre. Fixtures get header-rewritten; real data stays in the source and is renamed on load — the same secrets-never-touch-the-workspace principle as .env.

PromptCape ships open for trial at https://promptcape.com/ — free for 3 months, no credit card required. The PandasColumnDetector, the DataFrame-inference sidecar, and the data-file handling ship in the same JAR as the rest of the Python pipeline; the language is auto-detected from the source tree.

Django obfuscation for AI assistants: 6 invisible contracts we found the hard way

Genevieve Breton — Mon, 08 Jun 2026 09:47:44 +0000

A walkthrough of what broke each time we re-ran a Django test suite against an obfuscated workspace — and what we had to add to the detector to make the next round green.

The setup

PromptCape obfuscates source code before it reaches an AI assistant (Claude Code, Cursor, etc.) so the AI works on renamed identifiers rather than your real class, method, and field names. We've covered the Java pipeline and the general Python flow in earlier posts.

This post is about Django specifically. Django has more invisible name contracts than any framework we've integrated so far — strings inside Python code, in templates, in migration files, in URL configurations, in admin registrations, all referencing identifier names. The compiler can't catch them because Python has no compiler. The static import verifier can't catch them because they aren't imports. They surface only at the moment Django's introspection layer reaches for getattr(form, 'clean_<field>', None) and finds nothing.

The story below is the literal sequence of bugs that surfaced when we ran an obfuscated django-blog test app (Post / Comment / Tag models, CBVs + FBVs, ModelForm + standalone Form, admin registrations, pytest-django). Each bug exposed a contract; each contract drove a change to the DjangoDetector. Sixteen tests, six iterations to green.

Iteration 1 — `'django.db.migrations' has no attribute 'Cls_270e5090'`

First obfuscation. Tests fail immediately on collection:

ERROR tests/test_blog.py::test_post_creation_persists_all_fields
E   AttributeError: module 'django.db.migrations' has no attribute 'Cls_270e5090'
    blog/migrations/0001_initial.py:7: AttributeError

Line 7 of every Django migration file is:

class Migration(migrations.Migration):

The obfuscator picked up Migration from the class definition, registered it, and rewrote every subsequent occurrence — including migrations.Migration (the base class reference). Django's migrations module doesn't have an attribute Cls_270e5090, so the class can't be loaded.

The temptation: add Migration to a list of protected names. That handles one occurrence; the next line down is migrations.CreateModel(...), then migrations.AddField(...), then migrations.RunPython(...). There are roughly twenty operation classes and a handful of class-level attributes (initial, dependencies, operations, replaces, atomic). Worse, each CreateModel(name=..., fields=..., options=..., bases=..., managers=...) call uses kwargs that are extremely generic — name, fields, options, bases collide with every second user identifier in a real codebase. Adding them all to a project-wide exclusion list would gut obfuscation.

The right fix recognises that migration files are machine-generated. Django writes them via python manage.py makemigrations. The user never edits them by hand. They reference framework internals exclusively. There is nothing in them that needs to be renamed.

So: skip migrations/, alembic/, versions/ directories entirely. The obfuscator's collection pass doesn't visit them; the obfuscation pass doesn't rewrite them; they're copied to the workspace verbatim. Django's migrate command sees its expected files unchanged.

// ObfuscationEngine.java
private static final Set<String> MACHINE_GENERATED_DIR_NAMES = Set.of(
        "migrations", "alembic", "versions"
);

private boolean isInMachineGeneratedDir(Path relative) {
    for (int i = 0; i < relative.getNameCount(); i++) {
        if (MACHINE_GENERATED_DIR_NAMES.contains(relative.getName(i).toString())) {
            return true;
        }
    }
    return false;
}

There's no leak: the migration files reference model class names and field names that are already visible in models.py (which the AI does see, obfuscated). Migrations contain the same names the AI already has, in machine-generated form. Skipping them costs nothing.

Iteration 2 — `urlpatterns` doesn't appear to have any patterns

The same test, re-run:

django.core.exceptions.ImproperlyConfigured: The included URLconf 'mysite.urls'
does not appear to have any patterns in it. If you see the 'urlpatterns'
variable with valid patterns in the file then the issue is probably caused
by a circular import.

mysite/urls.py defines:

urlpatterns = [
    path("admin/", admin.site.urls),
    path("", include("blog.urls")),
]

The obfuscator picked up urlpatterns as a module-level assignment target and rewrote it. Django's URL resolver looks for the literal name urlpatterns in the imported URLconf module via getattr(module, "urlpatterns") — when it finds nothing, it reports "no patterns found."

This is the module-level convention pattern. Django reads a handful of named constants from urls.py files by exact name:

Name	Purpose
`urlpatterns`	The list of URL routes
`app_name`	Application namespace for `reverse('app_name:view_name')`
`handler400`, `handler403`, `handler404`, `handler500`	Custom error-view callables

These all need protection. They go into the project-wide Django API name list, applied unconditionally as soon as from django or import django appears anywhere in the project.

A few names in the same category that surfaced separately:

INSTALLED_APPS, MIDDLEWARE, DATABASES, TEMPLATES, ROOT_URLCONF, STATIC_URL, MEDIA_URL, LANGUAGE_CODE, SECRET_KEY, DEBUG, ALLOWED_HOSTS, AUTH_USER_MODEL, DEFAULT_AUTO_FIELD, etc. — settings.py module-level constants, all introspected by name.

Iteration 3 — `ModelForm has no model class specified`

Forms next:

ValueError: ModelForm has no model class specified.
  File ".../django/forms/models.py", line 362, in __init__
    if opts.model is None:
        raise ValueError("ModelForm has no model class specified.")

The user's PostForm:

class PostForm(forms.ModelForm):
    class Meta:
        model = Post
        fields = ["title", "slug", "body", "author", "published"]

    def clean(self):
        ...

After obfuscation:

class Cls_d367f020(forms.ModelForm):
    class Cls_7f994c64:               # <- was Meta
        fld_08db7fa3 = Cls_b8106b41   # <- was model = Post
        fld_b4a3ded4 = ["title", ...] # <- was fields = [...]

Three layers of damage:

Meta is the magic inner-class name Django introspects on every Form/ModelForm/Serializer/Model subclass. Renaming it makes the inner class invisible.
model is the attribute inside Meta that tells ModelForm which model to bind to.
fields is the attribute that lists which model fields to expose.

The fix: add Meta, model, fields (and the dozen other Meta attributes — widgets, error_messages, field_classes, localized_fields, help_texts, labels, read_only_fields, extra_kwargs, abstract, proxy, managed, app_label, indexes, constraints, get_latest_by, default_manager_name, default_related_name, ...) to the protected list.

model and fields are uncomfortably generic — they're going to over-protect plenty of unrelated user code. But the alternative is Django ModelForms not working at all. We took the trade.

This is the inner-class convention pattern: Django uses class Meta: inside another class to attach metadata. The outer class's behavior depends on Django finding Meta by literal name and reading its attributes by literal name.

Iteration 4 — `no such table: blog_cls_b8106b41`

Tests progressed to the DB layer:

django.db.utils.OperationalError: no such table: blog_cls_b8106b41

Django's ORM generates default DB table names from the model class name via app_label_classname.lower(). With:

class Post(models.Model):
    title = models.CharField(...)

Django creates table blog_post. The migration file (copied verbatim, see Iteration 1) declares that table. The obfuscated models.py declares:

class Cls_b8106b41(models.Model):
    title = models.CharField(...)

Django's ORM now expects table blog_cls_b8106b41. The migration created blog_post. The two never reconcile.

The fix is a small extension to the AST scan that detects models. The detector was already scanning classes that inherit from models.Model to extract field names — the same scan can emit the class name alongside the fields, with the reason "Django model class (drives db_table + migration refs)". Once the class name is protected, both the model declaration and the migration's CreateModel(name='Post', ...) references stay consistent.

# sidecar's detect_django_models command
for stmt in module.body:
    if not isinstance(stmt, libcst.ClassDef):
        continue
    if not _class_inherits_from(stmt, _DJANGO_MODEL_BASE_CLASSES, libcst):
        continue
    class_name = stmt.name.value
    fields = _scan_django_model_fields(stmt, libcst)
    if not fields:
        continue
    models_found += 1
    # Class name protects the DB table name and the migration's name='X' refs
    identifiers.append({"name": class_name, "kind": "class", ...})
    # Plus each field
    for field_name, factory in fields:
        identifiers.append({"name": field_name, "kind": "field", ...})

This is the string-derived name pattern: Django uses a Python identifier as a source for a string that gets stored in another system (DB schema, migration JSON, etc.). The class name has to be preserved end-to-end across the layers that aren't directly visible to the obfuscator.

Iteration 5 — empty post list when the database has posts

Render tests next:

def test_post_list_view_renders_published_posts(client, post, draft_post):
    resp = client.get(reverse("blog:post_list"))
    assert "Hello" in resp.content.decode()

Fixture post creates a Post with title="Hello" and published=True. The view should render it. The assertion fails — the page contains "No posts yet" instead.

The obfuscated PostListView:

class PostListView(ListView):
    model = Post
    fld_ede69551 = "blog/post_list.html"     # was template_name
    fld_475e135f = "posts"                   # was context_object_name
    fld_6b917593 = 10                        # was paginate_by

    def mtd_0729535b(self):                  # was get_queryset
        return Post.objects.filter(published=True)

Django's CBV machinery looks for template_name, context_object_name, paginate_by, and get_queryset by literal getattr name. When they're renamed, the base ListView.get() method picks up its defaults instead: no template (falls back to a synthesised one), default context name (object_list), default queryset (Post.objects.all() — which excludes the published filter), no pagination. The test loaded the page successfully but saw an empty queryset because the user's get_queryset override was effectively gone.

The fix is to add the CBV introspection points to the API name list:

CBV class attributes: template_name, template_name_field, template_name_suffix, context_object_name, paginate_by, paginator_class, page_kwarg, queryset, form_class, form_kwargs, success_url, initial, slug_url_kwarg, pk_url_kwarg, slug_field, raise_exception, redirect_field_name.
CBV methods: get_queryset, get_context_data, get_object, get_form_class, get_form_kwargs, get_form, get_initial, get_template_names, get_success_url, get_absolute_url, form_valid, form_invalid, dispatch, setup, as_view, http_method_not_allowed, http_method_names.
Implicit hooks: post_save, pre_save, post_delete, pre_delete.

CBV class-attribute names are the declarative-attribute convention pattern: you declare class-level attributes whose names match what the framework's base class expects to read, and you override methods whose names match what the base class's dispatcher calls. Same shape as Spring's @Bean-on-method or JPA's @Entity-on-class — declarative metadata, but expressed in Python via name conventions instead of decorators.

Iteration 6 — `clean_body` silently disappears

Last failure, on the standalone form:

class CommentForm(forms.Form):
    author_name = forms.CharField(max_length=100)
    body = forms.CharField(widget=forms.Textarea())

    def clean_body(self):
        body = self.cleaned_data["body"].strip()
        if len(body) < 5:
            raise forms.ValidationError("Comment body too short")
        return body

The test expects a 5-char minimum to fail validation:

def test_comment_form_requires_minimum_body_length():
    form = CommentForm(data={"author_name": "alice", "body": "tiny"})
    assert not form.is_valid()      # AssertionError: form IS valid

The obfuscated form:

class Cls_xxx(forms.Form):
    author_name = forms.CharField(max_length=100)
    body = forms.CharField(widget=forms.Textarea())

    def mtd_f10d53d5(self):                          # was clean_body
        body = self.cleaned_data["body"].strip()
        if len(body) < 5:
            raise forms.ValidationError("Comment body too short")
        return body

The method body is identical. The method NAME changed. Django's BaseForm._clean_fields() iterates over declared fields and does:

clean_method = getattr(self, f"clean_{name}", None)
if clean_method is not None:
    value = clean_method()

getattr(self, "clean_body", None) returns None. The user's validator silently never runs. The form accepts "tiny" and the test fails — not with a clear AttributeError, but with not form.is_valid() being False instead of True.

This is the discover-by-name pattern, analogous to:

pytest's def test_* discovery
Spring Data's findByX derived queries
Lombok's getX() from a field x

The fix extends the form AST scan: in addition to declared fields, walk the class body's FunctionDef children and collect any whose name matches clean_<field> or validate_<field> (DRF uses the latter prefix on serializers). Add them to the exclusion list with the reason "Django form clean_X method (Django discovers by name)".

# sidecar's detect_django_forms command
def _scan_django_form_clean_methods(class_def, libcst) -> list[str]:
    methods: list[str] = []
    for member in class_def.body.body:
        if not isinstance(member, libcst.FunctionDef):
            continue
        name = member.name.value
        if name.startswith("clean_") or name.startswith("validate_"):
            methods.append(name)
    return methods

The trade-off is mild: a user method called clean_audit_log (not actually a Django form clean method) won't be obfuscated. But the prefix is specific enough that the false-positive rate is low and the trade is worth it.

What the detector looks like at the end

After iterations 1-6, the DjangoDetector is the largest Python detector in PromptCape, with four complementary passes:

Fixed list, ~360 names, applied project-wide on any from django / import django. Includes the Field types, Manager/QuerySet methods, ORM aggregates (Count/F/Q/OuterRef/...), CBV bases + class attribute names + method names, FBV decorators (@login_required, @require_POST, @api_view, ...), HTTP responses + shortcuts, URL routing (path, re_path, include, urlpatterns, app_name, handler400–500), Forms/ModelForms/Serializers, Admin (ModelAdmin, list_display, ...), Auth shortcuts, settings keys (INSTALLED_APPS, MIDDLEWARE, ...), the Meta inner-class convention + its 25+ attribute names.
AST scan of models via detect_django_models: emits the model class name AND every name = models.XField(...) field with the factory name. Skips Meta, objects, _*.
AST scan of views via detect_django_views: emits CBV class names (subclasses of View/ListView/...incl. DRF APIView/ViewSet) AND FBV function names — detected by request first param in a file named views.py OR by a known Django/DRF view decorator.
AST scan of forms via detect_django_forms: emits form/serializer class field names AND clean_<field> / validate_<field> method names.

Plus the structural rule: migrations/, alembic/, versions/ directories are copied verbatim, never obfuscated, never collected.

On the test app it produces roughly:

Framework detection [Django]: 360 API + 12 model fields + 7 views + 6 form names = 385 rules in 1.4s

For comparison, the other Python detectors:

stdlib-common-attrs:    230 names (always on)
python-dotenv:            3 keys
pytest:                  78 fixtures + 16 test names
PydanticDetector:       102 API + AST-scanned BaseModel fields
FastApiDetector:         76 names
FlaskDetector:           82 names + view function AST scan
CeleryDetector:         ~130 names + AST-scanned task function + every parameter
ClickTyperDetector:      ~80 names + AST-scanned command function + every parameter
RequestsHttpxDetector:  ~110 names (Response attrs, request kwargs, exceptions; no AST scan)

Django needs every other framework combined, in rule count alone. The structural complexity is in the same ballpark.

Why discover-by-name is the recurring shape

Six iterations, six different name contracts, but the same underlying shape every time:

A Python framework asks "does this object have an attribute whose name is exactly X?" by string at runtime, where X is derived from the user's identifier names.

Iteration	Where the lookup happens	Form of the string
1 (migrations)	`getattr(migrations_module, 'Migration')`	Imported class name
2 (urlpatterns)	`getattr(urlconf, 'urlpatterns')`	Module-level constant name
3 (Meta)	`getattr(form_class, 'Meta')`	Inner class name
4 (model class name)	DB schema generation + migration `name='Post'`	Class name → string in another system
5 (CBV attrs)	`getattr(self, 'template_name')` etc.	Class attribute / method name
6 (clean_body)	`getattr(self, 'clean_body')`	Method name following a prefix convention

There is no compile-time check for any of these in Python. The framework's runtime does the lookup. If the lookup fails, the framework's fallback path runs — and the fallback is almost always silently wrong (default behavior instead of the user's override).

This is what makes proactive detection mandatory for Python frameworks. The reactive approach — obfuscate, run, see what breaks — doesn't even reliably surface the bugs. Django's CBV fallback to defaults (Iteration 5) didn't crash; it rendered an empty list. The form's silent validation skip (Iteration 6) didn't crash; the form accepted invalid data. A test suite is the only thing that catches them — and only if the test suite exercises the exact path that depends on the override.

The fix for each iteration is mechanical. The discipline is to enumerate every contract the framework has, in advance, and bake them into the detector before the first user reports a bug. The django-blog test app in PromptCape's repo exists specifically to surface these regressions on every release. Sixteen tests, one of which (test_comment_form_requires_minimum_body_length) exists because Iteration 6 silently happened to a real codebase first.

Conclusion

Django obfuscation for AI assistants isn't fundamentally different from any other Python framework integration: detect the framework, scan the project, build an exclusion list. What's different is the density of contracts. Models, views, forms, admin, settings, migrations, templates — every layer has names that double as strings, and the strings live in different places (other Python files, database schemas, generated migrations, HTML templates, URL configurations).

The four-pass design (fixed list + 3 AST scans) plus the verbatim-copy rule for machine-generated directories cover the surface as we currently understand it. New regressions will surface; each one will be one more entry in the detector. The pattern doesn't change — only the list grows.

Three takeaways for anyone integrating with a similar framework:

Enumerate name contracts upfront. Every place the framework does getattr(obj, 'string') at runtime is a contract. Find them in the framework's source code if you have to; don't wait for production breakage.
AST scans beat fixed lists when the contract is structural. "Every field of every BaseModel/models.Model subclass" is shorter to express as a scanner than as a hand-maintained list of every field name ever used.
Machine-generated files don't belong in the obfuscation pipeline. Migrations, alembic, anything you can regenerate from a command — copy verbatim, never rewrite. Whatever they expose to the AI is already exposed via the human-written source code, and rewriting them creates more failure modes than the obfuscation it provides.

PromptCape is open for trial at https://promptcape.com/ — free for 3 months, no credit card required. The Django detector + the 15 other Python framework detectors ship in the same JAR; the language and framework set are auto-detected from the source tree. The django-blog test app that drove the iterations in this post is in the public docs repo at gitlab.com/gbreton7/promptcape-docs/-/tree/main/applications/django-blog for anyone who wants to reproduce the cycle.

Python obfuscation for AI assistants: runnable workspaces and off-disk secrets

Genevieve Breton — Wed, 03 Jun 2026 08:21:06 +0000

Why obfuscating Python for AI tools requires a different mental model than Java — and how .env handling becomes the load-bearing question.

Java vs Python: a different relationship with the workspace

Obfuscating Java for an AI assistant is — at heart — about producing a workspace that still compiles. The developer rarely runs the obfuscated workspace directly; they let the AI work in it, apply the changes back to source, and run the app from there. Compilation is the contract. If mvn test-compile passes after obfuscation, you're 95% done.

Python is a fundamentally different game. There is no compile step. The workspace's "validation" happens at runtime, when the developer fires up:

streamlit run dashboard.py
pytest -v
python main.py
uvicorn main:app --reload

If a framework introspects a class name, a function name, a string in a URL pattern, or a Pydantic field — and that name was rewritten by the obfuscator — the error surfaces only when Python tries to call it. There is no compiler to catch it for you.

That changes the obfuscator's job in three concrete ways:

What you protect changes. Identifier names that double as string identifiers (template references, JSON keys, test discovery names) become the primary battle, not the secondary one.
What you check after obfuscation changes. A Python --verify step can't compile; it has to do static import resolution and let runtime catch the rest.
What you do with secrets changes. A Java workspace is read-only for the AI. A Python workspace is run by the developer, which means real values have to be available somewhere — and the naive choice (copy .env to the workspace) instantly defeats the obfuscation's purpose.

This article walks through each of those, then explains the promptcape run pattern: how to give the Python workspace the env vars it needs at launch time without ever writing them to disk in the AI-visible location.

Names that double as string contracts

In Java, framework conventions usually leave a compile-time trace: a missing getName() from a Lombok-renamed field throws cannot find symbol at javac time. You can detect it, you can auto-fix it. Spring Data derived queries (findByActiveTrue) are the rare exception that bites at startup, not at compile time — and that's already documented as a hard case.

Python frameworks are full of conventions like Spring Data. Names are silent contracts:

Framework	Identifier	Contract
Pydantic v2	`class User(BaseModel): email: str`	`email` is the JSON key in every `user.model_dump()` call. Rename it, every API consumer breaks silently.
Flask	`def index(): ...` decorated with `@bp.route("/")`	The function name becomes the default endpoint string for `url_for("blog.index")` and `{{ url_for('blog.index') }}`. Rename it, every redirect and template link 500s with `werkzeug.routing.BuildError`.
Django	`class Post(models.Model)`	The class name drives the DB table (`app_label_post`) AND every migration reference. Rename it, your `INSERT` query targets a table that doesn't exist.
SQLAlchemy	`id = Column(Integer, primary_key=True)`	`id` is the column name on the table. Plus it's accessed as `instance.id` everywhere.
pytest	`def test_login_succeeds(...)`	pytest discovers tests by the `test_` prefix. Rename to `mtd_xxx`, pytest collects 0 tests — your CI silently passes with no signal.
dataclass / attrs	`@dataclass class Post: title: str`	Field names are accessed as `obj.title`, dumped via `asdict()` and rendered in Jinja templates as `{{ post.title }}`.
Django forms / DRF serializers	`def clean_email(self): ...`	Django discovers field-level validators by the literal `clean_<field>` / `validate_<field>` name. Rename it, your validation silently disappears.
Celery	`@shared_task def send_email(recipient, subject)`	`send_email.delay(recipient="alice@…")` serialises the kwarg name through the broker (Redis, RabbitMQ). The worker reconstructs the call as `send_email(recipient=…)`; rename the parameter to `p_xxx` and the worker raises `TypeError: got an unexpected keyword argument 'recipient'`. Affects function name AND every parameter name.
Click / Typer	`@click.option("--config") def run(config)`	Click maps the CLI option `--config` to the Python kwarg `config` by string. Rename the parameter and the CLI call `run --config foo.yaml` raises `TypeError: got an unexpected keyword argument 'config'`. Affects every option/argument parameter.

All of these are invisible at "compile" time (which doesn't exist anyway). They fail at runtime, often in the form of a 500 in the second route the AI touches.

The fix has to be proactive detection, not reactive. For each framework, scan the project for the relevant declarations and add the discovered names to a project-wide exclusion list before identifier collection. The PromptCape codebase has 16 Python detectors today, 11 of which run an AST scan (the rest are pure import-check + fixed name lists):

PydanticDetector       AST scan: every BaseModel/RootModel field name
SqlalchemyDetector     AST scan: every declarative-model column / relationship
StreamlitDetector      AST scan: every top-level callable in streamlit scripts
FlaskDetector          AST scan: every @bp.route / @bp.get / @bp.errorhandler view
DataclassDetector      AST scan: every @dataclass / @attrs.define field
PytestDetector         AST scan: every def test_* / class Test* in the project
DjangoDetector         AST scan: model class+fields, CBV+FBV view names, form fields + clean_X methods
CeleryDetector         AST scan: every @app.task / @shared_task — function name + every parameter
ClickTyperDetector     AST scan: every @click.command / @app.command — function name + every parameter
RequestsHttpxDetector  Fixed list: ~110 names (Response attrs, request kwargs, exceptions); no AST scan
StdlibCommonAttrsDetector   ~230 stdlib method names (close, year, keys, items, split, …) — fixed list

The AST scans run via a bundled Python sidecar that parses each candidate file with LibCST and emits the discovered names back to the Java engine as JSON. The engine merges every detector's output into a single exclusion set before the obfuscation pass starts.

--verify for Python: import resolution, not compilation

Java's --verify runs mvn test-compile and reads javac output. There's a one-line equivalent on the Python side: there is none.

Python's closest analogue is importlib.util.find_spec(...). Given a dotted name like staffing.database, it returns None if the module can't be located, or a ModuleSpec if it can. The catch: it executes the parent package's __init__.py while looking. If staffing/__init__.py does from .database import sqlalchemy_stuff, then find_spec transitively imports SQLAlchemy, your DB driver, and probably half your app.

That's a non-starter for an obfuscation verification step: you don't want to import the user's code, you don't want the user's third-party dependencies installed in the sidecar's Python interpreter, and you definitely don't want side effects (database connections opened at module import time — a real Python anti-pattern, but common).

The strategy PromptCape ended up with classifies each import statement at the AST level and routes it to a different check:

Import shape	Check
`import xmlrpc.client` (top-level is a stdlib name)	`importlib.util.find_spec("xmlrpc.client")` — safe, stdlib never has side effects
`from staffing.database import X` (top-level is a workspace-local directory)	Check that `workspace/staffing/database.py` or `workspace/staffing/database/__init__.py` exists on disk. Never imports the file.
`import sqlalchemy` (third-party)	Skipped. Can't verify without the project's virtualenv installed alongside the sidecar — too much false-positive noise. Trust it.

This catches the canonical bug — import xmlrpc.client rewritten to import xmlrpc.fld_b8460726 when a user identifier client lands in the registry — without needing any project dependencies to be installed where the obfuscator runs.

It does NOT catch runtime AttributeError on stdlib instances (e.g. today.year where year was renamed because the user has a function called year). For those, the proactive detector pattern is the only option: a StdlibCommonAttrsDetector with ~210 of the most-commonly-accessed stdlib attribute names, applied unconditionally. The trade-off is real (user methods literally called year won't be obfuscated either) but the alternative is a workspace that crashes on the first date in the codebase.

Comments and docstrings: line count is the load-bearing property

Java obfuscation strips comments to // Processed. while preserving line count, because the reverse-apply 3-way merge needs 1:1 line correspondence between the source and the obfuscated cache.

Python has the same requirement but two distinct constructs:

Line comments (# something) — analogous to Java's // something.
Docstrings ("""multi-line""") — strings that are the first statement of a Module / FunctionDef / ClassDef body.

Stripping both is straightforward. The line-count preservation is what takes care:

# Original                          # After obfuscation
"""Module docstring                 """Processed.
spanning four
lines.
"""                                 """
                                    (4 newlines, same span)

def foo():                          def mtd_xxx():
    """Function docstring."""           """Processed."""
    return 42                           return 42

# A line comment                    # Processed.

For multi-line docstrings the rule is: count the \n characters in the original string value, emit """Processed. + N newlines + """. Stays on the same number of source lines so any File "...", line 243 in a traceback still points at the same source line in both versions.

The first version of the docstring stripper had a subtle bug: it assumed FunctionDef.body was always an IndentedBlock (the multi-line form, def foo():\n body). One-liner functions like def foo(): return 1 use a SimpleStatementSuite body — a totally different LibCST node type — and the stripper crashed with 'SimpleStatementSuite' object is not subscriptable. The exception was caught and the whole file was silently copied verbatim to the workspace, which manifested days later as ImportError: cannot import name 'OdooClient' (the import line was preserved as-is in the verbatim copy while the class definition was renamed in the obfuscated odoo_client.py).

The fix is mechanical (handle both body shapes), but the lesson is general: in Python obfuscation, the silent verbatim fallback is a foot-gun. The diagnostic command is worth memorising:

# Lists every .py in the workspace that has zero obfuscation markers
for f in $(find ~/.promptcape/cache/<hash> -name "*.py" -size +10c); do
  count=$(grep -c "fld_\|mtd_\|Cls_\|Processed" "$f")
  [ "$count" = "0" ] && echo "VERBATIM: $f"
done

Files that come out are either empty placeholders (fine — conftest.py is often empty in test suites) or fell through the fallback (file the bug).

The .env problem

This is the question that splits Python obfuscation from Java obfuscation more than anything else.

A Java workspace is typically read-only for the AI. The developer obfuscates, the AI works in the obfuscated copy, the developer applies changes back to source, and the app runs from the source project (with the real .env, the real application.properties, the real DB). The obfuscated workspace's job is to be readable, not runnable.

A Python workspace gets run by the developer. They iterate. They open Streamlit. They run pytest. They start the dev server. That requires real config values at runtime — but .env files are pure secrets: API keys, database URLs, OAuth client secrets. There is no "structure" to preserve in a .env file the way there is in application.properties (where keys are part of the architecture and values are leaf secrets). It's secrets all the way down.

The first iteration of the Python pipeline ran the existing Java sanitizer on .env:

# Original .env
DATABASE_URL=postgres://prod-db.acme.com:5432/myapp
SECRET_KEY=hunter2
ACTIVITY_MONTHS=6

# Sanitized .env (copied to workspace)
DATABASE_URL=REDACTED
SECRET_KEY=REDACTED
ACTIVITY_MONTHS=REDACTED

The first time the developer ran streamlit run from the workspace, it crashed instantly:

ValueError: invalid literal for int() with base 10: 'REDACTED'
  File ".../dashboard.py", line 243, in <module>
    ACTIVITY_MONTHS = int(os.getenv('ACTIVITY_MONTHS', '6'))

ACTIVITY_MONTHS=6 is not a secret. It's a config knob. But the sanitizer was uniform: redact everything because some entries are sensitive. That works for Java where the workspace doesn't run, but it instantly bricks the Python use case.

Three options surfaced:

Option	Workspace runs?	AI sees secrets?
A. Copy `.env` verbatim	Yes	Yes (any tool that reads files sees them)
B. Sanitize all values	No (crashes on first int/bool/URL parse)	No
C. Sanitize selectively (heuristics for "looks like a secret")	Maybe (depends on heuristic quality)	Mostly no

A and B are bad in different ways. C is fragile — every secret format you don't think of becomes a leak, and every config value that happens to match the heuristic becomes a crash.

The fix that actually worked is to recognise that the workspace doesn't need .env on disk at all. It needs the env vars at the moment a child process starts. There's a layer between "secrets at rest" and "secrets in the running app's environment" that PromptCape can sit on.

`promptcape run`: inject `.env` at subprocess launch, never on disk

The pattern is borrowed from how 12-factor apps deploy in containers: the orchestrator reads the secret store at container start time and exports keys into the process environment. The container image itself contains no secrets.

Translated to PromptCape:

promptcape obfuscate writes the workspace without .env. A small file .env.promptcape-pointer is written instead, with the absolute path to the source .env and instructions to use promptcape run. The AI sees the pointer if it opens it — that's intentional; we want the indirection documented.
promptcape run <command> is a wrapper that:
- Resolves the source project from the current working directory (same mechanism as promptcape apply / promptcape status).
- Parses <source>/.env and <source>/.env.local with a minimal python-dotenv-compatible parser.
- Spawns <command> with cwd = workspace, the child's environment populated from the current OS env layered with the parsed .env entries.
- Inherits stdin/stdout/stderr so the child has a real TTY (colors, prompts, progress bars all work).
- Propagates the child's exit code.

The flow:

# Source project: ~/projects/my-streamlit-app/.env
# DATABASE_URL=postgres://prod-db.acme.com:5432/myapp
# SECRET_KEY=hunter2
# ACTIVITY_MONTHS=6

cd ~/projects/my-streamlit-app
promptcape obfuscate --language python --verify .
# -> ~/.promptcape/cache/a1b2c3d4/
#    ├── (the obfuscated code)
#    └── .env.promptcape-pointer    (text file, no values)

cd ~/.promptcape/cache/a1b2c3d4
promptcape run streamlit run dashboard.py
# 1. reads ~/projects/my-streamlit-app/.env
# 2. spawns `streamlit run dashboard.py` in cwd=workspace
# 3. child environment: OS env + DATABASE_URL=postgres://... + SECRET_KEY=hunter2 + ACTIVITY_MONTHS=6
# 4. streamlit starts normally; os.getenv('DATABASE_URL') returns the real value

For pytest, the same shape:

promptcape run pytest -v
# tests run against the obfuscated source, with real env vars injected at child launch

For Java apps using Spring Boot's relaxed binding (DATABASE_PASSWORD env var overrides database.password property), the SAME command works without any extra plumbing:

promptcape run mvn spring-boot:run
# Spring Boot reads OS env vars (precedence rank 5) before application.properties (rank 8).
# The sanitized application.properties in the workspace has database.password=REDACTED.
# The OS env var DATABASE_PASSWORD=real overrides it. App starts with real credentials.
# No .env ever copied to the workspace.

Three properties this gets right:

Secrets never touch the AI-visible workspace directory. An AI tool with file-read access can grep ~/.promptcape/cache/<hash> all it wants — there are no values to find.
Explicit failure mode. If the developer runs pytest directly (without promptcape run), the app starts with no env vars and crashes at the first os.getenv('REQUIRED_KEY'). That's loud, it's traceable, and it's correct — they're missing the wrapper.
No code change in the user's project. load_dotenv() calls in the user's code become a graceful no-op (no .env to find), but os.getenv('KEY') finds the value in the child environment. The framework's startup path is unchanged.

The downside: developers have to remember to use promptcape run. The mitigation is documentation (.env.promptcape-pointer is the first place they look when something doesn't read env vars), the proxy/Cursor-terminal integration (which can wrap launches automatically), and a clear failure message when the wrapper is forgotten.

The complete Python cycle

1. pytest                              -> GREEN (source is healthy)
2. promptcape obfuscate --verify       -> Obfuscated workspace created
                                          .env NOT copied; pointer file written
3. promptcape run pytest               -> GREEN (workspace runs with real env vars
                                          injected at subprocess launch)
4. AI modifies obfuscated code
5. promptcape run pytest               -> GREEN (AI changes work in the runtime)
6. promptcape apply                    -> Changes applied to source
7. pytest                              -> GREEN (de-obfuscated changes work)

Each step has a specific failure mode:

Step 2 → 3: if the workspace fails to run, it's almost always a framework-name collision the detectors missed. The fix is to grep the obfuscated workspace for the obfuscated identifier (grep -rn "mtd_098fd2b6" .) to see what real name the AI sees in context, then add it to the relevant detector. Real-world examples that surfaced this way: cursor.close() (sqlite3 Cursor method), today.year (datetime.date attribute), df.value_counts().to_dict() (pandas chain), engine.connect() (SQLAlchemy lifecycle). Each got added to the protected list once.
Step 5 → 6: the AI invented an obfuscated name that's not in the registry. The reverse-apply step has a hash-resolver that maps Cls_e5f6a7b8 patterns back to known real names. Same mechanism as Java.
Step 6 → 7: rare — usually means the AI introduced a syntax error. The pre-apply --compile-gate check (which for Python is the static import verifier) catches most of these.

A note on what this does NOT protect

It is worth being explicit about the threat boundary, because Python's open-source nature makes the question come up naturally: if my distributed Python app ships as .py files anyone can read, why bother obfuscating it for the AI in the first place?

The answer is that those are two different threats living in two different lifecycle stages.

Threat	When	Who reads the source	What protects
AI-provider transit	Development sessions (Claude Code, Cursor, Aider…)	Anthropic / OpenAI / Mistral on their servers	PromptCape — obfuscate before sending, reverse-map the reply
End-user inspection	After product release	Anyone who installs the `.py`, `.pyc`, or PyInstaller bundle	Native compilation (Nuitka, Cython), commercial obfuscators (PyArmor), or SaaS-only deployment

PromptCape's obfuscated workspace lives in ~/.promptcape/cache/<hash>/ on the developer's own machine, only during AI sessions. It never ships with the product. After promptcape apply, the developer's source tree is back to real names. Whatever the developer builds and distributes is independent of whether they used PromptCape that day or not.

The two layers are also independent in the opposite direction: a Nuitka-compiled binary doesn't help the developer at all while they're prompting Claude with their real source code — that's not when end users are looking, that's when the AI provider's logs are being written. A developer who needs both protections uses both: PromptCape during development, Nuitka at release. The combination covers the full lifecycle.

Specifically on Python distribution effort levels:

.py files: readable as-is. Zero effort.
.pyc-only (python -m compileall): decompiles cleanly in seconds with decompyle3 or uncompyle6.
PyInstaller / cx_Freeze / py2exe: embed .pyc inside a bundle that pyinstxtractor cracks open in 5–10 minutes.
PyArmor (commercial): custom encrypted loader. Hours-to-days of reverse-engineering effort depending on the obfuscation level chosen.
Nuitka or Cython: compile Python through C to a real native binary. Days-to-weeks of effort for a determined reverser. The strongest open-source option.
SaaS / cloud-only: the only mathematically tight answer — if the code never leaves your servers, no one can read it on their disk.

This isn't a Python-specific issue. Java has the same shape — .class files in a .jar decompile cleanly with jd-gui / CFR / Procyon, and the traditional answer is ProGuard or R8 name-mangling at release-build time, which is conceptually identical to what PromptCape does at AI-session time but applied at a different lifecycle point. The two layers don't replace each other; a Java product that ships obfuscated bytecode AND uses PromptCape during development covers both transit and distribution leaks.

Conclusion

Python obfuscation for AI assistants is not a port of the Java pipeline. The fundamental shift — the developer runs the workspace, not just reads it — changes every layer: what you protect (name contracts, not just identifiers), how you verify (file existence, not compilation), and how you handle secrets (inject at subprocess launch, never on disk).

The three insights from building this:

Names that double as strings are the hard cases, and they're proactive-only. No compile error catches def index() → def mtd_xxx() when Flask looks up the endpoint string "blog.index". The detector has to know the framework's discovery rules in advance.
A silent verbatim fallback hides bugs for days. If a file fails to obfuscate, the engine must surface that loudly. The .env.promptcape-pointer and the verbatim-detection grep snippet exist precisely because the failure mode is silent otherwise.
.env doesn't need to be on disk in the workspace. The wrapper-injection pattern (promptcape run) gives the workspace real values at runtime without ever writing them to the AI-readable directory. This is the load-bearing pattern that makes the rest of the security story coherent: if the developer can run the workspace and the secrets never leave the source project, the AI assistant has zero attack surface on credentials.

PromptCape ships open for trial at https://promptcape.com/ — free for 3 months, no credit card required. The Python pipeline, the 16 framework detectors, and the promptcape run wrapper ship in the same JAR as the Java pipeline; the language is auto-detected from the source tree.

The AI Code Protection Landscape: 13 Products Compared

Genevieve Breton — Mon, 01 Jun 2026 10:05:20 +0000

A practical comparison of tools that protect source code and sensitive data from leaking to AI assistants — across deployment model, target user, and lifecycle coverage.

The problem

When developers use AI coding assistants — Claude Code, Cursor, GitHub Copilot, Cody, Aider — they implicitly send source code, comments, and configuration values to a remote server they do not control. For most companies that is a regulatory, contractual, or competitive risk: customer data inside test fixtures, IP inside class names, credentials inside config files, business logic spelled out in comments.

A growing market of products tries to address some part of this. They are not all the same product. Several are not even in the same category. This article maps 13 of them across three axes that actually matter at decision time:

Deployment model. Does the data leave your network, and to whom?
Target user. Is this a developer's tool that disappears into the IDE, or a CISO's tool that sits at the network gateway?
Lifecycle coverage. Does it just block or redact on the way out, or does it round-trip — obfuscate, let the AI work, apply changes back to the real code, and verify the build?

The third axis is where most products in this space stop short.

The three axes in detail

Axis 1 — On-premise vs SaaS

If your threat model is "no proprietary code on third-party servers", then a product that requires sending your prompts through its own SaaS before forwarding to OpenAI/Anthropic is a substitution, not a solution: you swapped one third party for another. The configurations that actually fit this threat model are:

Strict on-premise: the product runs as a binary, container, or library inside your network. Examples: Presidio, LLM Guard, NeMo Guardrails, PromptCape (CLI mode), Quieta.
Hybrid proxy: the engine runs locally and sanitizes prompts; the LLM call goes out to whatever provider you choose. Examples: PromptCape (proxy mode), ChatWall Box, ZeusLock self-hosted.
SaaS-only: the product itself is a cloud service. Examples: GCP DLP, Lakera Guard, Skyflow, Cypher AI, Code Integrity.

A SaaS-only choice is not wrong — it is a different trade-off. If your data already lives in GCP, GCP DLP is a sensible choice. If you cannot send code to a third-party cloud at all, it is a non-starter.

Axis 2 — CISO tool vs developer tool

Two product shapes coexist in this market and they are easy to confuse:

CISO/governance tools sit at the network egress. They scan outbound prompts for PII, secrets, and policy violations; log hits; raise alerts; produce audit trails. They are bought by security teams and imposed on developers — often visible to the dev only as "the thing that occasionally blocks my prompt." Adoption is enforced top-down.
Developer tools integrate where the developer already works (IDE terminal, CLI, plugin, library). They aim to be invisible — same workflow, same commands, the obfuscation happens transparently. Adoption is bottom-up, driven by zero added friction.

Most products are clearly one or the other. A few try to be both and end up not great at either. When a developer tool adds friction (extra step, copy-paste, context switch), developers route around it. When a CISO tool is exposed too directly to developers without sandboxing, it gets disabled or bypassed.

Axis 3 — Coverage of the full cycle

For non-code data (a customer name in a chat prompt), redact-on-the-way-out is enough. For code, you need round-trip: the AI's response has to land in the repo with the original names, comments, and structure restored — and the result must compile and pass tests. Otherwise the developer manually patches the AI's output, which destroys the productivity gain that motivated the AI in the first place.

Specifically, full-cycle code protection requires:

Forward obfuscation that does not break framework conventions (Spring Data derived queries, JPA entity names in JPQL, Lombok-generated accessors, Jackson serialization, Bean Validation, OpenAPI schemas)
An obfuscated workspace where the code still compiles and tests still pass
Reverse application that only modifies AI-changed lines (preserves comments and formatting on untouched lines)
Resolution of names the AI invented during its work (variables it created based on the obfuscated identifiers it saw)
Build/test verification on the de-obfuscated source

Most products in this list cover none of that. That is not a flaw — they are solving a different problem. Conflating "we redact PII in chatbot prompts" with "we let developers safely use Cursor on a closed-source codebase" leads to bad procurement decisions.

Comparison table

Product	Deployment	OSS	Domain	Target user	Full code cycle?	Distinguishing feature
ChatWall	Browser extension only (Firefox)	Partial (source-available)	DLP for AI web chat (browser overlay)	End-user	Partial (chat-overlay reversal)	Local-only token substitution for ChatGPT/Claude.ai/Gemini web UIs; very early adoption stage
Cypher AI	Hybrid (client-side encryption + vendor or sovereign compute)	No	Encrypted LLM inference (TFHE)	CISO	No	Customer-managed keys; multi-scheme FHE (TFHE / BFV / CKKS / Paillier); 128-bit post-quantum lattice-based; ~400× speedup vs Microsoft SEAL at 10M records; deployments in defense, Tier-1 finance, biometric infrastructure
Google Cloud DLP	SaaS (GCP)	No	Generic PII redaction + tokenization	CISO	Partial (de-id reversible, not code-aware)	150+ infoTypes; native to BigQuery / GCS
Lakera Guard	SaaS	No	Prompt-injection guardrails	Mixed	No	Real-time AI/agent attack detection
Limina AI	On-prem (VPC container)	No	PII / PHI / PCI redaction	CISO	Partial (PII reversal, not code)	Context-aware detection across 50+ entity types and 52 languages; healthcare/finance positioning
LLM Guard (Protect AI)	On-prem	Yes (MIT)	LLM I/O guardrails	Developer	Partial (code is banned, not obfuscated)	~35 input/output scanners around an LLM call
Microsoft Presidio	On-prem	Yes (MIT)	Generic PII redaction	Mixed	Partial (no code reverse)	Pluggable PII recognizers in Python; broadly deployed
NVIDIA NeMo Guardrails	On-prem	Yes (Apache 2.0)	Dialogue safety	Developer	No (out of scope)	Programmable Colang DSL for conversational containment
PromptCape	On-prem (CLI + proxy)	No	Code obfuscation	Developer	Yes	Java & Python; obfuscate → AI → apply → build verify; Cursor/VS Code terminal integration
Quieta	On-prem (desktop app)	No	Generic PII redaction	End-user	Partial (copy-paste workflow)	macOS/Windows app; "paste → mask → AI → restore" in one click, fully local
Skyflow	SaaS	No	Data vault + tokenization	CISO	No	"LLM Privacy Vault" for sensitive customer data
TitanOne	Both (self-hosted + SaaS)	No	PII redaction for AI	CISO	Partial (no code awareness)	Context-preserving substitution + re-enrichment of LLM responses with original values
ZeusLock (Zeus DLP)	Both (EU SaaS + sovereign on-prem)	No	DLP + secrets + Shadow AI detection	Mixed	Partial (no source-code awareness)	Browser extension + CLI + IDE + MCP coverage; blocks AI tools that train on data (Shadow AI Detection)

Reading the table by axis

By deployment

Strict on-premise (no third-party server in the loop except the LLM you choose to call): Presidio, LLM Guard, NeMo Guardrails, PromptCape, Quieta, Limina (VPC container), ChatWall (purely local extension) — plus the on-prem deployment options of TitanOne, ZeusLock, and Cypher AI (for defense and regulated industries).

SaaS-only (your prompts/data hit the vendor's cloud first, then maybe go to an LLM): GCP DLP, Lakera Guard, Skyflow. Cypher AI is SaaS-by-default but with a cryptographic twist — prompts arrive encrypted under TFHE so the vendor sees no plaintext even on its own servers.

Hybrid proxy (engine runs locally, LLM call goes out to whatever provider you pick): PromptCape, ZeusLock self-hosted. This configuration gives you both control and access to frontier models — the engine is yours, the model is theirs, and the bridge is yours.

By target user

Developer-first (IDE-seamless): PromptCape (Cursor/VS Code terminal profile), LLM Guard (library wrapping LLM calls in your code), NeMo Guardrails (library or local server for LLM apps), ZeusLock (browser extension + CLI + IDE plugins). These integrate where the developer already is and add little or no friction.

CISO/governance-first: Skyflow, GCP DLP, Lakera, Limina, TitanOne, Cypher AI. Strong dashboards, policies, audit trails, compliance certifications. Developers see them as the thing that gates their prompts; adoption requires top-down enforcement.

End-user / individual: Quieta (desktop app for pre-paste anonymization), ChatWall (Firefox extension for browser chat overlays). Bought and installed by individual users one at a time, no enterprise console.

Generic / mixed: Presidio (library that can be wrapped in either direction).

By coverage of the full cycle

For source code specifically, only PromptCape advertises the full cycle: obfuscate the project → AI iterates on the obfuscated workspace → apply only AI-changed lines back → verify the source still compiles and tests still pass. Everything else in this list either:

(a) does redaction without round-trip (Presidio, GCP DLP, Lakera, ChatWall, ZeusLock when applied to code-containing prompts),
(b) does round-trip but only on free-text data — not on code that has to compile against framework conventions (Limina, TitanOne, Quieta), or
(c) is in a different category entirely (NeMo dialogue safety, Cypher FHE inference, LLM Guard input/output scanning).

That gap exists because the round-trip on code is much harder than on text. You have to handle Spring Data derived queries (findByActiveTrue is the query), JPA entity name strings in @Query annotations, Lombok-generated accessor names, comment stripping vs. preserving line counts, AI-invented variable names, build artifacts that should not flow back, and you have to verify the result compiles and passes tests. A redaction library is a few hundred lines; the round-trip is an order of magnitude more work.

Categorical, not directly comparable

It is misleading to put all 13 products in one ranked list — they live in different categories. Roughly:

Category	Products	What they actually do
Generic PII / DLP	Presidio, GCP DLP, Limina, TitanOne, Quieta, ChatWall, ZeusLock	Detect sensitive entities in text and redact, mask, or tokenize them
LLM I/O guardrails	LLM Guard, Lakera Guard, NeMo Guardrails	Sit between app and LLM; detect prompt injection, jailbreaks, scan input/output for policy violations
Data vaults / tokenization	Skyflow	Store sensitive data in a vault; replace with tokens for downstream use including AI
Encrypted inference	Cypher AI	Run inference on data that stays encrypted end-to-end (FHE)
Code obfuscation for AI coding	PromptCape	Obfuscate source before AI sees it; round-trip back with build verification

If your problem is "we send PII into a chatbot," go to row 1. If your problem is "prompt-injection or jailbreaks in our AI app," go to row 2. If your problem is "our source code is being trained on by a model vendor," only row 5 answers the question.

A pragmatic decision matrix

Protecting customer PII inside chat or RAG prompts → CISO-driven. Skyflow, GCP DLP, Limina, TitanOne, ZeusLock. Pick on deployment constraints (regulated cloud vs. on-prem VPC), language coverage, and existing data infrastructure.

Protecting against prompt-injection and jailbreaks in your AI app → developer-driven. LLM Guard (free, OSS) or NeMo Guardrails (free, OSS) for in-process; Lakera (commercial SaaS) for managed.

Protecting AI agents that call tools (MCP-style integrations) → developer + CISO. NeMo Guardrails for input-side containment; ZeusLock for MCP-protocol monitoring at the network layer.

Cryptographic guarantee that even the LLM provider — and even the privacy vendor itself — cannot read the data → CISO-driven. Cypher AI: prompts are encrypted client-side under TFHE with customer-managed keys; inference runs on encrypted tensors; only the user decrypts the output. Strong fit for defense and regulated finance. Alternative: self-host a private LLM via AWS Bedrock / Azure OpenAI / Vertex with private endpoints — gives you trust-based isolation rather than mathematical isolation, but no FHE overhead.

Protecting your team's source code while still using Claude Code / Cursor / Copilot every day → developer-driven, full cycle. PromptCape. Java & Python today, more languages on the roadmap. The unique slot in this list — no other product in our set round-trips real code through framework conventions and verifies the build.

Just a desktop or browser tool to clean text before pasting into a web AI → individual user. Quieta (desktop, macOS/Windows), or ChatWall (Firefox extension; very early stage at the time of writing).

Honesty about gaps in this comparison

The line between "AI security" and "data privacy" is fuzzy and many products straddle it. We have categorized by primary marketing claim, not by every adjacent capability.
Pricing is omitted from the table because it changes constantly and most enterprise products do not publish it. Where pricing is publicly listed, it is mentioned in the text.
This is not exhaustive. Notable adjacent products not included: GitHub Copilot Enterprise data controls, Anthropic / OpenAI zero-retention enterprise tiers, AWS Bedrock / Azure OpenAI / Vertex private deployments, Tabnine self-hosted, Cody Enterprise, Sourcegraph Cody on-prem.
All products were assessed from public web pages on a single research pass. Vendor positioning shifts quickly in this market — verify before purchase.

Conclusion

The AI privacy / code-protection space is crowded but not duplicative. Most products are solving genuinely different problems and only collide on the executive's PowerPoint slide labelled "AI Security."

If you are a CISO setting policy on AI use across the organization, your shortlist is in the generic PII/DLP and LLM I/O guardrails rows. Pick the one that fits your existing stack and compliance regime — most of them are good at what they do.

If you are a developer who wants to keep using AI coding assistants without sending real source code to a third party, the field narrows fast. The full cycle — obfuscate before, work transparently in the IDE, apply back, and verify the build — is currently only addressed end-to-end by PromptCape. That is a technical gap, not a marketing one: round-tripping code through framework conventions and a 3-way merge is harder than redacting names from free text, and the rest of the market has reasonably chosen the easier problem.

Both directions are valid and not in competition with each other. A mature AI strategy probably involves one product from each row of the categorization above: a DLP layer at egress, a guardrail layer around your AI apps, a tokenization layer for stored sensitive data, and — if developers in your org code in the IDE every day with AI assistants — a code-obfuscation layer that closes the loop between the IDE and the model.

PromptCape is open for trial at https://promptcape.com/ — free for 3 months, no credit card required. The companion deep-dive on what makes the Java cycle hard is in Java Code Obfuscation for AI Assistants: Ensuring the Full Cycle Works.

References

Links to the 13 products reviewed in this article, in the order they appear in the comparison table. All URLs verified May 2026.

ChatWall — Firefox extension for browser AI chat anonymization
Cypher AI — TFHE-based encrypted LLM inference with customer-managed keys; multi-scheme FHE (TFHE/BFV/CKKS/Paillier); 128-bit post-quantum; ~400× faster than Microsoft SEAL on 10M records; NVIDIA Inception member, validated by 2 independent security agencies
Google Cloud DLP / Sensitive Data Protection — managed PII redaction and tokenization
Lakera Guard — real-time AI/agent attack detection
Limina AI — context-aware PII / PHI / PCI redaction in VPC containers
LLM Guard — input/output scanners around LLM calls (Protect AI)
Microsoft Presidio — open-source PII redaction framework
NVIDIA NeMo Guardrails — programmable conversational containment
PromptCape — Java & Python code obfuscation proxy for AI coding assistants
Quieta — local-only desktop anonymizer (macOS / Windows)
Skyflow — data vault and tokenization
TitanOne — AI Data Firewall with context-preserving substitution and response re-enrichment
ZeusLock / Zeus DLP — DLP, secrets detection, and Shadow AI Detection for AI tooling

PromptCape vs PromptBase: similar names, different products

Genevieve Breton — Tue, 26 May 2026 14:40:32 +0000

I keep getting the same question: "Is PromptCape the same thing as PromptBase?"

No. They're different products solving different problems for different audiences. The names look alike, the spaces overlap (both are AI-adjacent), and Google sometimes autocorrects one to the other. This short article exists to make the distinction explicit — for humans, and for search engines.

If you're here because you typed "promptcape" into Google and landed on PromptBase, this article is the bridge.

PromptBase, in one paragraph

PromptBase is a marketplace for AI prompts. Designers, copywriters, and AI hobbyists list prompts they've engineered for image models (Midjourney, Stable Diffusion, DALL·E) and for text models (ChatGPT, Claude). Buyers download the prompts and use them to generate their own content. Think of it as Etsy for prompt engineering. It launched in 2022 and has been growing steadily as the "selling prompts as digital products" niche matured.

Target user: anyone who uses AI tools to generate content (visual, marketing, copy) and wants higher-quality prompts than they could write themselves.

Problem solved: distribution and monetization of prompt engineering as craft.

PromptCape, in one paragraph

PromptCape is a Java code obfuscation proxy for AI coding assistants. It sits between your IDE (Claude Code, Cursor, Mistral) and the AI API, renames every identifier in your source code — InvoiceService becomes Cls_a1b2c3d4, customerName becomes fld_e5f6a7b8 — sends the obfuscated version to the AI, then reverses the rename on the way back. The AI works on the obfuscated code without ever seeing your real class names, package structure, or business domain language. It targets developers and teams who have IP protection clauses, NDAs, or compliance requirements that constrain what can be sent to cloud-based AI tools.

Target user: Java developers and engineering teams who want to use AI coding assistants without exposing proprietary source code to AI training corpora or third-party logs.

Problem solved: keeping source code IP private while still benefiting from AI coding assistance.

Side by side

	PromptBase	PromptCape
What it is	Marketplace for AI prompts	Code obfuscation proxy for AI assistants
Audience	Content creators, designers, marketers	Software developers and engineering teams
Primary value	Buy/sell pre-engineered prompts	Protect source code from AI cloud APIs
Used for	Image generation, copywriting	Java coding with Claude Code / Cursor / Mistral
Touches your code?	No	Yes — that's the whole point
Pricing	Per-prompt purchases	Free for 3 months, then paid license
Founded	2022	2026

The overlap is zero. PromptBase is about the inputs (prompts as digital products). PromptCape is about the inputs and the outputs of an AI coding loop, with a strong focus on what leaves your machine.

Why the names look so close

Both names start with "Prompt" because both are in the AI space. The follow-on word makes the difference:

PromptBase — "Base" as in database, foundation, the collection where prompts live and are exchanged.
PromptCape — "Cape" as in the garment that shields; a cape over your code before it travels to the AI.

I picked "Cape" for the protection metaphor, knowing the proximity to existing names was a risk. The metaphor is the whole product positioning: your code is protected when it goes out and comes back.

Which one do you actually need?

"I want to find a great Midjourney prompt for a vaporwave cityscape" → PromptBase.
"I want to find a great ChatGPT prompt for cold sales emails" → PromptBase.
"I want to use Claude Code on a private Java repo without sending real class names to Anthropic" → PromptCape.
"My client added a no-AI-assistants clause and I want to comply without giving up AI productivity" → PromptCape.
"I work in a regulated industry (banking, health, defense) and need to obfuscate source identifiers before AI calls" → PromptCape.

If you're a developer and the latter sounds relevant, the landing page is at promptcape.com. If you're looking for prompts to buy, you want promptbase.com.

No rivalry, no overlap. Just two products with names that happen to start with the same five letters.

Building a transparent terminal-based proxy for Claude Code in Cursor (or any IDE)

Genevieve Breton — Thu, 21 May 2026 16:18:14 +0000

The previous two articles in this series (part 1: obfuscation, part 2: the 3-way merge) were about what happens to your code. This one is about what happens to your developer.

I had a CLI that could obfuscate a Java project, send it to Claude, and merge the changes back. The pipeline worked. But the actual day-to-day flow was: run a CLI command to obfuscate, copy the obfuscated workspace path, paste it into Claude Code, work in Claude, copy the AI's output back, run another CLI command to merge. Five context switches per AI interaction. Nobody — including me — was going to use it twice.

The friction was the integration. Every IDE has its own way of talking to Claude or to OpenAI. Cursor has its own Claude pane, JetBrains has its own AI assistant, VS Code has Copilot. I was not going to build a plugin for each one, maintain it, watch them break every release.

The shortcut that solved it: a transparent localhost HTTP proxy. About 200 lines of code, no IDE plugin, no Cursor extension, no fork of anything. The developer types claude in Cursor's built-in terminal and PromptCape is silently between them and the API.

This article is the how of that proxy: the architectural choice, the five traps that made it harder than I expected, and why this approach generalizes to almost anything that talks to an LLM.

The decision: don't wrap the IDE, wrap the network

When you set out to integrate a tool into an IDE, the obvious-looking path is to write a plugin. JetBrains has its plugin API, VS Code has its extension model, Cursor has its own integrations. You quickly realize:

Each IDE has its own API, packaging, and review process.
AI features inside each IDE evolve fast — every release threatens to move where the conversation hooks live.
For a tool that has to see every prompt and every response, you end up reimplementing the wire protocol per IDE anyway.

The shortcut nobody mentions: every modern AI coding assistant respects a base URL environment variable. Claude Code uses ANTHROPIC_BASE_URL. The OpenAI ecosystem (which Cursor and many others speak) uses OPENAI_BASE_URL. Set it, and the client points at your server instead of api.anthropic.com or api.openai.com.

That collapses the integration problem from "write N IDE plugins" to "run a reverse proxy on localhost." One code path. Every IDE that respects the env var works for free.

The mental model:

 Cursor terminal               PromptCape proxy        Anthropic API
 ┌─────────────┐  obfuscation  ┌──────────────┐  HTTPS  ┌──────────┐
 │   claude    │ ────────────► │  localhost   │ ───────►│  real    │
 │   (CLI)     │ ◄──────────── │   :8077      │ ◄───────│  API     │
 └─────────────┘   de-obf'd    └──────────────┘   obf'd └──────────┘

From Cursor's point of view, the user opened a terminal and ran claude. There is no extension. There is no patched binary. The proxy is invisible to the IDE because the IDE was never the integration point — the network was.

The bare minimum

Stripped of the obfuscation logic, the proxy is uncomfortably simple. A Javalin-based catch-all that takes any POST, rewrites the body, forwards it to the real API, and pipes the response back:

app.post("/*", ctx -> {
    String body = ctx.body();
    String rewritten = interceptRequest(body);
    HttpRequest req = HttpRequest.newBuilder()
        .uri(URI.create(targetBaseUrl + ctx.path()))
        .POST(HttpRequest.BodyPublishers.ofString(rewritten))
        // ... forward headers, minus hop-by-hop
        .build();
    HttpResponse<String> resp = httpClient.send(req,
                             BodyHandlers.ofString());
    ctx.status(resp.statusCode());
    ctx.result(interceptResponse(resp.body()));
});

If your "interception" is a no-op, that's a transparent proxy. The two interception methods are where obfuscation happens — translating real names → obfuscated names on the way out, and obfuscated → real on the way back.

The thing that surprised me is how little IDE knowledge is needed. The IDE never sees the proxy, never knows the URL was rewritten, never knows the conversation passed through anything. The contract is HTTP and a base URL.

Trap 1: streaming responses

The first version handled responses with BodyHandlers.ofString() — buffer the whole response, transform, return. Claude Code uses streaming responses (SSE — server-sent events). The first time I tested under real load, the user-visible behavior was: silence for 8 seconds, then the entire answer dumped at once.

Streaming isn't a nice-to-have. Developers expect tokens to flow as they're generated; that's a big chunk of what "feels like AI" is. You have to forward chunks as they arrive and de-obfuscate them on the fly.

The Java HTTP client supports BodyHandlers.ofInputStream(), which gives you an open socket. You read SSE events line by line, run each one through the de-obfuscation pass, write it back to the client's output stream, flush after each event boundary:

HttpResponse<InputStream> resp = httpClient.send(req,
                         BodyHandlers.ofInputStream());
try (BufferedReader r = new BufferedReader(new 
                InputStreamReader(resp.body(), UTF_8));
     OutputStream out = ctx.outputStream()) {
    String line;
    while ((line = r.readLine()) != null) {
        String processed = processor.processLine(line);
        out.write(processed.getBytes(UTF_8));
        out.write('\n');
        if (line.isEmpty()) out.flush();// SSE event boundary
    }
}

The subtlety is in processor.processLine. SSE events look like:

event: content_block_delta
data: {"type":"content_block_delta",
       "index":0,
       "delta":{
          "type":"text_delta",
          "text":"InvoiceService"}}

You can't just regex-replace on the raw line — InvoiceService might be split across two chunks (Invoice in one, Service in the next) by the server's tokenizer. The processor maintains a small carry-over buffer that holds the trailing bit of the previous chunk, joins it with the new chunk, runs the replacement, then writes everything except a tail of length max-mapping-length back out.

This is the kind of thing that doesn't show up in unit tests with full strings but breaks the moment a real API tokenizes mid-identifier. The fix is mechanical once you see it — but you'll only see it if you test against the real API, not a mocked one.

Trap 2: accept-encoding

This one cost me a day. The proxy was buffering responses fine, but the de-obfuscation logic was matching zero identifiers. The response body looked like binary garbage in the logs.

The cause: I was faithfully forwarding the IDE's request headers — including accept-encoding: gzip, br. The real API obliged and returned a gzipped response. My text-based interceptor parsed the gzipped bytes as if they were JSON, found no identifiers to replace, and forwarded the still-gzipped bytes to the client. The client decompressed them on its end, so the user saw a plausible response — but with no obfuscation reversal.

The fix is one line: strip accept-encoding from the forwarded request. Now the API returns uncompressed JSON, the interceptor sees text, the round trip works.

private static final Set<String> HOP_BY_HOP_HEADERS = Set.of(
    "host", "connection", "keep-alive", "transfer-encoding",
    "te", "trailer", "upgrade", "content-length",
    "accept-encoding" // ← critical: keep responses uncompressed
);

Worth a half-line comment in the code. It's the kind of single-character mistake that produces a silently wrong system, not a noisy crash.

Trap 3: don't translate tool blocks

Claude's API content isn't a flat string. It's a list of typed blocks:

{
  "messages": [{
    "role": "user",
    "content": [
      {"type": "text", 
       "text": "Refactor InvoiceService to use Optional"},
      {"type": "tool_result", 
       "tool_use_id": "...", 
       "content": "package com.acme; ..."},
      {"type": "tool_use", 
       "id": "...", 
       "name": "read_file", 
       "input": {"path": "..."}}
    ]
  }]
}

The user-typed text needs translation: InvoiceService → Cls_a1b2c3d4. But the tool_result block contains the contents of a file the AI just read — from the obfuscated workspace. It's already obfuscated. If I run it through the translator, nothing visibly happens (the obfuscated names don't match the real-name patterns), but the moment a real name accidentally appears in a comment that survived stripping, you've now obfuscated something inside a string that came from an already-obfuscated context. It rapidly gets harder to round-trip.

The fix: walk the content array, look at the type field, only translate "text" blocks. Leave "tool_result" and "tool_use" blocks untouched.

for (JsonNode block : contentArray) {
    String type = block.path("type").asText("");
    if ("text".equals(type) && block.has("text")) {
        ((ObjectNode) block).put("text", 
          translateText(block.get("text").asText()));
    }
    //tool_use, tool_result → leave alone, already in obfuscated space
}

This is the corollary of the bigger architectural choice: the AI works in an obfuscated workspace, not just on obfuscated prompts. The file system the AI sees through read_file is the obfuscated cache directory. Everything it reads is already obfuscated. The proxy only needs to translate the human-readable channel: what the user types, and what the AI replies in text.

Trap 4: HTTP/2 pseudo-headers

This was the obscure one. The Java HTTP client speaks HTTP/2 to modern APIs. HTTP/2 has pseudo-headers — :status, :method, :path — that are legal at the protocol layer but illegal in HTTP/1.1 responses. My proxy was happily copying every response header from the API back to the Cursor terminal, including :status. Some clients tolerate this; some (Claude Code) reject the response.

apiResponse.headers().map().forEach((name, values) -> {
    String lower = name.toLowerCase();
    if (lower.startsWith(":")) return;// skip HTTP/2 pseudo-headers
    // ... forward the rest
});

One of those bugs that exists at the protocol seam between two HTTP versions. The Java HTTP client gives you the HTTP/2 headers in their HTTP/2 form, and you're shipping them to a client that may or may not be reading HTTP/2 framing. Filter aggressively.

Trap 5: making it forget-about-it-able

A foreground proxy in a terminal works for a demo. For daily use, developers want the proxy running quietly in the background so they can open a new terminal and claude immediately. So the CLI grew a --detach mode:

Spawn a child JVM running the proxy in the foreground.
Inherit env (so the license key propagates).
Redirect stdout/stderr to ~/.promptcape/proxy.log.
Write the child PID to ~/.promptcape/proxy.pid.
Wait up to 5 seconds for the port to come up, then exit.

ProcessBuilder pb = new ProcessBuilder(cmd);
pb.redirectErrorStream(true);
pb.redirectOutput(ProcessBuilder.Redirect.appendTo(logFile.toFile()));
pb.redirectInput(new File(isWin ? "NUL" : "/dev/null"));

Process child = pb.start();
Files.writeString(pidFile, String.valueOf(child.pid()));

Plus a --stop that's idempotent (returns 0 if the proxy is already gone — a stale PID file isn't an error), and a --logs that tails the log file with the rotation handling you'd expect.

These are the kinds of features users discover they need three days in. "How do I see what the proxy is doing without restarting it in the foreground?" — --logs. "I don't remember if the proxy is running, can I just run --stop to be safe?" — yes, it's idempotent. None of this is technically deep, but skipping it makes the tool feel rough.

The Cursor angle: there is no Cursor angle

Here's the punchline. Once you have a localhost reverse proxy that respects ANTHROPIC_BASE_URL, integrating with Cursor isn't a feature. It's the absence of one.

The workflow inside Cursor:

Open Cursor.
Open the built-in terminal (Ctrl+`).
Run promptcape proxy --detach (or have it running already from a startup script).
Run ANTHROPIC_BASE_URL=http://localhost:8077 claude — or just claude if you exported the env var.
Use Claude Code normally.

There is no Cursor plugin to install. There is no JSON config to edit. There is no .cursorrules file to set up. The terminal is just a shell, the shell respects environment variables, the env var changes the API endpoint, the proxy does the rest.

That's the win. The integration cost — for me, for the user, for every future IDE — collapsed to nothing.

You can wrap it up as a small launcher script. I called mine pcc (PromptCape Claude). It does export ANTHROPIC_BASE_URL=...; exec claude "$@". Three lines. The user types pcc instead of claude and everything is obfuscated end to end.

Why this generalizes

I think the broader takeaway is worth more than the specific implementation:

If a tool you want to integrate with reads an HTTP endpoint, write a reverse proxy before you write a plugin. The endpoint is the integration point. The plugin is at best a config helper around the same indirection.

This applies far beyond AI tooling. Anything that talks to a SaaS API and respects a base URL — analytics, observability, payments — can be sandboxed, intercepted, transformed, or replayed with the same pattern. Plugins are per-IDE; proxies are per-protocol. Per-protocol wins.

The specific lesson for AI tooling: the prompt and the workspace are different channels. Translating the workspace (the file system the AI reads through tools) and translating the prompt (the human-typed text) are two different problems. Conflate them and you double-obfuscate. Keep them separate, type-tagged content blocks make this trivial, and the proxy stays small.

If you want to see the proxy code in full, the streaming SSE processor, and the conversation samples (real-name in, obfuscated-name on the wire, real-name back), the worked examples are in gitlab.com/gbreton7/promptcape-docs. This is the third and last article of the PromptCape series — obfuscation pipeline, 3-way merge, transparent proxy. MRs welcome on the docs repo if you've integrated this pattern with an IDE I haven't tried.

Building a transparent terminal-based proxy for Claude Code in Cursor (or any IDE)

Genevieve Breton — Thu, 21 May 2026 16:18:14 +0000

The previous two articles in this series (part 1: obfuscation, part 2: the 3-way merge) were about what happens to your code. This one is about what happens to your developer.

This article is the how of that proxy: the architectural choice, the five traps that made it harder than I expected, and why this approach generalizes to almost anything that talks to an LLM.

The decision: don't wrap the IDE, wrap the network

Each IDE has its own API, packaging, and review process.
AI features inside each IDE evolve fast — every release threatens to move where the conversation hooks live.
For a tool that has to see every prompt and every response, you end up reimplementing the wire protocol per IDE anyway.

That collapses the integration problem from "write N IDE plugins" to "run a reverse proxy on localhost." One code path. Every IDE that respects the env var works for free.

The mental model:

 Cursor terminal               PromptCape proxy        Anthropic API
 ┌─────────────┐  obfuscation  ┌──────────────┐  HTTPS  ┌──────────┐
 │   claude    │ ────────────► │  localhost   │ ───────►│  real    │
 │   (CLI)     │ ◄──────────── │   :8077      │ ◄───────│  API     │
 └─────────────┘   de-obf'd    └──────────────┘   obf'd └──────────┘

The bare minimum

Stripped of the obfuscation logic, the proxy is uncomfortably simple. A Javalin-based catch-all that takes any POST, rewrites the body, forwards it to the real API, and pipes the response back:

app.post("/*", ctx -> {
    String body = ctx.body();
    String rewritten = interceptRequest(body);
    HttpRequest req = HttpRequest.newBuilder()
        .uri(URI.create(targetBaseUrl + ctx.path()))
        .POST(HttpRequest.BodyPublishers.ofString(rewritten))
        // ... forward headers, minus hop-by-hop
        .build();
    HttpResponse<String> resp = httpClient.send(req,
                             BodyHandlers.ofString());
    ctx.status(resp.statusCode());
    ctx.result(interceptResponse(resp.body()));
});

Trap 1: streaming responses

HttpResponse<InputStream> resp = httpClient.send(req,
                         BodyHandlers.ofInputStream());
try (BufferedReader r = new BufferedReader(new 
                InputStreamReader(resp.body(), UTF_8));
     OutputStream out = ctx.outputStream()) {
    String line;
    while ((line = r.readLine()) != null) {
        String processed = processor.processLine(line);
        out.write(processed.getBytes(UTF_8));
        out.write('\n');
        if (line.isEmpty()) out.flush();// SSE event boundary
    }
}

The subtlety is in processor.processLine. SSE events look like:

event: content_block_delta
data: {"type":"content_block_delta",
       "index":0,
       "delta":{
          "type":"text_delta",
          "text":"InvoiceService"}}

Trap 2: accept-encoding

This one cost me a day. The proxy was buffering responses fine, but the de-obfuscation logic was matching zero identifiers. The response body looked like binary garbage in the logs.

The fix is one line: strip accept-encoding from the forwarded request. Now the API returns uncompressed JSON, the interceptor sees text, the round trip works.

private static final Set<String> HOP_BY_HOP_HEADERS = Set.of(
    "host", "connection", "keep-alive", "transfer-encoding",
    "te", "trailer", "upgrade", "content-length",
    "accept-encoding" // ← critical: keep responses uncompressed
);

Worth a half-line comment in the code. It's the kind of single-character mistake that produces a silently wrong system, not a noisy crash.

Trap 3: don't translate tool blocks

Claude's API content isn't a flat string. It's a list of typed blocks:

{
  "messages": [{
    "role": "user",
    "content": [
      {"type": "text", 
       "text": "Refactor InvoiceService to use Optional"},
      {"type": "tool_result", 
       "tool_use_id": "...", 
       "content": "package com.acme; ..."},
      {"type": "tool_use", 
       "id": "...", 
       "name": "read_file", 
       "input": {"path": "..."}}
    ]
  }]
}

The fix: walk the content array, look at the type field, only translate "text" blocks. Leave "tool_result" and "tool_use" blocks untouched.

for (JsonNode block : contentArray) {
    String type = block.path("type").asText("");
    if ("text".equals(type) && block.has("text")) {
        ((ObjectNode) block).put("text", 
          translateText(block.get("text").asText()));
    }
    //tool_use, tool_result → leave alone, already in obfuscated space
}

Trap 4: HTTP/2 pseudo-headers

apiResponse.headers().map().forEach((name, values) -> {
    String lower = name.toLowerCase();
    if (lower.startsWith(":")) return;// skip HTTP/2 pseudo-headers
    // ... forward the rest
});

Trap 5: making it forget-about-it-able

Spawn a child JVM running the proxy in the foreground.
Inherit env (so the license key propagates).
Redirect stdout/stderr to ~/.promptcape/proxy.log.
Write the child PID to ~/.promptcape/proxy.pid.
Wait up to 5 seconds for the port to come up, then exit.

ProcessBuilder pb = new ProcessBuilder(cmd);
pb.redirectErrorStream(true);
pb.redirectOutput(ProcessBuilder.Redirect.appendTo(logFile.toFile()));
pb.redirectInput(new File(isWin ? "NUL" : "/dev/null"));

Process child = pb.start();
Files.writeString(pidFile, String.valueOf(child.pid()));

Plus a --stop that's idempotent (returns 0 if the proxy is already gone — a stale PID file isn't an error), and a --logs that tails the log file with the rotation handling you'd expect.

The Cursor angle: there is no Cursor angle

Here's the punchline. Once you have a localhost reverse proxy that respects ANTHROPIC_BASE_URL, integrating with Cursor isn't a feature. It's the absence of one.

The workflow inside Cursor:

Open Cursor.
Open the built-in terminal (Ctrl+`).
Run promptcape proxy --detach (or have it running already from a startup script).
Run ANTHROPIC_BASE_URL=http://localhost:8077 claude — or just claude if you exported the env var.
Use Claude Code normally.

That's the win. The integration cost — for me, for the user, for every future IDE — collapsed to nothing.

Why this generalizes

I think the broader takeaway is worth more than the specific implementation:

Reverse-applying AI changes to obfuscated code: a 3-way merge that actually works

Genevieve Breton — Tue, 19 May 2026 20:02:23 +0000

In the last article I went through what breaks when you obfuscate Java code before sending it to an AI assistant — Spring Data, JPA, Lombok, the whole framework iceberg. That was about getting the obfuscated source out in a state the AI can work on.

This one is about the much subtler half: getting the AI's changes back in.

It looks trivial. You sent Cls_a1b2c3d4 to the AI, the AI returned a modified Cls_a1b2c3d4, you have a mapping table, just walk the file and replace each obfuscated identifier with its original. Done in twenty lines of code.

Except your real file — the one a human will read tomorrow morning — now has no comments, no Javadoc, no blank lines between methods, no formatting choices you made over six months. The obfuscation pipeline stripped all of that on the way out. Reversing the rename doesn't bring it back.

This is the story of why naive reverse-translation is wrong, why it's a 3-way merge problem, not a translation problem, and what the merge actually has to handle in practice.

The naive reverse

Here's what most people try first:

String aiOutput = readAiResponse();
String realSource = aiOutput;
for (Mapping m : mappings) {
    realSource = realSource.replace(m.obfuscated(), m.real());
}
writeRealFile(realSource);

Set aside that you also need word-boundary regex and longest-match-first ordering to avoid prefix collisions — assume you handled all of that. The output is still wrong.

Why? Because the file you sent to the AI was not just renamed. It was also:

Comment-stripped. Sending Javadoc and inline comments to the AI is gratuitous leakage — they contain plain-English domain language. So they get replaced with blank-equivalent lines before transmission.
Reformatted in subtle ways. Multi-line string literals get sanitized. Annotations on separate lines get coalesced. Blank lines are preserved but only by accident.

When you reverse-translate the AI's output and write it back, you're overwriting your real source with the obfuscation-pipeline-shaped version of itself, plus the AI's changes. Every comment you wrote is gone. Every formatting choice. Every blank line at the right place.

The first time I ran this end-to-end on a real project, I tested it on a service class. The AI added one method. I diffed the result against my source: 312 lines changed. One of them was the AI's new method. The other 311 were comments and formatting I had just nuked.

The mental shift: it's a merge, not a translation

Here's the model that finally clicked. The obfuscated file is not the canonical version of your source. It is a projection of your source — one that lost information on purpose. You can't reconstruct your source from the projection alone. You need both.

In git terms: this is a 3-way merge.

Three inputs:

Snapshot — the obfuscated version of your code before the AI touched it. (Your "common ancestor.")
Cache — the obfuscated version after the AI's changes. (The "their" side.)
Real — your actual source file, with all comments and formatting intact. (The "ours" side.)

The output is your real file, with only the AI's changes applied.

The merge logic, in one sentence: for each line, if the AI didn't change it (snapshot line == cache line), keep your real line; if the AI changed it, de-obfuscate the cache line and use that.

Stated like that, it's almost obvious. The implementation has interesting corners.

The easy case: same line count

When the AI modifies lines without adding or removing any, the line indices line up across all three files. The merge is one pass:

String[] snapshotLines = snapshot.split("\n", -1);
String[] cacheLines = cache.split("\n", -1);
String[] realLines = real.split("\n", -1);

StringBuilder out = new StringBuilder();
for (int i = 0; i < cacheLines.length; i++) {
    if (i > 0) out.append('\n');
    if (snapshotLines[i].equals(cacheLines[i])) {
        // AI didn't touch this line — keep the real version (with comments, formatting)
        out.append(realLines[i]);
    } else {
        // AI changed this line — de-obfuscate it
        out.append(deobfuscate(cacheLines[i]));
    }
}

That's it. The whole trick is the snapshotLines[i].equals(cacheLines[i]) check. Equal obfuscated lines mean the AI didn't write here, so your real line — comments, blank lines, formatting — survives untouched. Only the cells the AI actually changed get the de-obfuscated translation.

This single trick made the merge usable. On a typical edit (the AI adds a parameter, changes a return type, inserts a guard clause), it touches 5–20 lines and the rest of the file stays bit-for-bit identical to my source. No phantom formatting changes, no destroyed Javadoc.

The hard case: AI added or removed lines

When the AI adds an if block or removes a redundant method, line counts diverge between snapshot and cache. Now indices don't line up — line N of the cache might correspond to line N+3 of the snapshot, or to nothing at all.

You can pull in java-diff-utils and run a real LCS-based diff here. I tried that first. It works, but it adds a dependency, the diff format needs translation, and for the size of edits the AI typically makes (5–50 lines), a homegrown linear walker is faster and easier to reason about.

The walker keeps three indices — one per file — and decides at each step whether the current cache line is an unchanged line (advance all three), a modification (advance all three, but de-obfuscate the cache line), or an insertion (advance only the cache index):

int si = 0, ci = 0, ri = 0;
while (ci < cacheLines.length) {
    if (si < snapshotLines.length && snapshotLines[si].equals(cacheLines[ci])) {
        // unchanged → keep real
        out.append(realLines[ri]);
        si++; ci++; ri++;
    } else {
        // changed: modification or insertion?
        boolean isInsertion = false;
        if (si < snapshotLines.length) {
            for (int look = ci + 1; look < cacheLines.length && look < ci + 50; look++) {
                if (snapshotLines[si].equals(cacheLines[look])) {
                    isInsertion = true;
                    break;
                }
            }
        }
        if (isInsertion) {
            // AI inserted a new line before the next snapshot line
            out.append(deobfuscate(cacheLines[ci]));
            ci++;
        } else {
            // AI modified or replaced this line
            out.append(deobfuscate(cacheLines[ci]));
            si++; ci++; ri++;
        }
    }
}

The 50-line look-ahead window deserves a comment. It's the heuristic that decides "did the AI insert new code before this snapshot line, or did it modify this snapshot line?" If the next snapshot line shows up within the next 50 cache lines, treat the current cache line as an insertion. Otherwise treat it as a modification.

Why 50? Two reasons:

Cost. A full O(N²) LCS on a 2000-line file does ~4M comparisons. Bounded look-ahead caps each step at 50 comparisons → 100k total. On a real file this is microseconds.
Realism about edit shapes. AI assistants rarely insert 50+ contiguous lines without also modifying surrounding code. When they do, you're outside "merge a small edit" territory and you should be re-running the obfuscation pipeline on the result anyway.

It is a heuristic. On pathological inputs (the AI rewrites the entire file), it degrades to "treat everything as modification" which produces a usable but heavily de-obfuscated file. That's the right failure mode — you'll lose formatting on the affected stretch, but you won't lose data.

Three traps that the test suite found

The merge in the previous sections is the version that works. Getting there involved walking face-first into a few traps that aren't obvious from the algorithm.

Trap 1: snapshot and cache disagree on line count even when the AI didn't add lines

Early on I was confused by failures that looked like the AI had inserted lines, when the diff in the assistant's output clearly hadn't.

What was happening: the snapshot had been written months earlier, when the obfuscation pipeline's comment-stripping pass replaced multi-line /* ... */ comments with a single empty line. The current version replaces each line of the comment with its own empty line — preserving line count. So a snapshot from version v1 and a cache from version v2 could disagree by dozens of lines for the same source file, just because of comment-stripping format drift.

The fix: when snapshot and cache disagree on line count, re-obfuscate the real file on the fly to get a fresh snapshot in the current format, and use that as the merge ancestor. Only .java files — sanitizers for .properties, .yml, and pom.xml preserve line count by construction, so any line-count drift on those files is a genuine AI edit, not a format mismatch.

if (snapshotLines.length != cacheLines.length && obfRelativePath.endsWith(".java")) {
    String freshObfuscated = engine.obfuscateContent(realContent);
    if (freshObfuscated != null) {
        snapshotContent = freshObfuscated;
    }
}

I did not gate this on the obfuscation pipeline version — the cost of re-obfuscating one file on demand is negligible, and the alternative (storing version metadata per snapshot and migrating on read) was complexity I didn't want.

Trap 2: don't run the Java obfuscation pipeline on a .properties file

There's a sharp corner in the fix above. The re-obfuscation call is engine.obfuscateContent(realContent). That method runs the Java pipeline — JavaParser AST walk, identifier replacement, comment stripping, reflection-string post-processing.

If I run it on a .properties file, it produces a near-identity transformation (no Java identifiers to rename, no comments to strip the same way). The output is almost-but-not-quite the same as the real file. Now I have a "snapshot" that diverges from the cache on every single line, because the properties sanitizer (a different pipeline) produced the cache, while the Java pipeline produced this fresh "snapshot."

The merge then concludes that the AI rewrote every line of the properties file, and helpfully writes the sanitized (REDACTED placeholder) values back into the real application.properties. That's not a corrupted file — that's a data exfiltration risk inverted: the redaction now overwrites the real secret.

The .endsWith(".java") guard above isn't a perf optimization. It's a correctness boundary.

Trap 3: AI-created files don't have a snapshot at all

When the AI creates a new file — Cls_a1b2c3d4Test.java, say — there's no snapshot to merge against. There's no real file either. You just have the cache.

This case is simpler in some ways (full de-obfuscation of the content, no merge) but it has its own corner: the filename itself contains obfuscated identifiers. Cls_a1b2c3d4Test.java needs to become InvoiceServiceTest.java — the AI used the obfuscated class name as a prefix to a new identifier, and the path resolver has to recognize the embedded mapping.

The strategy: try a full-filename match against known class mappings first (Cls_a1b2c3d4.java → InvoiceService.java). If that fails, run the standard line de-obfuscation on the filename without extension and treat whatever comes out as the real name (Cls_a1b2c3d4Test → InvoiceServiceTest). Same for package path segments.

if (!matched && fileName.endsWith(".java")) {
    String stem = fileName.substring(0, fileName.length() - 5);
    fileName = engine.deobfuscateLine(stem) + ".java";
}

The same machinery you wrote to de-obfuscate file contents solves the file path problem if you feed it the path as a string. Once I noticed this, several other corner cases I'd been hand-rolling (paths in stack traces, file references in error messages) collapsed into the same call.

What about deletions?

The AI sometimes "cleans up" by deleting a file. I do not auto-apply deletions. The merge reports them — applied: 3, created: 1, deletedByAi: 1 — and the developer decides whether to follow through.

This is not a technical limitation. It's a deliberate asymmetry. The cost of accidentally creating a file is a git rm away. The cost of accidentally deleting a file the developer hadn't checked in yet is unrecoverable. The merge plays defense on the irreversible side.

Why this generalizes

I started building this for obfuscation because I had to. But the pattern — projection, transformation in the projected space, merge back into the original — shows up in a lot of places once you look for it:

Source maps in JavaScript bundlers. The bundled file is a projection; the original sources are the real version; you map errors back via the source map.
AST-based refactoring tools. The AST is a projection; the textual source has comments and formatting the AST doesn't; round-tripping requires a 3-way merge.
Notebook → script extraction and back. Strip cells to a script for review; merge edits back into the notebook.
Anything that asks an LLM to edit code with stripped context. Hide secrets, hide proprietary names, hide internal comments — and now you own a merge problem.

The takeaway from six months of breaking my own merge: don't think of the projection as a translation. Think of it as a branch. Once you call it a branch, you stop trying to invent a clever inverse and you start writing a merge — which is a problem the industry has spent decades solving.

If you want to see the merge running on real Java edits — including the tricky cases — the example diffs and test fixtures live in gitlab.com/gbreton7/promptcape-docs. It's the docs and worked-examples companion to **PromptCape*, the obfuscation proxy I'm building for Claude Code and Cursor. MRs welcome if you've run into a merge case I haven't.

Java Code Obfuscation for AI Assistants: Ensuring the Full Cycle Works

Genevieve Breton — Mon, 04 May 2026 18:14:55 +0000

How to obfuscate Java code for AI coding tools while guaranteeing that compilation, tests, and reverse-application all succeed.

The problem

AI coding assistants (Claude Code, Cursor, GitHub Copilot) need access to your source code to help you. But sending proprietary code to an LLM means exposing your business domain, architecture, and intellectual property, and configuration data, even personal data.

Code obfuscation can solve this: rename identifiers before the AI sees the code, let the AI work on the obfuscated version, then reverse the changes back. Simple in theory. In practice, Java's rich ecosystem of frameworks, annotations, and conventions makes this a minefield.

This article describes what a Java obfuscation tool must handle to guarantee the full cycle:

Source compiles & tests pass
    -> Obfuscation
        -> AI modifies code
            -> Obfuscated code compiles & tests pass
                -> De-obfuscation (apply)
                    -> Source compiles & tests pass

Each transition can break. Here is what you need to address at each step, and how PromptCape solves it.

Step 1: Source -> Obfuscation

1.1 What to rename

A Java obfuscator for AI must rename:

Element	Example	Why
Package names	`com.acme.billing` -> `pkg_a1b2c3d4`	Reveals company and domain
Class names	`InvoiceService` -> `Cls_e5f6a7b8`	Reveals business concepts
Method names	`calculateDiscount` -> `mtd_1a2b3c4d`	Reveals business logic
Field names	`customerName` -> `fld_9e8d7c6b`	Reveals data model
Comments	`// Apply VAT to invoice` -> `// Processed.`	Reveals business context
Javadoc	`/** Calculates the total with tax /` -> `/* Processed. */`	Same
Config values	`jdbc:postgresql://prod.acme.com` -> `REDACTED`	Reveals infrastructure

1.2 What NOT to rename

This is where most naive approaches fail. The following must be preserved:

JDK types and methods: String, List, Map, Optional, toString, equals, hashCode, main, stream, forEach...

Framework annotations: @Autowired, @Entity, @RestController, @GetMapping, @JsonProperty, @Data, @Builder...

Framework-specific identifiers that carry semantic meaning for the framework at runtime:

Framework	What breaks if renamed	Example
Spring Data JPA	Derived query methods	`findByActiveTrue()` -> the method name IS the query. Renaming it to `mtd_xxx` makes Spring fail with "No property mtd found"
JPA/Hibernate	Entity names in JPQL	`@Query("SELECT e FROM Invoice e")` — the string `Invoice` must match the entity class name
Lombok	Generated accessor names	`@Data` generates `getName()` from field `name`. If `name` is renamed to `fld_xxx`, Lombok generates `getFld_xxx()` — but code calling `getName()` is also renamed to `getMtd_xxx()`
Jackson	JSON field mapping	`@JsonProperty` fields, or fields in DTOs in `model`/`dto` packages — renaming breaks serialization/deserialization
Spring Config	Property binding	`@ConfigurationProperties` binds YAML keys to field names
Bean Validation	Field references	`@NotBlank` on a field — the constraint message references the field name

The solution: framework detection (Pass 0). Before collecting identifiers, scan the entire project for framework annotations and produce exclusion rules. Each framework has a dedicated detector:

Project scan -> LombokDetector       -> exclude fields + get/set/is accessors
             -> SpringDataDetector   -> exclude findByXxx, countByXxx, existsByXxx methods
             -> JacksonDetector      -> exclude @Entity/@JsonProperty fields
             -> JpaHibernateDetector -> exclude @MappedSuperclass/@Embeddable fields
             -> SpringConfigDetector -> exclude @ConfigurationProperties fields
             -> ValidationDetector   -> exclude @NotBlank/@Min/@Size fields
             -> OpenApiDetector      -> exclude @Schema/@Operation fields and methods
             -> SpringBootDetector   -> track @SpringBootApplication for test fixing

1.3 String literals: a hidden trap

Code replacement must skip string literals to avoid breaking values like "Hello World" or "/api/v1/users". But some strings DO reference identifiers:

Context	String content	Must be updated?
`@Query("SELECT e FROM Invoice e")`	JPQL entity name	Yes
`Class.forName("com.acme.InvoiceService")`	Fully qualified class name	Yes
`getMethod("calculateTotal")`	Reflection method name	Yes
`@ComponentScan("com.acme.service")`	Package name	Yes
`"Hello World"`	User-facing string	No
`"/api/v1/invoices"`	REST endpoint	No

The obfuscator must apply identifier replacement INSIDE specific string contexts while leaving general strings untouched. This requires post-processing passes for @Query, reflection calls, and package annotations.

1.4 Comment stripping and special characters

Comments contain business context that reveals your domain. But stripping them introduces two problems:

Line count changes: A multi-line Javadoc becomes a single-line /** Processed. */, breaking line-number correspondence between obfuscated and original files.
Special characters in comments: French (and other languages) comments contain apostrophes (// Service d'injection), accented characters, and other non-ASCII text. A character-by-character scanner that treats ' as a Java char literal delimiter will be confused by l'injection, potentially skipping code after the comment.

Solution: Process comments before string/char literal scanning. Replace line comments (//) in-place (one line in, one line out). For multi-line Javadoc and block comments, accept the line count change and handle it during the reverse-apply step with a 3-way merge.

Step 2: Obfuscated code -> AI modification -> Compilation & tests

2.1 The obfuscated code must compile

This seems obvious but is surprisingly hard. Even with framework detection, some identifiers cause compilation failures that can only be detected by actually compiling. Examples:

A method name that collides with a JDK method after obfuscation
A field name that matches a Java keyword
An annotation processor that generates code based on identifier names

Solution: auto-fix loop. Compile the obfuscated code. If it fails, parse the compiler errors, reverse-map the broken identifiers, add them to an exclusion list, and re-obfuscate. Repeat until green or max iterations reached. Persist exclusions for future runs.

Obfuscate -> Compile -> Parse errors -> Exclude broken identifiers -> Re-obfuscate -> Compile -> ...

2.2 Tests must pass on obfuscated code

Compilation is necessary but not sufficient. Tests exercise the runtime behavior where framework conventions matter most:

Spring context loading: @SpringBootTest boots the full application context. A broken repository method or missing bean crashes the entire test suite.
Spring Data query derivation: happens at context startup, not at compile time.
JPA schema generation: Hibernate creates tables from @Entity classes. If JPQL @Query strings reference the original entity name but the class is renamed, the context fails.
H2 compatibility: Test profiles often use H2 instead of PostgreSQL. Database-specific types (JSONB, ARRAY) in column definitions fail on H2 regardless of obfuscation.

Key insight: If the source tests pass and the obfuscated tests don't, the obfuscation broke something. The auto-fix loop should use mvn test-compile (or even mvn test) as the build command to catch these failures.

2.3 The AI must be able to work effectively

The AI needs to:

Read and understand the code structure (even with obfuscated names)
Create new files, classes, and methods
Modify existing code
Run builds and tests to verify its work

The obfuscated names should be deterministic (same input always produces the same hash) so the AI can learn patterns across files. Prefixes (Cls_, mtd_, fld_, pkg_) help the AI understand the identifier type.

Step 3: De-obfuscation (apply) -> Source compiles & tests pass

This is where most obfuscation tools stop — they handle the forward direction but not the reverse. For AI coding, the reverse is just as critical.

3.1 Only apply what the AI changed

The naive approach: read the obfuscated file, de-obfuscate all identifiers, overwrite the real file. This breaks because:

Comments were stripped during obfuscation. The de-obfuscated file has /** Processed. */ where the original had full Javadoc. If the AI didn't touch that line, the original comment should be preserved.
Formatting may differ. The obfuscated file may have different whitespace or line endings.

Solution: 3-way merge. Compare the snapshot (obfuscated, pre-AI) with the cache (obfuscated, post-AI) line by line:

Lines unchanged by the AI -> keep the original source line
Lines modified by the AI -> de-obfuscate the new version

Snapshot line == Cache line?
    Yes -> keep original source line (preserves comments, formatting)
    No  -> de-obfuscate cache line (AI changed it)

For added/removed lines, use chunk-based alignment to find sync points and apply the changes surgically.

3.2 Handle AI-generated variable names

When the AI creates a new variable for an obfuscated class, it invents a name based on what it sees:

// AI writes:
private Cls_f45371c4 fld_f45371c4;

// Standard de-obfuscation produces:
private ZipBuilderService fld_f45371c4;  // class de-obfuscated, but variable name is unreadable

The variable name fld_f45371c4 is not in the mapping registry — the AI invented it. But the hash f45371c4 matches the known class ZipBuilderService.

Solution: After standard de-obfuscation, scan for remaining fld_XXXXXXXX/cls_XXXXXXXX/mtd_XXXXXXXX patterns. If the hash matches a known entry, generate a camelCase variable name:

private ZipBuilderService zipBuilderService;  // readable

Track each unique token across the file to ensure consistent renaming (declaration and all usages get the same name).

3.3 Don't apply build artifacts

The AI may run mvn package in the obfuscated workspace, creating target/ with compiled .class files, .jar archives, and test reports. These must be excluded from the diff detection:

Skip directories: target/, build/, node_modules/, .idea/
Skip binary files: .class, .jar, .war, images, fonts
These patterns match what the obfuscation engine already skips

3.4 Snapshot management

The apply command needs a "before" snapshot to detect what the AI changed. After a successful apply, the snapshot is updated. But if the apply fails or the user reverts with git restore, the snapshot is out of sync.

Solution:

Don't update the snapshot when the apply has errors
Provide a --reset-snapshot option that re-obfuscates the source into the snapshot directory without touching the cache

The complete cycle

Here is what must work end-to-end:

1. mvn test                       -> GREEN (source is healthy)
2. promptcape obfuscate --verify  -> Obfuscated workspace created
3. mvn test (in workspace)        -> GREEN (obfuscation didn't break anything)
4. AI modifies obfuscated code
5. mvn test (in workspace)        -> GREEN (AI changes work)
6. promptcape apply               -> Changes applied to source
7. mvn test                       -> GREEN (de-obfuscated changes work)

Each transition requires specific handling:

Transition	Challenge	Solution
1 -> 2	Framework identifiers break	Framework detection (8 detectors)
1 -> 2	Some identifiers cause compile errors	Auto-fix loop with exclusion persistence
2 -> 3	JPQL strings reference original names	Post-processing: replace entity names in `@Query`
2 -> 3	Reflection strings reference original names	Post-processing: replace in `getMethod()`, `forName()`
2 -> 3	Spring Data query derivation fails	Repository method name protection
4 -> 5	AI must understand the code	Deterministic naming, type prefixes
5 -> 6	Comments stripped during obfuscation	3-way merge (only apply AI-changed lines)
5 -> 6	AI invents unreadable variable names	Hash-based name resolution
5 -> 6	Build artifacts in workspace	Directory and binary file filtering
6 -> 7	Applied changes don't compile	User review + re-apply capability

What PromptCape implements

PromptCape is a Java-first obfuscation tool designed for this exact cycle. Here is what it covers today:

Obfuscation engine:

AST-based identifier collection via JavaParser (packages, classes, methods, fields, enums, records)
Deterministic HMAC-SHA256 naming with type prefixes
Package hierarchy flattening
Word-boundary replacement (\b) with longest-match-first ordering
String literal preservation with post-processing for @Query, reflection, @ComponentScan
Full comment stripping (Javadoc, block, and line comments)
POM, properties, YAML, and XML file sanitization

Framework detection (8 detectors):

Lombok: field + accessor protection
Spring Boot: application class tracking, test annotation fixing
Spring Data: repository derived query method protection
JPA/Hibernate: entity field protection, JPQL entity name replacement
Jackson: DTO/entity field protection
Spring Config: property-bound field protection
Validation: constraint field protection
OpenAPI: schema field and method protection

Auto-fix:

Compile-and-fix loop with configurable build command
Compiler error parsing and reverse mapping
Persistent exclusion lists across runs
Source verification option

Reverse application:

3-way merge (preserve original lines for unchanged content)
AI-generated variable name resolution (hash-based)
Build artifact and binary file exclusion
Snapshot management with reset capability

Two modes:

CLI workspace (obfuscate -> AI works -> apply)
HTTP proxy (transparent interception for IDE-based tools — see below)

Metrics:

Final identifier and duration counters at the end of every run, for instance:

+-------------------------------+----------+
| Final Summary                 |          |
+-------------------------------+----------+
| Iterations                    |       4  |
| Identifiers obfuscated        |    3287  |
| Packages (flattened)          |      74  |
| Exclusions loaded (previous)  |       0  |
| Exclusions added (this run)   |     152  |
| Exclusions total              |     152  |
| Verification time             |  106,1s  |
| Total time                    |  224,5s  |
+-------------------------------+----------+
| Compilation                   |    OK    |
+-------------------------------+----------+

Seamless IDE integration

The obfuscation cycle described above can run as a one-shot CLI workflow, but friction kills adoption. Developers don't want to leave their IDE, run promptcape obfuscate, switch to a workspace folder, ask the AI to do something, then run promptcape apply and switch back. They want the assistant they already use, in the IDE they already use, with the obfuscation invisible.

PromptCape provides this via an HTTP proxy mode that intercepts traffic to the AI provider and applies the same forward/reverse cycle on the fly:

IDE -> Claude Code -> [PromptCape proxy] -> Anthropic API
                          obfuscates the prompt going out
                          de-obfuscates the response coming back

The "PromptCape Claude" terminal in Cursor

The simplest integration is a dedicated terminal profile. In Cursor (and equally in VS Code or any IDE that supports terminal profiles), you create a profile named PromptCape Claude that:

Starts the proxy in the background if it is not already running
Sets ANTHROPIC_BASE_URL (and equivalent variables) to point Claude Code at the local proxy
Launches claude (the Claude Code CLI) inside that environment

From the developer's perspective, this is just another terminal in the IDE sidebar. They open the PromptCape Claude terminal instead of the default one, type their request to Claude as usual, and watch the AI work on their codebase. Behind the scenes:

Outbound prompt: identifiers, comments, and config values are obfuscated before leaving the machine
Inbound response: file edits, suggestions, and explanations are de-obfuscated before reaching the IDE
Build artifacts and binaries are filtered out of the cycle

No workflow change. No obfuscate or apply command to remember. The same Claude Code experience, with the obfuscation guaranteeing that what reaches the provider is not your real source code.

Why a terminal profile is the right shape for this

The CLI workspace is the right primitive — it gives full control and fits CI/CD or one-shot review use cases. But for daily AI-assisted coding, friction wins or loses the security battle. A proxy that hooks into the existing tool's trust chain (env vars, ANTHROPIC_BASE_URL) gives:

Zero training cost: developers keep using Claude Code exactly as before — same commands, same outputs
Zero forgotten steps: there is no apply to forget — the response is reverse-mapped on the wire
Per-project configuration: terminal profiles ship in .vscode/settings.json, .cursor/, or JetBrains run configurations, so opening a project pre-configures the secure terminal automatically
Auditability by default: every prompt and response transits the proxy, which can log, redact, or block on policy

The same pattern extends to any AI tool that respects a base-URL override (Cursor's built-in chat, Aider, Continue.dev, OpenAI-compatible clients, etc.). The IDE doesn't need a plugin and the AI tool doesn't need to know the proxy exists — the integration is just a terminal away.

Conclusion

Java obfuscation for AI coding assistants is not just about renaming identifiers. It requires deep understanding of how Java frameworks use naming conventions, how annotation processors derive behavior from names, and how to surgically apply AI changes without losing information that was stripped during obfuscation.

The key insight: framework detection before obfuscation is more effective than reactive error fixing after. Proactively protecting Spring Data repository methods, JPA entity fields, and Lombok-generated accessors eliminates most compilation failures before they happen.

The second insight: the reverse direction is just as hard as the forward. A 3-way merge that only applies AI-changed lines, combined with hash-based resolution of AI-invented names, makes the de-obfuscated code readable and correct.

The third insight: friction kills adoption, so the obfuscation has to disappear into the IDE. A dedicated terminal profile (the PromptCape Claude terminal in Cursor) that boots Claude Code through the proxy turns the entire cycle into a transparent operation — same tool, same commands, no extra steps. Security that requires discipline gets bypassed; security that ships as a terminal in the sidebar gets used.

PromptCape is open for trial at promptcape.com

Why Your Source Code Is at Risk When Using AI Coding Assistants, but no dev future without AI coding!

Genevieve Breton — Fri, 01 May 2026 16:41:29 +0000

Every line you send to an AI coding tool leaves your control. Here's what that means for your business, your clients, and your legal obligations.

You are sending your source code to a foreign server

When you use Claude Code, Cursor, GitHub Copilot, ChatGPT, Mistral Vibe, or any LLM-based coding assistant, your source code is sent over HTTPS to a remote API. That API runs on servers you don't control, in a jurisdiction you didn't choose, operated by a company whose data practices you've accepted by clicking "I agree."

Let's be specific about where your code goes:

Tool	API provider	Server locations
Claude Code / Cursor (Claude)	Anthropic	US (AWS us-east, us-west)
GitHub Copilot	Microsoft / OpenAI	US (Azure data centers)
ChatGPT	OpenAI	US (Azure data centers)
Cursor (OpenAI mode)	OpenAI	US
Mistral Vibe / Le Chat	Mistral AI	EU (France, via cloud providers)
DeepSeek	DeepSeek	China
Gemini Code Assist	Google	US (GCP data centers)

Most developers don't think twice about this. They open their IDE, the AI suggests code, they accept. Behind the scenes, the IDE sent the contents of the current file — and often surrounding files, imports, and project context — to a server thousands of kilometers away.

What exactly is being sent?

It's not just "a few lines of code." Modern AI coding tools send rich context to produce better suggestions:

The current file — full content, not just the cursor position
Open tabs and imported files — the AI reads your project structure
File paths — revealing your package hierarchy (com.acme.billing.service.InvoiceService)
Configuration files — application.yml, pom.xml, .env with database URLs, API keys, internal hostnames
Comments and Javadoc — containing business logic descriptions, TODO items, bug references
Test files — revealing edge cases, business rules, validation logic
Git context — commit messages, branch names, sometimes diffs

A single prompt to an AI coding assistant can contain more context about your business than a 10-page architecture document.

The risks are real and specific

1. Source code leakage

Your code is transmitted to and processed on third-party infrastructure. Even if the provider promises not to train on your data (and many do), the code still:

Transits through networks you don't control — intermediate proxies, load balancers, logging systems
Is stored temporarily for processing — cache layers, request logs, debugging infrastructure
May be retained for abuse detection — most providers log requests for safety monitoring
Could be subpoenaed — US providers are subject to US law enforcement requests, including the CLOUD Act which allows cross-border data access

The question is not "will the provider deliberately steal my code?" It's "how many systems touch my code between my IDE and the model, and who has access to those systems?"

2. Intellectual property exposure

Source code is a trade secret. Once exposed, trade secret protection can be lost permanently — unlike patents or copyrights, trade secrets only have value as long as they remain secret.

What your code reveals:

Element	What it exposes
Class and method names	Your business domain and capabilities (`FraudDetector`, `TaxCalculator`, `PatentAnalyzer`)
Package structure	Your architecture and module boundaries
Algorithm implementations	Your competitive advantage (pricing logic, recommendation engines, risk models)
Database schema	Your data model and relationships
API endpoints	Your service surface and capabilities
Configuration	Your infrastructure topology
Comments	Your business rules in plain language

A competitor with access to your AI provider's logs could reconstruct your product's architecture, business rules, and technical approach without ever seeing your actual repository.

3. Client code exposure (integrators and freelancers)

If you're a consulting firm, systems integrator, or freelance developer, the risk multiplies. You're not just exposing your own code — you're exposing your client's code.

Consider the scenarios:

You customize an ERP for a bank. You send controller code to Claude that contains transaction processing logic, compliance rules, and internal API endpoints. That code belongs to the bank, not to you.
You build a SaaS platform for a healthcare company. You use Copilot while working on patient data models. HIPAA-regulated data structures are now on Microsoft's servers.
You maintain a defense contractor's codebase. You use an AI to debug a networking module. The code may be subject to ITAR export controls — sending it to a US cloud provider may technically comply, but sending it to a Chinese provider (DeepSeek) would be a violation.

Most client contracts include clauses about code confidentiality and data handling. Using AI coding tools on client code may violate these contracts — and the client may never know until a breach occurs. But if it occurs and you are the one in charge of the code, this may a very bad stone in your shoe.

4. Regulatory and compliance risks

Depending on your industry and jurisdiction, sending source code to external AI services can create compliance issues:

Regulation	Risk
GDPR (EU)	If your code processes personal data and the code itself contains PII patterns, field names, or test data, sending it to a US server may violate data transfer rules
SOC 2	Requires documented controls over data access. Using AI tools without DLP controls may fail audit
ISO 27001	Requires risk assessment for third-party data processing. AI coding tools are a new attack vector
HIPAA (US healthcare)	Code containing PHI field names, validation rules, or test fixtures with patient data patterns
PCI DSS	Code handling payment card data, encryption keys, or tokenization logic
ITAR (US defense)	Export-controlled technical data cannot be shared with foreign persons or servers
NIS2 (EU)	Critical infrastructure operators must control their software supply chain

Even if you're not in a regulated industry, your clients might be. And their auditors will ask how their code is protected.

5. The training data question

Most AI providers now offer policies like "we don't train on your data." But:

Policies change. OpenAI initially trained on API data, then reversed course after backlash. What's the policy today may not be tomorrow's policy.
Policies have exceptions. Abuse detection, safety monitoring, and model evaluation may still use your data.
Free tiers have different rules. ChatGPT Free explicitly trains on your conversations. Many developers prototype with the free tier before switching to paid.
Subprocessors matter. The AI provider may not train on your data, but what about their cloud provider? Their logging vendor? Their CDN?
Data breaches happen. Samsung's semiconductor division leaked proprietary chip designs through ChatGPT in 2023. OpenAI suffered a data breach in March 2023 where users could see other users' chat titles. Even claude code has recently leaked!

The safest assumption: anything you send to an AI service should be treated as if it could become public.

The false sense of security

"But we use the enterprise plan"

Enterprise plans typically offer:

No training on your data
Data processing agreements (DPAs)
SOC 2 compliance of the provider

What they don't offer:

Control over where the data is processed
Guarantees about intermediate systems
Protection against subpoenas or government data requests
Deletion verification (you can't audit what you can't see)

"But we use a self-hosted model"

Self-hosted models (Llama, Mistral, CodeLlama) solve the data residency problem but introduce others:

Dramatically lower code quality compared to frontier models
Significant infrastructure costs
No access to the latest model capabilities (Claude Opus, GPT-4o)
Still requires GPU infrastructure that someone must maintain

"But we only send small snippets"

AI coding tools send more context than you think. And even small snippets reveal information:

// "Just a small function"
public BigDecimal calculateRoyalty(Contract contract, SalesReport report) {
    BigDecimal baseRate = contract.getRoyaltyRate();
    BigDecimal sales = report.getNetSales().subtract(report.getReturns());
    if (contract.hasMinimumGuarantee()) {
        return sales.multiply(baseRate).max(contract.getMinimumGuarantee());
    }
    return sales.multiply(baseRate);
}

This "small snippet" reveals: you have a royalty calculation business, contracts have minimum guarantees, you track returns separately from net sales, and your financial model uses BigDecimal precision. A competitor now knows your pricing model structure.

The solution: pseudonimyse and obfuscate before sending

The principle is simple: rename everything that reveals business meaning before the AI sees it, then reverse the renaming when applying the AI's changes.

Your code:                          What the AI sees:
calculateRoyalty()          ->      mtd_a1b2c3d4()
Contract contract           ->      Cls_e5f6a7b8 fld_9c8d7e6f
getRoyaltyRate()            ->      mtd_1a2b3c4d()
hasMinimumGuarantee()       ->      mtd_5e6f7a8b()

The AI can still:

Understand the code structure (types, control flow, patterns)
Suggest refactorings and bug fixes
Add new functionality
Write tests

What it cannot do:

Infer your business domain
Reconstruct your architecture from meaningful names
Extract business rules from comments (stripped)
Identify your company from package names (flattened)

What a proper obfuscation tool must handle

It's not as simple as find-and-replace. Java's framework ecosystem means certain identifiers carry semantic meaning for the runtime:

Spring Data repository methods (findByName) derive SQL queries from the method name
Lombok generates accessor methods from field names
JPA uses entity class names in JPQL query strings
Jackson derives JSON field names from Java field names
Spring Config binds YAML keys to field names

A good obfuscation tool detects these frameworks and protects the identifiers that would break. Everything else gets renamed.

The full cycle must work

Obfuscation is only useful if the cycle is complete:

Source compiles     -> Obfuscate -> Obfuscated compiles
                                 -> AI modifies -> Still compiles
                                                -> Apply back -> Source still compiles

Every transition can break. Framework detection, JPQL string updating, comment stripping, 3-way merge for reverse-application — all are necessary for a production-ready workflow.

What you should do today

Immediate steps

Audit what your AI tools send. Enable request logging or use a proxy to see what context is transmitted. You'll likely be surprised.
Check your client contracts. Look for clauses about code confidentiality, data processing, and third-party tools. Many contracts written before 2023 don't explicitly address AI coding tools — which doesn't mean they allow them.
Establish an AI coding policy. Define which projects can use AI tools, which cannot (client code, regulated code), and what safeguards are required.
Consider obfuscation. For projects where AI assistance is valuable but code exposure is unacceptable, obfuscation provides the best of both worlds: AI productivity without IP exposure.

For regulated industries

Document your AI tool usage in your risk register. Auditors will ask.
Include AI tools in your data processing agreements with clients.
Evaluate data residency requirements. If your data must stay in the EU, most US-based AI providers don't qualify without additional safeguards.

For integrators and freelancers

Get explicit written consent from clients before using AI tools on their code.
Use obfuscation by default on client projects. It's a competitive advantage: "We use AI to deliver faster, and we protect your code while doing it."
Include AI tool policies in your contracts. Define what tools you use, how code is protected, and what the client's options are.

Conclusion

AI coding assistants are transformative tools. They make developers faster, reduce boilerplate, and help navigate unfamiliar codebases. But they come with a fundamental trade-off: to help you, the AI needs to see your code. And "seeing your code" means transmitting it to infrastructure you don't control, in jurisdictions you didn't choose, with data handling practices you can't verify.

The answer is not to stop using AI tools. The answer is to stop sending your code in clear text.

Obfuscate your identifiers. Strip your comments. Sanitize your configuration. Let the AI work on the structure of your code without knowing what your code does. You get the productivity benefits. Your intellectual property stays yours.

PromptCape is a Java code obfuscation tool designed for AI coding workflows. It handles framework detection, compilation verification, and smart reverse-application. Free trial at promptcape.com.

Why Your Source Code Is at Risk When Using AI Coding Assistants

Genevieve Breton — Fri, 10 Apr 2026 06:35:02 +0000

Every line you send to an AI coding tool leaves your control. Here's what that means for your business, your clients, and your legal obligations.

You are sending your source code to a foreign server

Let's be specific about where your code goes:

Tool	API provider	Server locations
Claude Code / Cursor (Claude)	Anthropic	US (AWS us-east, us-west)
GitHub Copilot	Microsoft / OpenAI	US (Azure data centers)
ChatGPT	OpenAI	US (Azure data centers)
Cursor (OpenAI mode)	OpenAI	US
Mistral Vibe / Le Chat	Mistral AI	EU (France, via cloud providers)
DeepSeek	DeepSeek	China
Gemini Code Assist	Google	US (GCP data centers)

What exactly is being sent?

It's not just "a few lines of code." Modern AI coding tools send rich context to produce better suggestions:

The current file — full content, not just the cursor position
Open tabs and imported files — the AI reads your project structure
File paths — revealing your package hierarchy (com.acme.billing.service.InvoiceService)
Configuration files — application.yml, pom.xml, .env with database URLs, API keys, internal hostnames
Comments and Javadoc — containing business logic descriptions, TODO items, bug references
Test files — revealing edge cases, business rules, validation logic
Git context — commit messages, branch names, sometimes diffs

A single prompt to an AI coding assistant can contain more context about your business than a 10-page architecture document.

The risks are real and specific

1. Source code leakage

Your code is transmitted to and processed on third-party infrastructure. Even if the provider promises not to train on your data (and many do), the code still:

Transits through networks you don't control — intermediate proxies, load balancers, logging systems
Is stored temporarily for processing — cache layers, request logs, debugging infrastructure
May be retained for abuse detection — most providers log requests for safety monitoring
Could be subpoenaed — US providers are subject to US law enforcement requests, including the CLOUD Act which allows cross-border data access

The question is not "will the provider deliberately steal my code?" It's "how many systems touch my code between my IDE and the model, and who has access to those systems?"

2. Intellectual property exposure

Source code is a trade secret. Once exposed, trade secret protection can be lost permanently — unlike patents or copyrights, trade secrets only have value as long as they remain secret.

What your code reveals:

Element	What it exposes
Class and method names	Your business domain and capabilities (`FraudDetector`, `TaxCalculator`, `PatentAnalyzer`)
Package structure	Your architecture and module boundaries
Algorithm implementations	Your competitive advantage (pricing logic, recommendation engines, risk models)
Database schema	Your data model and relationships
API endpoints	Your service surface and capabilities
Configuration	Your infrastructure topology
Comments	Your business rules in plain language

A competitor with access to your AI provider's logs could reconstruct your product's architecture, business rules, and technical approach without ever seeing your actual repository.

3. Client code exposure (integrators and freelancers)

If you're a consulting firm, systems integrator, or freelance developer, the risk multiplies. You're not just exposing your own code — you're exposing your client's code.

Consider the scenarios:

You customize an ERP for a bank. You send controller code to Claude that contains transaction processing logic, compliance rules, and internal API endpoints. That code belongs to the bank, not to you.
You build a SaaS platform for a healthcare company. You use Copilot while working on patient data models. HIPAA-regulated data structures are now on Microsoft's servers.
You maintain a defense contractor's codebase. You use an AI to debug a networking module. The code may be subject to ITAR export controls — sending it to a US cloud provider may technically comply, but sending it to a Chinese provider (DeepSeek) would be a violation.

4. Regulatory and compliance risks

Depending on your industry and jurisdiction, sending source code to external AI services can create compliance issues:

Regulation	Risk
GDPR (EU)	If your code processes personal data and the code itself contains PII patterns, field names, or test data, sending it to a US server may violate data transfer rules
SOC 2	Requires documented controls over data access. Using AI tools without DLP controls may fail audit
ISO 27001	Requires risk assessment for third-party data processing. AI coding tools are a new attack vector
HIPAA (US healthcare)	Code containing PHI field names, validation rules, or test fixtures with patient data patterns
PCI DSS	Code handling payment card data, encryption keys, or tokenization logic
ITAR (US defense)	Export-controlled technical data cannot be shared with foreign persons or servers
NIS2 (EU)	Critical infrastructure operators must control their software supply chain

Even if you're not in a regulated industry, your clients might be. And their auditors will ask how their code is protected.

5. The training data question

Most AI providers now offer policies like "we don't train on your data." But:

Policies change. OpenAI initially trained on API data, then reversed course after backlash. What's the policy today may not be tomorrow's policy.
Policies have exceptions. Abuse detection, safety monitoring, and model evaluation may still use your data.
Free tiers have different rules. ChatGPT Free explicitly trains on your conversations. Many developers prototype with the free tier before switching to paid.
Subprocessors matter. The AI provider may not train on your data, but what about their cloud provider? Their logging vendor? Their CDN?
Data breaches happen. Samsung's semiconductor division leaked proprietary chip designs through ChatGPT in 2023. OpenAI suffered a data breach in March 2023 where users could see other users' chat titles. Even claude code has recently leaked!

The safest assumption: anything you send to an AI service should be treated as if it could become public.

The false sense of security

"But we use the enterprise plan"

Enterprise plans typically offer:

No training on your data
Data processing agreements (DPAs)
SOC 2 compliance of the provider

What they don't offer:

Control over where the data is processed
Guarantees about intermediate systems
Protection against subpoenas or government data requests
Deletion verification (you can't audit what you can't see)

"But we use a self-hosted model"

Self-hosted models (Llama, Mistral, CodeLlama) solve the data residency problem but introduce others:

Dramatically lower code quality compared to frontier models
Significant infrastructure costs
No access to the latest model capabilities (Claude Opus, GPT-4o)
Still requires GPU infrastructure that someone must maintain

"But we only send small snippets"

AI coding tools send more context than you think. And even small snippets reveal information:

// "Just a small function"
public BigDecimal calculateRoyalty(Contract contract, SalesReport report) {
    BigDecimal baseRate = contract.getRoyaltyRate();
    BigDecimal sales = report.getNetSales().subtract(report.getReturns());
    if (contract.hasMinimumGuarantee()) {
        return sales.multiply(baseRate).max(contract.getMinimumGuarantee());
    }
    return sales.multiply(baseRate);
}

The solution: obfuscate before sending

The principle is simple: rename everything that reveals business meaning before the AI sees it, then reverse the renaming when applying the AI's changes.

Your code:                          What the AI sees:
calculateRoyalty()          ->      mtd_a1b2c3d4()
Contract contract           ->      Cls_e5f6a7b8 fld_9c8d7e6f
getRoyaltyRate()            ->      mtd_1a2b3c4d()
hasMinimumGuarantee()       ->      mtd_5e6f7a8b()

The AI can still:

Understand the code structure (types, control flow, patterns)
Suggest refactorings and bug fixes
Add new functionality
Write tests

What it cannot do:

Infer your business domain
Reconstruct your architecture from meaningful names
Extract business rules from comments (stripped)
Identify your company from package names (flattened)

What a proper obfuscation tool must handle

It's not as simple as find-and-replace. Java's framework ecosystem means certain identifiers carry semantic meaning for the runtime:

Spring Data repository methods (findByName) derive SQL queries from the method name
Lombok generates accessor methods from field names
JPA uses entity class names in JPQL query strings
Jackson derives JSON field names from Java field names
Spring Config binds YAML keys to field names

A good obfuscation tool detects these frameworks and protects the identifiers that would break. Everything else gets renamed.

The full cycle must work

Obfuscation is only useful if the cycle is complete:

Source compiles     -> Obfuscate -> Obfuscated compiles
                                 -> AI modifies -> Still compiles
                                                -> Apply back -> Source still compiles

Every transition can break. Framework detection, JPQL string updating, comment stripping, 3-way merge for reverse-application — all are necessary for a production-ready workflow.

What you should do today

Immediate steps

Audit what your AI tools send. Enable request logging or use a proxy to see what context is transmitted. You'll likely be surprised.
Check your client contracts. Look for clauses about code confidentiality, data processing, and third-party tools. Many contracts written before 2023 don't explicitly address AI coding tools — which doesn't mean they allow them.
Establish an AI coding policy. Define which projects can use AI tools, which cannot (client code, regulated code), and what safeguards are required.
Consider obfuscation. For projects where AI assistance is valuable but code exposure is unacceptable, obfuscation provides the best of both worlds: AI productivity without IP exposure.

For regulated industries

Document your AI tool usage in your risk register. Auditors will ask.
Include AI tools in your data processing agreements with clients.
Evaluate data residency requirements. If your data must stay in the EU, most US-based AI providers don't qualify without additional safeguards.

For integrators and freelancers

Get explicit written consent from clients before using AI tools on their code.
Use obfuscation by default on client projects. It's a competitive advantage: "We use AI to deliver faster, and we protect your code while doing it."
Include AI tool policies in your contracts. Define what tools you use, how code is protected, and what the client's options are.

Conclusion

The answer is not to stop using AI tools. The answer is to stop sending your code in clear text.

PromptCape is a Java code obfuscation tool designed for AI coding workflows. It handles framework detection, compilation verification, and smart reverse-application. Free trial at PromptCape.

DEV Community: Genevieve Breton

Pandas pipelines through AI without leaking your column names

The rule pandas breaks

Where column names hide

The detection problem: the schema isn't in the code

The type-inference trap: not every x["string"] is a column

Before / after

What does NOT change (and why)

The data-file leak (the other half)

Reverse-apply and AI-invented columns

What this does NOT protect

Conclusion

Django obfuscation for AI assistants: 6 invisible contracts we found the hard way

The setup

Iteration 1 — 'django.db.migrations' has no attribute 'Cls_270e5090'

Iteration 2 — urlpatterns doesn't appear to have any patterns

Iteration 3 — ModelForm has no model class specified

Iteration 4 — no such table: blog_cls_b8106b41

Iteration 5 — empty post list when the database has posts

Iteration 6 — clean_body silently disappears

What the detector looks like at the end

Why discover-by-name is the recurring shape

Conclusion

Python obfuscation for AI assistants: runnable workspaces and off-disk secrets

Java vs Python: a different relationship with the workspace

Names that double as string contracts

--verify for Python: import resolution, not compilation

Comments and docstrings: line count is the load-bearing property

The .env problem

promptcape run: inject .env at subprocess launch, never on disk

The complete Python cycle

A note on what this does NOT protect

Conclusion

The AI Code Protection Landscape: 13 Products Compared

The problem

The three axes in detail

Axis 1 — On-premise vs SaaS

Axis 2 — CISO tool vs developer tool

Axis 3 — Coverage of the full cycle

Comparison table

Reading the table by axis

By deployment

By target user

By coverage of the full cycle

Categorical, not directly comparable

A pragmatic decision matrix

Honesty about gaps in this comparison

Conclusion

References

PromptCape vs PromptBase: similar names, different products

PromptBase, in one paragraph

PromptCape, in one paragraph

Side by side

Why the names look so close

Which one do you actually need?

Building a transparent terminal-based proxy for Claude Code in Cursor (or any IDE)

The decision: don't wrap the IDE, wrap the network

The bare minimum

Trap 1: streaming responses

Trap 2: accept-encoding

Trap 3: don't translate tool blocks

Trap 4: HTTP/2 pseudo-headers

Trap 5: making it forget-about-it-able

The Cursor angle: there is no Cursor angle

Why this generalizes

Building a transparent terminal-based proxy for Claude Code in Cursor (or any IDE)

The decision: don't wrap the IDE, wrap the network

The bare minimum

Trap 1: streaming responses

Trap 2: accept-encoding

Trap 3: don't translate tool blocks

Trap 4: HTTP/2 pseudo-headers

Trap 5: making it forget-about-it-able

The Cursor angle: there is no Cursor angle

Why this generalizes

Reverse-applying AI changes to obfuscated code: a 3-way merge that actually works

The naive reverse

The mental shift: it's a merge, not a translation

The easy case: same line count

The hard case: AI added or removed lines

The type-inference trap: not every `x["string"]` is a column

Iteration 1 — `'django.db.migrations' has no attribute 'Cls_270e5090'`

Iteration 2 — `urlpatterns` doesn't appear to have any patterns

Iteration 3 — `ModelForm has no model class specified`

Iteration 4 — `no such table: blog_cls_b8106b41`

Iteration 6 — `clean_body` silently disappears

`promptcape run`: inject `.env` at subprocess launch, never on disk