Keep Tirith local.Run in platform mode when governing IaC at scale.
The CLI answers one question, once: is this change allowed? At fifty repositories the questions that matter cannot be answered from inside a single run. StackGuardian evaluates policy continuously, ranks what is genuinely exposed rather than what merely failed, and stages each fix as a reviewable pull request with its evidence attached.
- Cloud scan writes the policy
- One policy set, every repo
- Ranked by real exposure
- Fixes arrive as pull requests
Which one is your problem?
Most teams should stay local. This page is only worth reading if the second row describes you.
- Keep Tirith local
- One or a few repositories; policies owned by the repository; your existing CI and review process are enough; no central history needed.
- Connect StackGuardian
- Many repositories; policy drifting apart between them; installing the same gate by hand over and over; central approvals and evidence; credential and runtime controls; remediation across teams.
What each one costs
- Tirith OSS£0 · Apache-2.0A developer or team governing repositories independentlyLocal plan evaluation, policies in your repository, actionable verdicts, a CI gate and community support
- StackGuardianCustomPlatform organisations coordinating many IaC projectsDiscovery and rollout, central policies, plan visibility, approvals, audit, remediation and governed execution
Both routes are demonstrated end to end in the public demo repositories — on GitHub, GitLab and Bitbucket. Each starts with policies committed to the repository and then switches to the organization's, with nothing else in the pipeline changing.
What connecting adds
- DiscoverFind Terraform and OpenTofu repositories and pipelines with read access; show coverage confidence and gaps.
- DetectScan connected cloud accounts on a schedule against CIS, PCI DSS, NIST and HIPAA, and turn each finding into a Tirith policy the pipeline then enforces.
- PrioritiseRank which repositories need governance first by verified severity and exposure signals.
- InstallOpen minimal Tirith pull requests for repository owners to review, and it does not write directly to protected branches.
- StandardiseManage central policy and evaluate it continuously across GitHub Actions, GitLab CI and other pipelines.
- ApproveAdd policy-aware approvals, credential brokering and private user-owned runners without rewriting the developer workflow.
- RemediateStage an explainable code change for human approval, with file and line evidence and an audit trail.
- ExecuteKeep your current apply jobs, or move execution into StackGuardian for revisions, snapshots, recovery and notifications.
- Execute from TirithplannedTirith calling the StackGuardian workflow API directly to move from policy decision into controlled execution.
One boundary stated plainly: moving execution into existing StackGuardian workflows is available today. Tirith itself calling the workflow API to initiate execution is planned and not shipped, so do not build a rollout plan around it yet.
Find it once, then stop it recurring
The strongest reason to connect anything. What is already misconfigured in your cloud is the specification for the rule that keeps it from being rebuilt, and the two halves stay where they belong: the platform finds it, the open-source gate prevents it.
- 1It scans what you already runConnected cloud accounts are checked on a schedule against CIS, PCI DSS, NIST 800-53 and HIPAA. The result is a count of real resources failing real controls, not a list of things that might one day be wrong.
- 2Each finding becomes a policyA misconfiguration you already have is the best possible specification for a rule: somebody built it that way once, so somebody will build it that way again. The platform writes it as an ordinary Tirith policy.
- 3The gate stops it coming backThat policy runs in your pipeline, on your runner, through the same open-source CLI as everything else on this site. The next plan that would reintroduce the misconfiguration does not reach apply.
- Masked before it leavesValues Terraform marked sensitive are replaced on your runner, not on arrival. Once bytes reach a server the exposure has already happened, so masking there would be theatre.
- The mirror is dropped, not maskedA plan repeats every value in
planned_values, which carries no sensitivity markers of its own. It is removed entirely rather than scrubbed, because a real plan leaked a file body through exactly that path. - Provider blocks are scrubbedProvider configuration can hold hardcoded credentials, so everything except the handful of fields a policy can read is stripped.
- And the limit, statedTerraform’s markers are not exhaustive. A value that flows through a local, or comes from a provider that did not mark its schema, arrives unmarked and marker-driven masking will not catch it. Sending less is the only defence against that, which is why the two rules above exist.
A catalogue cannot know your estate
A scanner catalogue is built for the mistakes everyone makes, and it is good at them. At fifty repositories the rules that actually stop your incidents are the ones only you can state: which module sources are allowed, which accounts a pipeline may touch, the tag your finance team reconciles against. No catalogue ships those, because no catalogue has read your estate. Two things you already have can write them between them.
- 1The MCP server reads what you actually runRead access across workflows, stacks, templates, connectors and policies, and the cloud posture beside it: which resources are managed, which have drifted, and which are failing which control. Your agent asks in plain language and gets your estate back, not a generic example of one.
- 2The skill pack turns that into rulesWith the Tirith skills loaded, what it read becomes policy JSON against the real condition list and the argument key each provider actually reads. A misconfiguration you already carry is the best specification a rule can have: somebody built it that way once, so somebody will build it that way again.
- 3The gate enforces them, deterministicallyThe resulting policy set runs in your pipeline, on your runner, through the same open-source CLI as everything else on this site, and returns the same exit code every time for the same plan. Nothing about enforcement is agentic: the agent drafts the rule, the engine rules on the change.
Every generated policy is a draft until it has refused something. tirith lint checks the shape against the engine's own registries without needing a plan, and the skill's one standing instruction is never to hand back a policy it has not run against a document that should fail it. Packaging a set to run in one invocation is on the roadmap and has not shipped.
What you already have, and what you would gain
| Capability | Tirith OSS | With StackGuardian |
|---|---|---|
| Evaluate a Terraform or OpenTofu plan | Included | Included |
| Runs entirely on your own machine | Included | Not applicable; connection is explicit |
| Policies and results in each repository | Included | Included |
| Discover IaC repositories and open rollout PRs | Manual | Included |
| Central policy, history and plan visualisation | None | Included |
| Approvals, credential brokering and audit | Use your existing CI tools | Included |
| Assisted prioritisation and remediation | None | Included; verify entitlement |
| Author policies with a coding agent | Included; skill pack | Included |
| Read the estate from that agent: workflows, templates, cloud posture | None | Included; MCP server |
| Drift, snapshots, recovery and notifications | None | Where execution or state is connected |
| Private user-owned runtime | Your own CI runner | Included |
Five questions worth asking first
Do I need StackGuardian to use Tirith?
No. Local evaluation is Apache-2.0 and runs wherever your pipeline runs. The commitment that it stays that way is in GOVERNANCE.md.
What changes when I connect?
You explicitly supply a StackGuardian organisation and token; there is no other switch. Tirith masks values marked sensitive in the plan locally, then can send the masked plan, results, metadata and, unless you disable it with --no-source, the related source.
Can StackGuardian replace or control my repositories?
Installation and remediation arrive as pull requests for repository owners to approve. It does not write directly to protected branches, and your existing CI and apply jobs can stay exactly as they are.
Can the runtime remain ours?
Yes. A private runtime fully owned and operated by you is supported; its network and control-plane requirements are covered in the technical follow-up.
What stays open source?
The policy schema, the providers, the CLI and local action contract, and the example policy library are all usable without any commercial relationship, subject to the published governance commitments.
The complete masking behaviour, including what it does not catch, is in the platform-check documentation. The commitments are in GOVERNANCE.md.
Tell us how your IaC reaches production today
Whatever it looks like now, we will map the shortest route from the pipelines you already run to consistent governance across all of them, with no execution migration, and your apply jobs stay where they are.
Would rather keep it public? Open an issue instead. For anything that is not commercially sensitive, that gets you the maintainers rather than a sales process.