SoftwareapplygateTerraformcoding agentsguardrailsopen source
Applygate, a free open-source hook, stops coding agents from running Terraform destroy in production by unwrapping base64 and reading saved plans
Flurit's tool installs with Homebrew, starts in observe mode so it can't block anything on day one, and says outright that it is not a sandbox. The scorecard it publishes comes from its own test set.
Applygate’s README opens with the job it wants: “Stop coding agents from running terraform destroy in production.” The mechanism is a local hook. Before an agent runs a command, applygate checks it and answers allow, ask or block. The rules are fixed, and the README says so plainly: “Fixed rules decide, with no model involved by default.”
The obvious way to build this is a list of bad strings. The README says applygate isn’t that. A command hidden inside bash -c, or inside an eval, or behind a Makefile target, sails straight past a grep. So applygate reads commands the way the shell does. In the README’s words, it “follows cd, variables, bash -c, eval, sudo, xargs, Makefiles, scripts and base64 payloads to find what actually runs.” Then comes the line that stuck with me: “a destroy hidden in base64 is still a destroy.”
String matching also fails in the other direction. In its comparison, the README says a hand-written policy “also blocked harmless text like git commit -m "never run terraform destroy".” A guard that blocks your commit message about the guard is the kind of thing that gets uninstalled by Friday.
The second half is the saved plan. When an agent runs apply <planfile>, applygate “reads the plan and rates what it finds as critical or high.” The README lists what counts: “destroyed or replaced stateful resources, removed deletion protection, internet exposure,” among other findings. In a protected environment, critical findings block and high ones ask a person. A database replacement hiding in line 400 of a plan is the case where reading the file beats reading the command.
Environments are tiered: “protected” for production, “standard” or “disposable.” Anything applygate can’t place counts as protected. The config file can only add protection, and after every edit to .applygate.yaml, “a person runs applygate trust, so an agent cannot quietly relabel production.” The agent doesn’t get to vote on how dangerous its own environment is.
The numbers come with a warning label. On 17 dangerous Terraform scenarios, which the README calls “our own set, so a demonstration, not a measure of coverage,” the best existing open-source guard it tested (default config) caught 5 of 17, a hand-written Rego and regex policy caught 14 of 17, and applygate caught all 17 in its protected tier. Take that for what the README says it is: the authors grading themselves on their own exam.
It also isn’t a sandbox, and the README says that too: a determined agent with write credentials can still cause damage. It “catches mistakes and most injected instructions.” Install is brew install Flurit/tap/applygate, then applygate init from your infrastructure repository. The tool is maintained by Flurit, has a handful of GitHub stars, and its README marks only two agent hooks as “Tested live”; the others are previews that “have not been tested inside the agent.”
The safe rollout is built in. It starts in observe mode, where it logs what it would block and blocks nothing. Run it for a few days, then run applygate report, which “shows what it would have stopped.” Only then switch to mode: enforce.
The benchmark’s rival is the loose end. The README says 5 of 17 for “the best existing open-source guard tested” and never names it, so nobody can rerun the other column.