Skip to main content
TruStacks

Product · Policy

Tribal knowledge that survives the engineer who wrote it.

Three layers of signed Rego. Each layer can only ratchet stricter than the one above it, provable at compile time. The customer is a policy author at the deepest layer. Policy becomes the right unit of trust: durable, signed, version-controlled, queryable.

Customer overlay

Your architects, SREs, compliance officers

Deepest · most authoritative

Your domain rules. Authoring at the Team tier and above. Can ratchet stricter than the layers below. Never looser.

Packs

Regulatory · Industry · Framework · CI runtime

Regulatory packs (SOC2 / HIPAA / PCI / FedRAMP / ITIL) are TruStacks-curated, paid, and signed for auditor defensibility. Industry / framework / CI runtime packs are open-source community-contributable and free at all tiers.

Constitution

TruStacks-authored, signed, immutable, free at all tiers

Foundation

The universal rules every proposal must respect. Constitution rules are non-waivable; the layers above can only add to them or tighten them.

The agent crew reads all three layers and proposes pull requests. Each layer can only ratchet stricter than the one above.

The flow

How a rule becomes a merge block.

Three layers of signed Rego is the shape. This is the sequence — what actually happens between an agent deciding to write something and a person deciding to merge it.

How a proposed change is evaluated. Steps one to four happen before any human is involved: the signed policy bundle is verified, the agent crew reads the rules in force, an agent emits an artifact, and the policy gate evaluates it. A denial returns the change to the agent with the identifier of the rule that objected. Only a change that passes becomes a pull request, which a named human then merges.

Before a human is involved

  1. Verify the bundle

    An init container pulls the policy bundle as a signed OCI artifact and checks its signature. If verification fails, the runtime never starts.

    cosign verify

  2. Read the rules

    The crew reads your repository, your environment profile, and the index of every rule currently in force — before writing anything.

    rule_index

  3. Emit an artifact

    The DevOps Engineer produces the workflow, chart, and Application your stack needs. At this point it is a candidate, proposed to nobody.

    ci.yaml · Chart.yaml

The policy gate

opa eval data.proposal.deny

Three layers are evaluated together. Each may only tighten the one above it.

  • Constitution

    ours, non-waivable

  • Specialist packs

    SOC 2 today

  • Your overlay

    yours, tightens only

Denied

Returns an object carrying the rule_id that objected — so the agent knows exactly what to fix.

Back to step 3. No pull request is created.

Passes

Every rule in force was satisfied, and the change carries the list of which ones.

Crosses the line below.

Nothing crosses this line unevaluated

What a human sees

  1. The pull request opens

    The body cites the rules the change satisfies, so a reviewer starts from what was already checked rather than from scratch.

  2. A named human merges

    The mechanical questions are answered, so their attention goes to judgement. No configuration flag skips this step.

The argument is the position of step 4, and the arrow that goes backwards. A change that violates policy never becomes a pull request someone has to argue about — it goes back to the agent with the reason attached. By the time a person is involved, the only questions left are the ones a person is actually better at.

Why Rego and not a prompt

Prompts are not policy.

The usual way to control an AI agent is to ask it nicely in an AGENTS.md or a system preamble. That is a request, evaluated probabilistically, and it is different for every model version. Here is the same requirement expressed both ways.

A request

Please make sure production deploys
go through an approval gate before
we push an image.

Followed most of the time. You cannot test it, cannot prove it got stricter last quarter, and cannot show it to an auditor.

A decision

