The AI firewall era: from next-generation firewalls to protecting the code developers send to AI
The firewall has been rebuilt about once a decade for forty years. Each version caught a threat the last one missed, from packets on a wire to traffic hitting a web app.
The newest version is the AI firewall, and it exists for one reason: proprietary code and secrets now leave the building inside prompts to ChatGPT, Claude, and Copilot. An AI firewall sits between a developer and the model and controls what those prompts can carry.
The numbers make the case. Stack Overflow's 2025 survey put developer AI adoption at 84 percent, with 51 percent of professionals using these tools daily. For most engineering teams, the likeliest path for source code to leak has moved past email or a USB stick. Today it is a chat window open to fix a release, with an unwatched paste box. Network security in 1993 looked much the same, right before the firewall became mandatory.
What is the firewall for AI?
A firewall for AI, also called an AI firewall or LLM firewall, is a security layer between a user and a large language model that inspects traffic both ways. Inbound, it catches what should stay away from a model: secrets, credentials, personal data, proprietary source code, and prompt-injection attempts. Outbound, it screens the response before it returns. Same idea as a next-generation firewall, only pointed at a conversation with a model in place of a network connection.
In practice, working tools already exist. Pretense is one, and there are others built for different parts of the problem.
What are the four types of firewalls?
Four types came before the AI firewall, each one deeper than the last:
- -
Packet-filtering firewalls (late 1980s, Digital Equipment Corporation). They read each packet's source, destination, and port, then allow or drop it, with the payload out of view.
- -
Stateful inspection (early 1990s, Check Point and AT&T). It tracks whole connections, so the firewall can tell an expected reply from an unsolicited probe.
- -
Proxy firewalls, also called application-level gateways. They sit between client and service and inspect at the application layer, which allows finer control over what a request is doing.
- -
Next-generation firewalls. The current standard, and the subject of the next section.
The fifth type is arriving now, and it is the AI firewall.
What are next-generation firewalls?
Next-generation firewalls, or NGFWs, are what most enterprises run today. Palo Alto Networks defined the category around 2010. An NGFW keeps the traffic control of the earlier types and adds inspection deep enough to identify applications and threats, going beyond ports and addresses.
Next-generation firewall features
Several capabilities separate an NGFW from its predecessors:
- -Deep packet inspection that reads content as well as headers.
- -Application awareness that recognizes an app regardless of the port it uses.
- -Inline intrusion prevention that blocks known attacks as they pass.
- -User-based access control tied to identity in place of IP address.
- -TLS inspection that lets the firewall see inside encrypted traffic.
All of it runs in one appliance, acting at the application layer.
Why the best next-generation firewall still misses the AI problem
An NGFW watches traffic crossing the network and entering applications, and it handles that job well. The trouble sits at a different boundary. When a developer pastes source code into ChatGPT, the NGFW sees a normal encrypted HTTPS connection to a legitimate domain and passes it, because the contents of the prompt are invisible to it.
So the right pick for the "best next-generation firewall for AI" is a different kind of tool altogether. The risk lives in the content of a conversation with a third-party model, away from the network path. Different boundary, different firewall.
We are in the pre-firewall era of AI security
Pretense laid this out in an analysis of six major AI security incidents over twelve months, and the incidents rhyme.
Consider the evidence. LayerX, working from real enterprise browsing telemetry, found that 40 percent of files uploaded to generative AI tools contain PII or payment data, and that generative AI is now the largest channel for corporate data leaving for personal destinations, at 32 percent of all such movement.
Around the same time, roughly 4,500 shared ChatGPT conversations were indexed by Google in mid-2025, some of them carrying business strategies and developer credentials, before OpenAI shut the feature off. And Samsung's semiconductor division had three separate engineering teams paste proprietary source code and internal notes into ChatGPT inside about twenty days of gaining access. That data was gone for good, and the ban that followed failed to hold.
Then there is the money. IBM's 2025 Cost of a Data Breach report found that shadow AI, meaning unapproved AI tools staff adopt on their own, added an average of 670,000 dollars to a breach. One in five breached organizations involved shadow AI, and among those that had an AI-related breach, 97 percent lacked access controls on the tools entirely.
The closest historical match is 1993. The internet was expanding, companies were wiring internal systems straight to the network, and firewalls were rare. The Morris worm had already shown the risk. Within a few years the network firewall went from optional to mandatory, driven by a growing pile of incidents more than by one disaster. The same accumulation is happening now, except the exposed connection runs between developers and a language model.
A check any team can run this week
Measuring exposure takes an afternoon, well before any tool conversation. Three checks are enough to start:
- -Search Google for
site:chatgpt.com/sharealongside the company name, product names, or internal codenames. Anything that returns is a shared conversation already public. - -Find out which AI tools developers actually reach for, personal accounts included, since that is where most leakage runs. LayerX measured 82 percent of pasted data moving through unmanaged personal accounts.
- -Check whether any current control reads the content of prompts headed to AI APIs. For most stacks the answer is that zero controls do, and that is the gap.
Why existing security tools miss it
The reflex is that current tools already cover this. Each one misses for a specific reason:
- -Cloud DLP (Nightfall, Symantec, Zscaler) scans outbound data for known patterns like card numbers, Social Security numbers, and API keys. It was built for structured secrets, with code outside its design. A function named calculateCustomerLifetimeValue or a class named AutonomousDrivingPerceptionPipeline gives away architecture and intellectual property, yet matches zero DLP patterns, so it sails through.
- -Endpoint detection and response (CrowdStrike, SentinelOne, and peers) catches malware and unauthorized access. An EDR agent sees an HTTPS connection to an AI API and calls it legitimate, and it skips the payload, so proprietary code rides inside unseen.
- -Code scanning (Gitleaks, Semgrep, Trivy) analyzes committed code for known vulnerabilities and secrets. It runs on the repository, away from live prompts. By the time it flags a secret in a pull request, the developer already pasted it into ChatGPT while debugging.
Each of these tools is strong at its actual job. The code-to-AI path is simply a gap outside what any of them was built to cover.
What an AI firewall actually does
At the AI boundary, an AI firewall closes that gap with three functions:
- -Identifier mutation replaces proprietary code identifiers, the function, variable, and class names, with synthetic stand-ins before a prompt reaches a model, and swaps them back byte-exact in the answer. Answers stay useful because the model reasons about structure and logic, independent of the names.
- -Secret swapping detects API keys, credentials, and personal data in AI-bound traffic and replaces them with stand-ins that stay stand-ins in the answer by design. Where general DLP is broad, this targets the code-to-AI pipeline directly.
- -Audit logging records every AI interaction with a timestamp, the provider, what was protected, and a risk score, which hands the compliance team an evidence trail.
Mutation over redaction
Most tools that protect a prompt work by stripping the sensitive parts out. Strip the secret, block the field, send the rest. The model then gets a prompt full of holes, loses the thread, and degrades with each turn.
Pretense uses mutation in its place. It swaps a value for a realistic stand-in while the prompt is still on the machine. In the response, it swaps code identifiers back to their real names locally, byte-exact, while secrets and personal data stay as stand-ins by design, so a prompt-injected model has only stand-ins to exfiltrate. On a real function it looks like this:
// What the developer wrote
async function calculateCustomerLifetimeValue(customer, revenueHistory) {
const churn = await this.churnModel.predict(customer);
// ...
}
// What the AI receives
async function _fn4a2b(_v3b1c, _v8a2f) {
const _v9d8e = await this._v5f6a._fn2c3d(_v3b1c);
// ...
}
The model sees the math, the control flow, and the data structures, which is enough to debug the logic. The fact that the code models customer lifetime value, and how the churn prediction works, stay on your machine. The business logic stays put.
| Redaction or blocking | Mutation (Pretense) | |
|---|---|---|
| Sensitive value | Removed or masked | Swapped for a realistic stand-in |
| What the model sees | A prompt with gaps | A complete, working prompt |
| Answer quality | Slips over a long session | Holds at full quality |
| Where it runs | Often a cloud service | On the machine, locally |
| Real data leaving the device | Sometimes | Stays put |
AI firewall for enterprise AI security
For enterprise AI security, catching a leak is half the job. Proving it is the other half. Because every AI interaction through Pretense is logged, the result is an audit trail: what left, what was protected, who sent it, and when.
That trail reaches past any single standard, because frameworks mostly ask for the same underlying controls in different words. The access-control and data-handling evidence a SOC 2 auditor wants also answers requirements in ISO 27001, HIPAA, PCI DSS, GDPR, and the EU AI Act. Pretense is built to produce audit evidence that maps to 36 frameworks used across regions, so one set of logs supports many audits at once.
One wording note that careful buyers watch for: producing evidence that helps satisfy a framework differs from being certified against it. Pretense is currently pursuing its own SOC 2 and ISO 27001 certification, and the roadmap states plainly what is done and what is in progress.
Pretense as an AI firewall software
Pretense is an open-source AI firewall aimed at the boundary the other tools skip: the code developers send out to AI every day. It runs locally as a proxy on the developer's machine, uses mutation in place of redaction so the AI stays useful, and produces the audit trail compliance needs. Most tools in the category protect the AI apps a company builds for its own customers. The outbound, developer-side lane is newer, and it is where Pretense started. It is one option there among several.
How the Pretense AI firewall works
Setup takes about thirty seconds and zero procurement. A developer installs the CLI, points the AI tool at the local proxy, and mutation, identifier swap-back, and logging run automatically from there.
# Deploy the AI firewall
curl -fsSL https://pretense.ai/install.sh | sh
pretense init
# Point the AI tool at the local proxy
export ANTHROPIC_BASE_URL=http://localhost:9339
Because Pretense works across model providers, the same protection covers ChatGPT, Claude, Gemini, Copilot, Cursor, and any OpenAI-compatible API, so developers keep the exact tools they use.