Letting AI open the door, but never skip the lock
How StackGate turns plain-English infra requests into governed workflows: a deterministic risk and cost policy engine, an LLM that only proposes, and Terraform that references secrets instead of embedding them.
Infrastructure requests have a bad failure mode. They start in chat ("hey can I get a Postgres instance for the staging service?"), they get approved by whoever happens to see the message, and three months later nobody can say who provisioned what, at what cost, or why. StackGate exists to keep the convenience of "just ask for it in plain English" without losing the audit trail, the approval, or the cost ceiling. The design rule is simple: AI can open the door, but it can never skip the lock.
The LLM proposes; policy decides
It's tempting to let the model do everything: read the request, judge the risk, approve it, provision it. That's exactly the architecture I avoided. In StackGate the language model has one job, translating a plain-English request into a structured, validated spec (engine, size, environment, data sensitivity). It proposes. It never approves.
The approval decision belongs to a deterministic policy engine, not the model. That separation matters: an LLM's risk judgment isn't auditable or repeatable, and "the AI said it was fine" is not an answer you want to give a security review.
Risk and cost as explicit tiers
Every request is classified into one of three tiers, low, medium, and high, from concrete signals: estimated cost, environment, and data sensitivity. Low-risk requests (a small dev database, no sensitive data) auto-approve and move straight to provisioning. Everything above that routes to role-aware approval, and the highest tier requires a second stage of sign-off.
The point of fixed tiers is consistency. The same request gets the same decision every time, regardless of who submitted it or who is online. The policy is the source of truth, and it's reviewable as code rather than living in someone's head.
Generate Terraform that references secrets, never embeds them
The provisioning layer is adapter-based: a simulation path for safe demos and a guarded Azure path behind it, so the workflow is identical whether or not real infrastructure is being touched. What it generates is reviewable Terraform, and the detail that matters is what's not in that Terraform: no plaintext credentials.
Generated configs reference Key Vault secrets instead of embedding them. The artifact a human reviews is the same artifact that runs, and it never contains a secret you'd have to rotate because it leaked into a plan output or a git history.
Every event, on the record
Because the whole point is governance, every workflow event is captured, from submission, through classification, through each approval, to provisioning. A request isn't a chat message anymore; it's a ticket with a complete history. When someone asks "who approved this database and why was it allowed?", the answer is a record, not a recollection.
Why it matters
The generalizable pattern is the division of labor: let the LLM handle the fuzzy, human-friendly part (understanding intent and drafting a spec), and keep the consequential decisions, approval, cost ceilings, secret handling, in deterministic, auditable code. AI makes the system approachable. Policy makes it safe. You don't have to choose.