deny contains msg if {
  some cluster in input.proposal.target_clusters
  cluster.tier == "prod"

  some f in input.proposal.files
  startswith(f.path, ".github/workflows/")
  _has_image_push(f.content)
  not _has_prod_environment(f.content)

  msg := {
    "rule_id": "acme.requires_prod_approval_gate",
    "message": sprintf("%s pushes images for a
      prod deploy with no environment gate", [f.path]),
  }
}

Evaluated deterministically. Ships with its own test file. Is versioned and signed. Fails the build when violated.

Both express the same intent. Only one of them is an object you can reason about.

That rule is not hypothetical — it is acme.requires_prod_approval_gate, a worked example that ships in the sample overlay — abridged here only by leaving out its two helper functions. Note what the rule returns: not a string, but an object carrying a rule_id. That is what puts a citation on the pull request, so a reviewer reads which rule objected rather than a bare complaint. It ships beside a test file covering the tier scope, four ways of detecting an image push, the environment gate, and the multi-file case. The longer version of this argument is in Prompts are not policy.

Three voices contribute to the rules.

Most policy products give you one voice and call it “flexible.” We give you three, and we make the boundaries between them load-bearing.

  1. Voice 1

    TruStacks domain experts

    Author and maintain the constitution and the curated regulatory packs. Tightly controlled, signed by TruStacks, distributed as the canonical foundation. The constitution is free at every tier; regulatory packs are paid.

  2. Voice 2

    The open-source community

    Will contribute framework packs, CI runtime packs, and cross-organization industry overlays through the trustacks-policy repository — Apache 2.0, DCO sign-offs, free at all tiers. The repository is not open to the public yet, so this layer is a commitment rather than something you can go read today. We would rather say that than let you find out by clicking.

  3. Voice 3

    Your own domain experts

    Author rules that codify your organization's specific context, layered on top of the TruStacks foundation and signed with your own keys. Your overlay cannot weaken anything TruStacks ships. It can only add to it or tighten it, and the policy linter proves that at compile time.

The ratchet

We wrote rules our own agents can’t talk their way out of.

“Ratchet-only” is easy to claim and easy to quietly break under deadline pressure, so it is worth being concrete about what it means. Say the constitution requires that an image scanner be present. Your overlay has exactly two options.

Allowed — tightens

“An image scanner must be present, and it must be FIPS-validated.”

Your architects know something we don’t about your environment. The overlay is where that goes.

Rejected — loosens

“An image scanner must be present, except for internal services.”

An overlay cannot remove a category an upper layer required. This one does not ship — it fails to build.

The check is trustacks rule lint, and it runs before the bundle is signed. So the failure is a compile error with a name attached to the commit, not a policy discussion six months later when someone notices the rule stopped firing.

This is the property that makes the rest of it worth anything. A rule that can be quietly relaxed is a rule that will be, and the relaxation will not appear in anyone’s evidence binder.

What an auditor asks next

The constitution is non-waivable. Including by us.

No exception path at the top

Constitution rules carry no waiver mechanism. There is no support ticket that turns one off for your tenant, because the capability does not exist — not as a courtesy, as an absence.

Waivers exist, but they expire

Deeper layers do support waivers, because real organizations need them. They are time-bound, signed, carry a mandatory expiration, and are visible in the audit trail. A waiver you have to renew is a waiver someone notices.

You sign your own layer

TruStacks signs what TruStacks authors. Your overlay and your environment profile are signed with your keys, so an auditor can tell our claims from yours rather than taking one vendor’s word for both.

The constitution ships as a cosign-signed OCI artifact, and an init-container verifies that signature on cluster start before any workload extracts the bundle. You can run the same check yourself, against our public registry, without asking us for anything — the command is on the supply chain page.

Default experience: zero customer-authored rules required.

A new customer installs, accepts the constitution and a Specialist Pack, and gets value on day one. Customer authoring is an unlock for sophistication, not a prerequisite. Git Push. Go Home. applies even to a customer who never writes a single rule of their own.

Build vs buy

The substrate is open. The stack isn’t.

Open Policy Agent ships the engine. Rego ships the language. Neither ships the rest of the stack you’d need to deploy layered, signed, customer-extensible policy across an organization: an authoritative constitution to anchor your overlay against, a signing root your security team trusts, OCI-based bundle distribution with init-container verification, and a linter that proves your overlay only ratchets stricter than the constitution at compile time. TruStacks delivers all four turnkey, plus the agent crew that proposes work respecting them. You stay the policy author at the deepest layer; we handle the substrate.

Read the rules before you buy the product.

Bring us a rule your organization actually enforces — the one everybody knows and nobody wrote down — and we will show you what it looks like as signed Rego your agents cannot argue with.

Request a demoVerify the supply chain