The Half-Life of a Prompt Is Shorter Than Your NDA

Sometime in late 2024, the term “prompt engineer” stopped being a meme and started showing up on org charts. By the end of 2025, I had personally watched three different companies set up internal “prompt repositories” — version-controlled, access-restricted, marked CONFIDENTIAL in the document properties, with NDAs covering anyone who could read them. One of them had its outside counsel review the repo’s labeling scheme. Another had hired a prompt-engineering manager whose job description included “protecting our prompt IP.”

There is no tactful way to say this, so I’ll just say it. Every dollar spent on those programs was protecting a thing that does not exist.

The U.S. Copyright Office settled the question on January 29, 2025, in Part 2 of its Copyright and Artificial Intelligence report. Prompts alone, the Office concluded, do not give the user sufficient control over expression to claim authorship of AI-generated output. That is not a doctrinal detail; it is the foundational layer of “prompt as IP” being officially declared structurally absent. There is nothing for copyright to attach to. The legal protection that most prompt-protection programs implicitly assume exists has not existed for over a year.

That settled, the industry pivoted to trade secret. Trade secrets work, the argument went. Trade secrets cover anything that derives economic value from not being generally known. Sophisticated, internally-developed prompts qualify, as long as you take reasonable measures to keep them confidential.

This is true. It is also, in any deployment that matters, beside the point. Because the moment your prompt is encoded in a queryable agent — the moment it ships, the moment a customer can poke at it, the moment an attacker can prompt-inject it — the trade secret leaks. And in 2026, that leak is not a theoretical risk in a research paper. It’s happening, in the wild, every day, against deployed enterprise agents.

The protection model the industry has built for prompts is theater built on top of theater. Let me show you where the actual protection lives.

The strongest version of the prompt-as-IP argument

Before I dismantle this, I owe the dominant view its best shot, because I have watched smart people argue for prompt-as-IP and the steelman is real even where the conclusion is wrong.

Here is the strongest case for treating prompts as protectable assets. Inside a closed enterprise environment — call it a Fortune 500 with controlled SSO, access-logged repositories, and a workforce under tight NDA — a sophisticated prompting package can absolutely qualify as a trade secret. It encapsulates institutional knowledge. It transforms a general-purpose foundation model into a tool that knows your business, your terminology, your decision criteria. It cost real money to develop. Competitors who don’t have it are at a measurable disadvantage. It satisfies every traditional element of trade-secret law: economic value, secrecy, reasonable measures.

I have built such packages. I know how much skilled work goes into them. I do not dismiss the labor or the value. The dominant view is right that prompts can hold trade-secret status, that the work is real, and that protecting that work is sensible.

The dominant view is wrong about how much of that protection survives the moment the prompt actually does its job.

Because the moment the prompt is loaded into an agent that a user can interact with — even an internal user, even behind your firewall, even through three layers of access control — the prompt becomes extractable. Prompt injection attacks, model extraction attacks, and the simple expedient of asking the model “what are your instructions?” in increasingly creative ways have been demonstrated to work against virtually every commercial LLM. Some of the most expensive prompts in the world — the system prompts that turn raw foundation models into branded assistants at major tech companies — have ended up on Twitter within days of those products launching, every single time. That isn’t a security failure on the part of any individual company. It’s a structural property of the technology. Prompts are not artifacts that hold their secrecy under interrogation. They are exhibits in a public record that gets written every time someone uses your product.

This is the hinge the steelman swings on. Trade-secret protection is conditional on secrecy, and secrecy is structurally impossible for prompts that are actually deployed into queryable systems. The prompts that hold trade-secret status are the ones nobody is using. The prompts that do useful work are the ones that have already leaked, or that will, on a clock you cannot influence.

So the deepest version of the argument is: yes, prompts can be trade secrets, but only the ones with no production deployment. Which is to say: the protection only attaches to the prompts that aren’t producing value. That is a strange thing to call a moat.

Where the protection actually lives

If the legal protection model doesn’t work — and it doesn’t — what does?

The answer, the same one I gave for data in the first essay in this series, is that protection lives in architecture and contract, not in IP doctrine. There is a stack of six layers people typically conflate, and the top three are theater while the bottom three are real. The whole budget of most “prompt protection” programs sits in the top three. Most of the actual protection these programs are trying to achieve lives in the bottom three, almost completely unaddressed.

