The Permanent Problem
Every useful AI coding tool needs context to work. That context is your code. The more context you provide, the better the output. The less context you provide, the less useful the tool becomes.
This is a lasting feature of the technology, well beyond a temporary technical limitation. It is the fundamental architecture of how large language models generate code. Transformers operate on token sequences. The quality of generated tokens is directly proportional to the quality and volume of input tokens. To get a useful code completion, the model needs to see your function signatures, your variable names, your class hierarchies, your business logic patterns.
That means every AI coding interaction is an information transfer event. Your proprietary identifiers -- the names that encode your architecture decisions, your domain model, your competitive advantages -- leave your network and enter someone else's infrastructure.
The information asymmetry between code creators and AI systems is a structural property of the interaction, and better models will keep it in place. Better models need MORE context, and less is off the table. The problem grows with capability.
This is why AI code security is a permanent category, far bigger than a feature request.
Why Better AI Makes It Worse
There is a common assumption that AI security problems are temporary. The reasoning goes: as models improve, they will need less context. They will understand intent from fewer tokens. Eventually, you will be able to give them abstract descriptions and get back working code.
This assumption is wrong, and the evidence is already clear.
GPT-3.5 in 2023 worked with 4K context windows. GPT-4 expanded to 128K. Claude 3.5 went to 200K. Claude 4 supports 1M tokens. Every generation of model improvement has INCREASED context requirements, every single time.
The reason is straightforward. Larger context windows enable more sophisticated tasks. A 4K context window limits you to single-function completions. A 200K window lets you refactor entire modules. A 1M window lets you restructure applications. Each jump in capability requires proportionally more of your codebase in the prompt.
The trajectory is clear:
- -2023: Autocomplete a function (needs 1 file)
- -2024: Refactor a module (needs 10-20 files)
- -2025: Architect a feature (needs 50-100 files)
- -2026: Autonomous agent sessions (needs entire repo context)
- -2030+: Cross-repository reasoning (needs multiple repos, documentation, deployment configs)
Every step forward in AI capability is a step forward in code exposure. The attack surface keeps growing. It expands with every model generation.
Decade 1: AI Code Security (2026-2036)
The first decade is about protecting developer code from AI APIs. This is the market that exists today.
The numbers frame the opportunity. GitHub Copilot has 1.8 million paid subscribers as of Q1 2025. Cursor has over 500,000 active users. Claude Code is the fastest-growing coding tool in enterprise. Every one of these tools sends proprietary code to external servers on every interaction.
The total addressable market for AI code security tools in 2026 is approximately $172 billion when measured against the broader developer security tooling category. The serviceable addressable market -- teams actively using AI coding tools in environments with proprietary code -- is roughly $8-12 billion and growing at 40%+ annually.
In this first decade, the product category looks like what Pretense builds today:
- -Proxy-layer mutation: Intercept API calls, mutate identifiers, swap identifiers back on response
- -Audit logging: Track every interaction, store mutation maps, generate compliance evidence
- -Policy enforcement: Define what may leave the network and what stays
- -Multi-provider support: Protect across OpenAI, Anthropic, Google, and any new provider
- -CI/CD integration: Block unprotected API calls in build pipelines
The key technical challenge in Decade 1 is latency. The mutation layer sits in the hot path of every request. At Pretense, the Rust scanner processes tokens in 1.82ms. That budget gets tighter as AI tools move from request-response to real-time streaming with sub-100ms expectations.
The key business challenge is adoption. Security tools that slow developers down get disabled. The mutation approach -- where the developer workflow stays exactly the same -- is critical. One environment variable, and you are protected. The same workflow, zero manual review steps, zero approval queues.
By 2036, AI code security will be as standard as HTTPS. Every enterprise will have it. The open question is which protocol wins.
Decade 2: AI System Governance (2036-2046)
The second decade extends beyond developer tools into autonomous AI systems operating across all business functions.
By 2036, AI agents will do far more than write code. They will execute business processes. They will manage supply chains, negotiate contracts, analyze financial models, and make operational decisions. Each of these activities involves proprietary information -- code plus business logic, pricing models, customer data, strategic plans.
The governance problem scales in three dimensions simultaneously:
1. More systems: Where today an organization runs 5-10 AI coding tools, enterprises will operate hundreds of AI agents across departments. Each agent needs access to proprietary data. Each access point is an exposure vector.
2. More autonomy: Today, a developer reviews every AI output before it reaches production. By 2036, AI agents will operate with delegated authority -- making decisions and taking actions with human review reserved for selected steps. The security boundary moves from "protect the prompt" to "protect the agent's operating context."
3. More interconnection: AI agents will communicate with other AI agents. An AI procurement agent will negotiate with a supplier's AI sales agent. Proprietary pricing logic, margin structures, and strategic priorities will flow through these inter-agent communications.
The mutation concept translates directly to this expanded surface. Beyond mutating code identifiers before they reach an LLM API, you mutate business identifiers before they reach any external AI system. The algorithm is the same. The scope is larger.
The audit requirement also scales. In Decade 1, audit logs track which code tokens were mutated in which API calls. In Decade 2, audit logs must track which business decisions were made by which agents using which proprietary context. The compliance surface expands from SOC2 and HIPAA to include AI-specific regulations that will emerge between 2028 and 2035.
Organizations that build mutation infrastructure in Decade 1 will have the audit corpus and operational patterns to extend into Decade 2 naturally. This is the strategic value of early adoption -- the data asset compounds.
Decade 3: Intelligence Boundary Protocol (2046-2056)
The third decade is speculative, but the direction is visible from current trajectories.
By 2046, the distinction between "AI system" and "software system" will be meaningless. Every piece of software will include AI components. The question of "which systems should we protect our data from" becomes "how do we define and enforce information boundaries across all computational interactions."
This is where AI code security evolves from a product category into infrastructure protocol. The way HTTPS became the default transport layer for web traffic, intelligence boundary protocols will become the default information exchange layer for AI-mediated interactions.
The protocol requirements:
- -Deterministic transformation: Any piece of proprietary information can be transformed into a semantically equivalent synthetic before crossing a trust boundary. The transformation must be reversible by the originator and only the originator.
- -Audit provenance: Every transformation event is recorded with enough metadata to reconstruct what information crossed which boundary at what time.
- -Policy expression: Organizations can define fine-grained policies about what information can cross which boundaries under what conditions.
- -Interoperability: The protocol works across vendors, platforms, and national jurisdictions.
Each of these requirements already exists. They are the same requirements Pretense implements today for code identifiers. The difference is scope -- from code tokens to all forms of proprietary information, from individual API calls to all computational interactions.
The organizations, open source communities, and standards bodies that shape this protocol will likely emerge from the AI code security category. The people building mutation engines today are developing the intuitions and technical foundations that will inform the protocol design of 2046.
What Survives Each Shift
Across all three decades, four assets compound regardless of how the market evolves:
1. The mutation algorithm: Deterministic, reversible transformation of identifiers is useful at every scale. The specific implementation changes -- from regex-based scanning to AST-aware analysis to semantic understanding -- but the core operation (transform before transit, swap identifiers back on receipt) is permanent.
2. The audit corpus: Every mutation event recorded today is training data for smarter mutation tomorrow. The patterns of what gets mutated, what gets missed, what causes false positives -- this operational data is the actual moat. Replicating it requires processing real-world codebases at scale.
3. Enterprise relationships: The CISO who deploys Pretense for AI code security in 2026 will need AI system governance in 2036. Trust relationships in enterprise security compound over decades. The vendor who proves reliability in Decade 1 has an unfair advantage in Decade 2.
4. Protocol influence: The technical decisions made in early implementations shape the eventual standard. UTF-8, HTTP, TLS -- these protocols reflect the architectural decisions of their earliest implementations. The AI security protocol of 2046 will reflect the design patterns established in 2026.
This is why the strategic imperative is to start now, even though the full 30-year vision is still ahead. The assets that matter most -- audit data, enterprise trust, protocol influence -- are time-dependent. Money spent later can only buy them back at a steep discount in time.
The Protocol End State
The end state of AI code security is a protocol, well beyond a product.
Consider what happened with web security. In 1995, SSL was a product sold by Netscape. By 2000, it was a feature of every web server. By 2010, it was an expected default. By 2020, browsers actively warned users away from sites that lacked it. The protocol (TLS) survived. Individual products came and went.
AI code security will follow the same arc:
- -2026: Mutation is a product (you install Pretense)
- -2030: Mutation is a feature (IDEs include it natively)
- -2035: Mutation is expected (enterprises require it by default)
- -2040: Absence of mutation is a vulnerability (regulatory and compliance pressure)
- -2045: Mutation is invisible (built into every AI interaction, like HTTPS)
The question for any company in this space is: do you want to be the Netscape that proves the concept, or the protocol designer whose architecture becomes the standard?
The answer is both. You prove the concept by shipping product. You shape the protocol by accumulating the operational data and enterprise deployments that inform standard design.
Pretense is built for this trajectory. Local-first architecture means the protocol stands on its own, independent of a central service. Open and auditable mutation means the algorithm can be standardized free of vendor lock-in. The audit format is designed for portability as well as internal use.
What This Means for You
If you are a developer using AI coding tools today, the immediate action is straightforward: put a mutation layer between your code and the API. It takes 30 seconds with Pretense. Set one environment variable and your proprietary identifiers stay on your machine, with only stand-ins traveling to the API.
npx @pretense/cli init
npx @pretense/cli start
export ANTHROPIC_BASE_URL=http://localhost:9339
That is the entire setup. Your workflow stays the same. Your AI tool output quality holds. Your code stays yours.
If you are a CISO evaluating AI security tooling, the category framework matters more than any single product evaluation. AI code security is an emerging infrastructure category that will expand to cover all AI-mediated information exchange over the next three decades, far more than a point solution you buy and forget.
The evaluation criteria should be:
- -Architecture: Is it local-first (data stays on your network) or cloud-dependent?
- -Approach: Does it mutate (preserve context) or strip values the way redaction tools do (break context)?
- -Audit: Does it generate compliance-ready evidence automatically?
- -Extensibility: Can it grow from code protection to broader AI governance?
- -Standards alignment: Is the approach compatible with emerging regulatory frameworks?
The companies that adopt AI code security early protect their current code and also build the operational foundation for AI governance that will be required -- by regulation, by customers, by insurers -- within the next decade.
The 30-year clock is already running. AI code security is on track to become standard infrastructure. The real question is whether you are building on it now or retrofitting it later.
How I run Pretense on my own code
I build Pretense with Claude Code, and my sessions run through it. Here is the setup I give a new engineer, in order.
- -Run the agent through the proxy. Type
pretense run claudewhere you would typeclaude. It starts a local proxy on port 9339, points Claude Code at it and stops the proxy when the session ends. Detected secrets and PII leave the laptop as stand-in tokens. - -Put hooks on every repo.
pretense installadds a pre-commit and a pre-push hook. A key that never lands in git is a key an agent never reads. - -Scan before an agent reads the repo.
pretense scan path .lists what it finds. In CI,pretense scan ciexits 0 when clean, 2 on findings and 3 when it examined nothing. Treat 3 as a failure. - -Preview the swap.
pretense review .shows what would be mutated.pretense mutate <file> --previewprints one file mutated and leaves the file on disk as it was. - -Round-trip a file you need to share.
pretense mutate <file> --map <map>swaps the secrets in place.pretense reverse <file> --map <map>turns it back into the original, byte for byte, from the encrypted map on your machine. We run that round trip on real files before every CLI release and compare sha256 hashes.
One thing I learned the hard way: inside a session the agent sees stand-ins, so a file the agent writes can hold a stand-in where you expected a real value. Grep what the agent wrote before you ship it.
What Pretense will not do is put a secret back into the model's answer. Code identifiers come back byte-exact. Secrets and PII stay as stand-ins in the response. That is deliberate: a prompt-injected model can echo a token into a link, and reversing it there would hand over the real key.
What this means if you buy security
The outcome: your engineers keep their AI coding tools, and detected secrets and PII leave each laptop as stand-in tokens.
- -The control sits on the endpoint. The swap runs on the developer's machine before the request leaves. No shared gateway holds every team's keys.
- -You get evidence, not a memo.
pretense audit --format csvexports every mutation event. Add--framework SOC2to keep only the events that map to that framework. - -Check it on your own code. Detection is pattern and entropy based, and coverage varies by data type. Run
pretense review .on a real repo and read what it catches before you sign off. - -Start with one team. One repo,
pretense run claude, one week. Then read the audit log with the team lead.
Try it on your own repo: create a free account, then run npm i -g @pretense/cli and pretense run claude. If you need a security review first, talk to me.