Prompt-Eligibility: The Missing Column in Your Data Classification

Pull up your company's data classification policy. Public, internal, confidential, restricted — four neat tiers, each mapped to a set of access controls and a list of approved storage locations. Now ask a question the policy was never written to answer: which of these tiers are allowed to leave the corporate perimeter as a token sequence sent to a third-party model API?

The answer is almost always silence. Not because the policy is wrong, but because it is incomplete. Every classification scheme in use today was designed for an access vector that asks "is this employee allowed to read this row?" The prompt layer introduced a different vector entirely: an authorized service reads the row, transforms it into a prompt, and ships it across the network to a vendor that may log it, train on it, or hold it in plaintext for thirty days. None of that is read-access. None of it is covered.

This is the missing column. Until you add it, your data classification document is confidently asserting a control posture you do not have.

Read-Access Is Not Egress-Eligibility

The core conceptual error is treating "the calling service has permission to fetch this field" as the only check that matters. It was the only check that mattered when the destination was a database join, an internal microservice, or a log line in your own infrastructure. Once the destination is api.openai.com or api.anthropic.com, four new questions appear, and read-access answers none of them.

First: does the vendor retain the prompt? Most providers' default consumer terms allow logging for thirty days or longer for abuse review, and some retain indefinitely for service improvement. Enterprise tiers can negotiate down to seven days or zero, but only if you signed the agreement and only for the products it covers. Anthropic, for example, recently dropped default API log retention from thirty days to seven, and offers true zero-data-retention only to qualifying enterprise customers and only for specific API products — not for everything that talks to a Claude endpoint.

Second: can the prompt enter a training set? Even when "no training on customer data" is the default for paid API tiers, that promise is contractual, not architectural. It applies only to the products and accounts named in the data processing agreement. A side project on a personal API key is not covered. A team that signed up for a new product line is not covered until procurement reviews it.

Third: where does the prompt physically land? A US-resident customer's data routed through an EU-hosted gateway to a US-hosted model crosses two jurisdictions. Whether that crossing is lawful depends on transfer mechanisms (SCCs, adequacy decisions, the post-Privacy Shield framework) that your read-access ACL knows nothing about.

Fourth: who else sees the byte stream in flight? Inline DLP gateways, observability vendors, prompt-injection scanners, and analytics tools may all process the prompt before it reaches the model. Each is its own subprocessor, each requires its own DPA, and each is invisible to the application code that built the prompt.

Read-access answers none of these. Prompt-eligibility is a function of data sensitivity and the destination contract — and the destination contract is a moving target measured in vendor SKUs.

What a Prompt-Eligibility Tier Looks Like

The fix is not to bolt warning labels onto the existing classification scheme. The fix is to add a parallel classification — call it prompt-eligibility — that is computed, not declared, and that resolves to a list of allowed model endpoints rather than a list of allowed users.

A workable scheme has three or four tiers, each with a contract requirement attached:

• Open: prompt-eligible to any model, including consumer-tier APIs and unverified vendors. Public marketing copy, documentation, open-source code.
• Bounded: prompt-eligible only to vendors with a signed DPA that prohibits training on inputs and bounds retention to a documented window. Most internal business data, non-public roadmaps, customer-facing communications stripped of identifiers.
• Restricted: prompt-eligible only to vendors with an active zero-data-retention agreement covering the specific API product in use. PII, financial records, employee data, source code with embedded secrets-handling.
• Prohibited: not prompt-eligible to any external vendor regardless of contract. Authentication secrets, raw cardholder data, regulated health data in jurisdictions where the vendor cannot demonstrate compliance, anything covered by export control.

The critical move is that "Restricted" is not a property of the data alone. It is a function that takes the data tier and the model endpoint and returns allow/deny. The same field — say, an employee's home address — is prompt-eligible against a self-hosted Llama instance, prompt-eligible against an Azure OpenAI deployment with ZDR enabled, and prompt-ineligible against the public OpenAI API even though the company has an enterprise contract for a different product.

This is uncomfortable because it means the classification decision cannot be made once at the data layer and then forgotten. It has to be evaluated at prompt-construction time, against the specific endpoint the prompt is about to be sent to. That sounds expensive. It is the actual shape of the problem.

Audit Every Prompt Template Like It's a Database Query

Most teams treat prompt templates as application code. They live in a repo, get reviewed in a PR, and ship when CI passes. From a privacy perspective this is wrong: a prompt template is closer to a SQL query that exfiltrates data to an external party. It deserves the same review rigor as a SELECT running against a regulated table.

The audit pass that has to land — and that nobody currently runs — looks like this. For every template in the codebase, surface every interpolated field. For each field, document its source table or service, its current data classification, and its prompt-eligibility tier. Cross-reference the eligibility tier against the model endpoint the template targets. Block the change if any field's eligibility tier prohibits that endpoint. Require sign-off if any field's eligibility tier is more permissive than the template author appears to have realized.