Layer one is copyright on prompts. The Copyright Office disqualified this in January 2025. There is no protection here. If your strategy depends on this layer, your strategy ended fifteen months ago and nobody told you.

Layer two is patents on prompt techniques. Technically possible. Practically: it discloses your method to the world during the eighteen-month patent grant cycle, and infringement of a prompt patent is essentially undetectable because you cannot inspect a competitor’s system prompt. By the time you have a granted patent, the model generation that made the technique valuable has been replaced. The cost-to-value ratio is upside-down. A small number of organizations are doing this anyway, mostly for portfolio reasons and not because they intend to enforce.

Layer three is “confidential” labels, employee NDAs, and access-controlled prompt repositories. These are necessary. They are the reasonable measures that establish trade-secret status under the Defend Trade Secrets Act. They are insufficient. They protect the prompt in the file. They do nothing about the prompt in the deployed agent. That is the entire problem.

Now drop below the line. This is where the real protection has been hiding the whole time.

Layer four is the no-training-on-our-data clause in your AI vendor contract. This single contractual provision — that your prompts, customer inputs, completions, and embeddings will not be used to train the vendor’s models, including derivative or fine-tuned models — is doing the actual protective work that most enterprises imagine their NDAs are doing. It is the difference between your competitive intelligence becoming training signal for your competitors’ future tools versus staying a private asset of your business. Every enterprise AI vendor I work with in 2026 has some version of this clause, but the language varies enormously, and the variation is where the whole game is. Read it carefully. Negotiate it. It is doing more for you than every NDA in your prompt repository combined.

Layer five is gateway-level PII tokenization. This is architectural rather than legal. Before any prompt or input crosses your perimeter to a model provider, sensitive data — names, identifiers, financial information, medical details — is replaced with reversible tokens. The provider receives a request with placeholders where the secrets used to be. The provider’s response comes back with placeholders, which are replaced with the original values inside your perimeter before the user ever sees them. The provider’s logs, the provider’s training pipeline, the provider’s potential breach exposure — none of them ever contains your raw secrets. This is not the same as “PII detection.” Detection flags a problem. Tokenization eliminates it. The architectural distinction is the difference between hoping a vendor doesn’t misuse your data and making it impossible for them to misuse data they never received.

Layer six is workflow integration and switching costs. This is the moat. Your prompts matter because they sit inside a workflow that produces feedback signal, integrates with systems of record, and has trained human muscle memory across hundreds or thousands of users. That position is not protected by any document any lawyer ever wrote. It is protected by the integration depth, the switching costs, and the time-bound human habits that make ripping it out a quarter-long project rather than an afternoon’s work. None of that is “IP” in the traditional sense. All of it is what’s actually keeping your competitor from eating your lunch.

The pattern should look familiar by now. The protection moves from the abstract and legal at the top toward the concrete and architectural at the bottom. The legal layer protects nothing in practice. The contract layer protects something specific. The architecture layer protects more than the contract because it makes the bad outcome physically impossible. The workflow layer protects the most because it doesn’t protect anything — it makes the question of protection beside the point.

What the Anthropic story showed about prompts specifically

I keep returning to the Anthropic-Pentagon crisis of February 2026 because it is the cleanest natural experiment we have on what actually survives an adverse event in the AI stack, and the prompt question is no exception.

When agencies and contractors lost access to Claude, what they lost was, in significant part, a body of carefully refined prompts. Engineers had spent months tuning system prompts that knew their domain, their terminology, their compliance constraints. Some of those prompts were treated as protected IP inside their respective programs — version-controlled, access-restricted, NDA-covered. The whole apparatus.

None of that protection mattered when the provider went away. The prompts were still there. The NDAs were still in force. The repositories were still locked. But the agents those prompts had been animating were gone, and the prompts were now expensively engineered instructions to a model nobody could call. The IP framing didn’t fail; it produced exactly the protection it was designed to produce. The framing simply protected the wrong thing.

What about organizations that had deployed prompts through a gateway architecture — where tokenization happened at the perimeter, where the no-train clause meant the prompts had not been ingested into the provider’s training pipeline anyway, where the workflow continued because the underlying provider was a substitutable component? I have to be honest about the evidence here too. No publicly named organization has come forward to describe its prompt deployment surviving the February crisis intact. The kinds of organizations most likely to have built this architecture — defense contractors, regulated enterprises, intelligence-adjacent SaaS — are also the kinds of organizations that do not publicly describe how their architecture handled a procurement crisis. The silence is consistent with the story being true and intentionally unpublished. But silence is not evidence, and I will not assert what I cannot back.

