How We Protect IP When Deploying AI Software on Customer Infrastructure

How We Protect IP When Deploying AI Software on Customer Infrastructure
How We Protect IP When Deploying AI Software on Customer Infrastructure

Shipping AI software directly onto a customer's servers — instead of hosting it yourself — solves real problems: data never leaves their network, latency drops, and procurement teams stop worrying about a third party touching regulated data. But it introduces a problem vendors don't face with SaaS: the code, weights, and prompts that make your product valuable are now sitting on a machine you don't control.

Here's how we think about protecting that IP without making the deployment miserable for the customer.

Start by deciding what actually needs protecting

Not every asset is equally sensitive. Before reaching for encryption or obfuscation, it's worth separating:

  • Model weights — usually the most expensive thing to reproduce, and the easiest to just copy off disk.
  • Prompts and orchestration logic — often the actual "secret sauce" of an AI product, more than the model itself.
  • Business logic — pricing rules, workflow definitions, integration code.
  • Training or fine-tuning data — sometimes more sensitive than the model, especially if it contains customer or licensed data.

Treating all four the same way usually means over-engineering protection for low-value assets and under-protecting the ones that matter.

Ship compiled artifacts, not source

For anything beyond trivial scripts, we compile or bundle before it ever reaches customer infrastructure. Interpreted languages make this harder — a Python codebase dropped on disk is trivially readable — so orchestration and business logic layers get compiled (Go, Rust, or bytecode-compiled Python) or packaged behind a binary entry point.

It's not bulletproof; a determined engineer can decompile a binary. But it moves the cost of extraction from "open a text editor" to "reverse engineer a binary," which is enough to stop casual copying and IP leakage through support tickets or contractor access.

Keep weights encrypted at rest, decrypt only in memory

Model weights get encrypted on disk and decrypted only into memory at load time, using a key that's fetched from a license server rather than baked into the deployment package. This means:

  • A copied model directory is useless without a valid, active license.
  • We can revoke access without touching the customer's infrastructure again.
  • Weight files can't be lifted by someone with filesystem access but no runtime credentials.

For customers in fully air-gapped environments, we issue time-boxed offline licenses instead, so protection doesn't collapse the moment there's no network path back to us.

License enforcement that fails safe, not silent

A license check that just crashes the app on failure creates support nightmares and tempts customers to patch it out. Ours degrades gracefully — read-only mode, watermarked outputs, or a clear in-product notice — while logging the failure for us to follow up on. The goal is to make circumvention pointless rather than to make failure painful.

Watermark and fingerprint outputs

For generative outputs in particular, we embed invisible, deployment-specific fingerprints. If model outputs turn up somewhere they shouldn't — a competitor's product, a public dataset, a leaked demo — we can trace which deployment they came from. This matters less for stopping theft in the moment and more for making misuse traceable after the fact, which changes the incentive calculus for anyone considering it.

Contracts still do most of the work

Technical controls raise the cost of misuse; they rarely make it impossible. The contract — usage restrictions, audit rights, IP assignment clauses, penalties for reverse engineering — is what actually gives you recourse when something goes wrong. We treat technical protection as a way to catch honest mistakes and deter casual misuse, not as a substitute for a properly negotiated agreement.

The trade-off we accept

Every layer above adds friction: license servers to maintain, encryption to manage, binaries that are harder to debug in the field. We've found the right amount of protection is the amount that survives a reasonably competent, moderately motivated actor — not a nation-state. Chasing perfect protection against a sophisticated adversary usually costs more in engineering time and customer trust than the IP it's protecting is worth. Match the protection to the threat model, not to the worst case you can imagine.

Learn more at