This is grindy work. It is also the only audit that catches the failure mode that has burned everyone who has been burned. The Samsung incident in 2023 — three separate engineers pasting source code, meeting transcripts, and yield-test sequences into ChatGPT within weeks of an internal ban being lifted — was not a failure of the data classification policy. The policy probably correctly tagged that source code as confidential. It was a failure of nobody having drawn a boundary between "engineer is allowed to read this code" and "engineer is allowed to send this code to a vendor we have no contract with." A template-level audit would not have stopped a copy-paste, but it would have stopped the institutional version of the same mistake: an internal tool quietly interpolating that source code into a prompt and shipping it to a model nobody flagged.

The 2025 EchoLeak vulnerability in Microsoft 365 Copilot makes the inverse case. There the classification was correct, the contract was correct, but a prompt-injection chain caused Copilot to embed sensitive context into an outbound link that bypassed the redaction layer. The takeaway is not that audits are pointless against adversaries; it is that the egress channel exists whether you mapped it or not, and adversaries are mapping it before you are.

Redact at Construction Time, Not at the API Boundary

A common architectural mistake is to push redaction to the AI gateway — a centralized proxy that sits between application code and the model API and enforces policy on outbound traffic. This is correct as a defense-in-depth layer. It is wrong as the primary control.

By the time a prompt reaches the gateway, the application has already assembled the byte stream. The decision about which fields to interpolate has already been made. If the application chose to embed an employee SSN in the system prompt, the gateway can pattern-match and redact it, but the gateway is now operating with low context: it sees 123-45-6789 and has to guess whether that is an SSN, a part number, or a serialized timestamp. False positives break legitimate prompts; false negatives ship the SSN.

The correct primary control is at prompt-construction time, where the application code knows exactly which field is which and can make a typed decision: "this is a EmployeePII.SSN, the active model endpoint is Bounded, the eligibility map says Restricted data cannot be sent to a Bounded endpoint, refuse." The gateway is then a backstop that catches construction-layer bugs, third-party libraries that interpolate fields the application did not authorize, and prompt-injection chains that smuggle restricted data into outputs.

This inverts the popular AI-gateway-as-savior architecture. The gateway is necessary but it is not the boundary. The boundary is wherever a typed value gets concatenated into a string that will become a prompt — usually inside a feature team's code, and usually invisible to the security team's threat model.

Map Your Vendor Stack to Your Eligibility Tiers

The last piece is operational. Every model endpoint your stack can reach — including the ones a feature team added last month, the ones embedded in a SaaS tool you bought, and the ones a contractor wired into an internal demo — needs to be tagged with its current contract status. Default API tier with thirty-day retention. Enterprise API with seven-day retention and no-training default. Enterprise API with negotiated zero-data-retention. Self-hosted with no external egress. Each tag determines which prompt-eligibility tier may be sent to it.

This list goes stale fast. Vendors change defaults. Products move between SKUs and inherit different terms. A team upgrades to a new API version and silently exits the contract that covered the old one. The audit cannot be a one-time exercise; it has to be a quarterly reconciliation that every feature team owes evidence for. Some of the better AI gateway implementations now do this enforcement automatically — Cloudflare, Vercel, Kong, and others ship variants of policy-tagged routing that refuses to forward a Restricted payload to a non-ZDR endpoint — but the gateway only knows what the application told it. Garbage tagging in, plausible compliance theater out.

The cost frame nobody surfaces is that this is platform work. It does not show up in feature velocity, it does not move a product metric, and it competes for engineering hours against things that do. The team that does it spends a quarter not shipping much. The team that does not spend that quarter is fine right up until a regulator asks "what data left your perimeter as model inputs in 2026?" and the answer is a shrug. The EU AI Act enforcement deadline for general-purpose models passed in August 2026 with maximum fines reaching seven percent of global revenue. That is the frame finance understands.

The Architectural Realization

The prompt layer is a data egress channel that your existing DLP scheme did not model. Email, file storage, and outbound network traffic all have controls. The prompt layer slipped past those controls because it looks like an internal API call from inside the application, and because the data leaving it does not look like a file or an email — it looks like ordinary string interpolation, the kind every developer writes a hundred times a day without thinking about it as exfiltration.

Naming the channel is the first move. A column in the data classification document that says "prompt-eligibility tier" and a corresponding inventory of "approved model endpoints by tier" forces a conversation that today happens only in incident postmortems. Once the column exists, the audit that fills it forces every prompt template into the same review surface as every other piece of code that touches sensitive data — which is where it should have been from the start.

The organizations that have not done this are not necessarily wrong yet. They are unscored. The day a regulator, a customer security review, or a class-action discovery process asks the question, the absence of an answer is the answer. The work to build the answer is not glamorous and does not market well. It is, however, exactly the kind of platform investment that retroactively looks obvious — the way the first DLP rollouts looked obvious in hindsight, after the breach. The team that names the column now is the team that does not have to invent the audit trail later.