Platform-locked AI is a bet that you'll never switch vendors

Keep the policy outside the platform. If the rules governing your AI agents exist only as configuration inside a vendor's system, leaving means re-authoring and re-proving every control, so you never leave. Rules kept as files in your own repository, in an open language, run by an open engine, make the tool replaceable and keep the controls yours.

That is the whole argument. The rest of this post is about why it is a procurement question rather than a feature question, and how to check whether a vendor — including us — actually passes it.

A common design, stated fairly

A common way to build agentic software delivery is to put everything in one place. The agents run inside the vendor's platform. They act on the platform's own objects: its pipelines, its repositories, its deployment definitions. And the rules that govern them live there too, as platform configuration, edited through the platform's console and evaluated by the platform's engine.

This is a reasonable engineering choice, and we want to be clear about that before arguing with it. One system means one permissions model, one audit log, one vendor to call. The integration is genuinely tighter than anything a neutral tool can offer, and if you have standardized on one platform end to end, it is a coherent way to buy.

The cost is not in the engineering. It is in what happens to your controls the day you want to stop.

The switching cost is not where people look

When teams estimate the cost of leaving a delivery platform, they price the visible parts: migrating pipelines, re-pointing repositories, retraining people. Those are real and they are bounded.

The agents themselves are close to free to replace. That is the strange thing about this generation of tooling — the expensive-looking part is the most interchangeable one.

What is not interchangeable is the policy. The rules that say a production deploy needs an approval gate, that a cardholder-data service must pin its image digest, that the legacy service only deploys on Sunday nights. Each of those is a decision somebody in your organization made, usually after an incident or an audit finding, and each one is now referenced by the evidence you hand an auditor.

If those rules exist only as configuration inside a platform, leaving means two things. Re-authoring every one of them for whatever comes next. And then re-establishing — to the auditor, to your own security team — that the new rules say what the old ones said. The second part is the one that kills the project, because there is no diff between two vendors' configuration formats. There is only a person reading both and vouching.

Most teams look at that cost and renew. Nobody has to intend this for it to happen; it is simply what the architecture does over a multi-year contract. Every control you add makes the next renewal more certain.

Five questions to ask before you sign

You do not need to settle the architecture debate to protect yourself from it. You need to ask where the policy lives, and what it would take to keep it.

Policy as platform configuration

Policy as an artifact you hold

Where is the rule stored?

Platform configuration

As a record inside the vendor's system, edited through its console or API.

An artifact you hold

As a file in a git repository you control, changed through pull requests like any other code.

What evaluates it?

Platform configuration

The platform's own engine, running inside the platform.

An artifact you hold

Open Policy Agent — the same open-source binary you can download and run yourself.

How do you test it?

Platform configuration

However the platform exposes testing, if it does.

An artifact you hold

opa test, in your own CI, with or without the vendor.

Which rules were in force on the day of a given merge?

Platform configuration

Whatever the platform's history retains, for as long as you are a customer.

An artifact you hold

git log on the rule files. The answer outlives the contract.

What does leaving cost?

Platform configuration

Re-authoring every control for the next platform, then re-establishing to an auditor that the new rules say what the old ones did.

An artifact you hold

You keep the rules, their tests and their history. Running them on another engine means mapping the input they read — real work, but work on files you already hold.

The left column is a reasonable design. Keeping rules inside the platform buys tight integration and one permissions model. The cost only shows up in the last row, and usually only on the day you try to use it.

The question that matters most is the fourth. An auditor asking which rules were in force on the day a particular change merged is asking for history, and history kept inside a vendor's system lasts as long as the relationship does. History kept in git lasts as long as the repository.

Run this before you believe us

A post arguing that you should be able to check a vendor's policy without the vendor's help owes you a way to check ours. So here it is, with no account and no conversation with us required.

Our constitution — the baseline rules every proposal is checked against — is published as a standard OPA bundle on a public registry. Pull it, unpack it, and run its own test suite with an unmodified Open Policy Agent binary:

# List the published versions, then pull one
oras repo tags ghcr.io/trustacks/policy/constitution
oras pull ghcr.io/trustacks/policy/constitution:<version>

# The bundle is a dotfile tarball; unpack it
mkdir constitution && tar -xzf .policy-bundle.tar.gz -C constitution

# Stock OPA, no TruStacks software anywhere
opa test constitution/policy/ constitution/data.json

The bundle carries its own tests, and on the day this was written every one of them passed. To check that the bundle you pulled is the one we built, the cosign verify command is on our security page. The bundle is signed keyless against the identity of our release workflow, so there is no long-lived key of ours to trust — only that identity and an entry in Sigstore's public transparency log.

And to read the rules rather than run them, the source is in the public trustacks-policy repository, licensed Apache 2.0, alongside the framework packs and their tests.

Your own rules work the same way. The overlay your architects write lives as Rego files in a git repository you own, one directory per rule with a test beside it, and changes through pull requests like any other code. Our CLI's trustacks rule test command is a thin wrapper around opa test, which means the tests that guard your rules run in your CI whether or not we are still in the picture.

What portable does not mean

This is the part a post like this usually leaves out, and it is the part that makes the rest worth believing.

Our rules are written against our input. A TruStacks rule reads a proposal — input.proposal.files, input.proposal.target_clusters — because that is what the crew hands the engine. Rego is an open language and OPA is an open engine, but a rule is always written against something. If you moved your overlay to a different system, you would keep every rule, every test, and every line of history, and you would still have to map the new system's input onto the shape the rules expect. That is real work. It is also work on files you already hold, which is a different order of problem from rebuilding controls out of a console export.

The crew is not open. The agents — their prompts, their orchestration, the way the Coordinator decides which specialist a change needs — are our product, and we sell it. We are not arguing that everything should be open. We are arguing that the one part you should never have to rent is the definition of what is allowed into your production systems.

Portability is a property of the artifact, not a list of integrations. Today the crew works against GitHub repositories, writes CI as GitHub Actions workflows, and hands deployment to ArgoCD. If your delivery runs on something else, the crew does not write for it yet, and we would rather say so here than on a sales call. What does not depend on that list is the policy itself: a directory of Rego files and tests reads, runs and diffs the same way on any machine with OPA installed.

The question to ask every vendor

Strip away the feature comparisons and one question separates the two architectures cleanly:

If we cancel, what do we keep that still works?

For a platform where the controls are configuration, an honest answer is usually an export, and then a project. For a governance layer built around an artifact you hold, the answer should be: the rules, the tests, the history, and an engine you can download. Ask us. Then ask everyone else on your list the same thing, in the same words, and compare the answers.

TruStacks is AI delivery governance — the control layer between the agents that write your software and the systems that run it. We built it so that the layer could be replaced without the controls going with it.

Agents propose. Policy decides. Humans approve.

Every product claim in this post is on our facts page with the date it was last checked and how. The commands above were run against the public registry on the day this post was published. If one of them fails for you, tell us — a portability argument that does not survive a reader running the commands is not one we want to be making.