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 is no longer email or a USB stick. It is a chat window open to fix a release, with nothing watching what gets pasted in. 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 never reach 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 instead 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 no view of the payload.

• -

  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, not just ports and addresses.

Next-generation firewall features

Several capabilities separate an NGFW from its predecessors:

• -Deep packet inspection that reads content rather than 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 instead 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 cannot see 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 no NGFW is the right pick for the "best next-generation firewall for AI." The risk lives in the content of a conversation with a third-party model, not in 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 could not be recalled, and the ban that followed did not 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 had no access controls on the tools at all.

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 rather than 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:

1. -Search Google for site:chatgpt.com/share alongside the company name, product names, or internal codenames. Anything that returns is a shared conversation already public.
2. -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.
3. -Check whether any current control reads the content of prompts headed to AI APIs. For most stacks the answer is that nothing does, and that is the gap.

Why existing security tools miss it

The reflex is that current tools already cover this. They do not, and 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, not code. A function named calculateCustomerLifetimeValue or a class named AutonomousDrivingPerceptionPipeline gives away architecture and intellectual property, yet matches no DLP pattern, 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 reads no payload to judge whether proprietary code is riding inside.
• -Code scanning (Gitleaks, Semgrep, Trivy) analyzes committed code for known vulnerabilities and secrets. It runs on the repository, not on live prompts. By the time it flags a secret in a pull request, the developer already pasted it into ChatGPT while debugging.

None of these tools are weak at their actual jobs. The code-to-AI path is simply a gap none 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. Answers stay useful because the model reasons about structure and logic, not the names.
• -Secret blocking detects and stops API keys, credentials, and personal data in AI-bound traffic. Unlike general DLP, it 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, not redaction

Most tools that protect a prompt work by stripping the sensitive parts out. Redact 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 instead. It swaps a value for a realistic stand-in before the prompt leaves the machine, then restores the true value in the response locally. 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. It never learns that the code models customer lifetime value or how the churn prediction works. The business logic 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 rather than 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, not the only one.

How the Pretense AI firewall works

Setup takes about thirty seconds and no procurement. A developer installs the CLI, points the AI tool at the local proxy, and mutation, reversal, 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.