The structural point still holds. An architecture in which prompts are bound to the customer’s own gateway rather than to any single provider’s API, in which the prompt is a versioned organizational asset rather than a vendor-coupled artifact, in which tokenization happens at the perimeter so the underlying provider never received the raw secrets in the first place — that architecture would, mechanically, have made the prompt question a non-event when the provider went away. The protection model that would have worked in February is the same protection model that will work for the next adverse event, whatever shape it takes. The lesson is forward-looking. It does not depend on the existence of a documented survivor, only on the fact that the architecture is buildable today.

This is the architectural posture I designed into AOSentry, the AI gateway product I founded AOCyber to build, for exactly this reason. The two years I spent exploring gateway architectures before starting on AOSentry were dominated by exactly this question — what protection actually survives a deployed agent, and what protection only survives a prompt sitting in a repository. The product is the answer I arrived at. The point is not that AOSentry is the only way to do this; you can build a gateway in-house, you can adopt one of several other gateway products, you can decide that for your specific use case the trade-offs land elsewhere. The point is that some form of architectural decoupling between your prompts and any single AI provider is the only protection that survives the kind of adverse event that has now happened, in public, in production, against thousands of organizations. Every other form of “prompt protection” — the legal layer, the access controls, the NDAs, the repository labels — kept performing its job perfectly while the actual asset evaporated.

What to do instead

The practical implications of this fall out cleanly once you stop treating the legal layer as the primary protection.

Stop investing in the top three layers as though they are doing what you imagine they are doing. Keep them — the reasonable-measures requirement of trade-secret law makes them necessary and the cost is low — but stop staffing them up, stop hiring outside counsel to review them, stop putting “prompt IP” as a line item in your defensibility deck. They are the legal hygiene equivalent of locking your front door. Necessary. Not sufficient. Not where the burglary actually happens.

Move the budget to the bottom three. Specifically: read your AI vendor contracts and negotiate the no-train clause hard. Adopt or build a gateway architecture that puts tokenization at the perimeter. Spend on workflow integration depth instead of legal posture. The relative cost of these moves, compared to a robust prompt-protection-as-IP program, is favorable in every direction at once. They cost less. They protect more. They protect the things that actually matter — the data signal flowing through your prompts, the architectural coupling that determines whether you survive a provider event, the workflow position that makes prompts valuable in the first place.

Stop talking to lawyers about prompts. Start talking to architects.

Stop labeling prompt files CONFIDENTIAL and start labeling provider integrations substitutable.

Stop treating prompt engineering as an IP discipline and start treating it as a workflow discipline. The output of a good prompt-engineering program in 2026 is not a body of trade-secret-protected prose. It is a measurable improvement in how a workflow performs over time, with the prompt as a tunable parameter inside a larger system that includes data, evaluations, integrations, and human feedback. Treating that system as the asset, and the prompt as a configurable component within it, is the move that separates the organizations that will still be doing useful AI work in five years from the ones whose prompt repositories will be expensive monuments to a category error.

The line

The thesis of this whole series is the same line, and I keep getting opportunities to say it from different angles.

Stop protecting. Start owning the loop.

For prompts, the version is sharper. Stop treating prompts as artifacts that can be protected through legal posture. Start treating them as parameters in a workflow whose value comes from architecture, contract, and position. The legal posture doesn’t survive contact with a deployed agent. The architecture, contract, and position survive contact with everything — including the kind of adverse events that have now happened in public, against organizations who thought they were defended.

If you run the protection-stack diagnostic on your own organization right now, you will likely find that you have spent a lot of money in the top three layers and almost nothing in the bottom three. That is the situation most enterprises are in. The fix is not subtle. Move the spending. Move the attention. Move the talent.

In the next post in this series, I’ll do the same thing for agentic AI that this post did for prompts and the previous post did for data. The story is structurally identical: the industry has been protecting the wrong thing, the right thing is workflow position, and the gap between the two is where the next generation of AI businesses will either be built or eaten.

Justin Donnaruma is the founder and CEO of AOCyber. He built AOSentry from scratch after two years exploring gateway architectures and AI tooling. AOSentry is an AI security gateway and governance platform that gives organizations one API across every major AI provider, with PII tokenization, immutable audit logs, and post-quantum cryptography from Day 1. If your prompt-protection program is heavy at the top of the stack and light at the bottom, start a conversation.