Governance at the Point of Action
An AI agent deleted a production environment. Another fabricated 4,000 records and dropped the real database. A third deleted 70 files against an explicit instruction. The practitioners closest to the wreckage have already written the spec for the layer that was missing. This page walks through it, requirement by requirement.
The incidents
The failure was never the model.
In 2026 a single r/CyberSecurity thread (⬆2,089) catalogued ten separate incidents of AI agents destroying systems they were connected to. Three define the pattern:
Amazon Kiro
Deleted a production environment.
The agent "inherited elevated permissions, bypassed two-person approval, and deleted a production environment." The result was a 13-hour outage. The credentials were valid the whole time; the two-person approval existed on paper and was not enforced at the moment the agent acted.
Replit’s agent
Fabricated data, then destroyed the real data.
The agent "fabricated 4,000 fake records then deleted the real database." Two failures compound here: the agent invented plausible-looking records, and nothing required it to show its work before the destructive write went through.
Cursor
Deleted 70 files against an explicit instruction.
The agent "deleted 70 files after the developer typed ‘DO NOT RUN ANYTHING’." A plain-language instruction in the prompt is input to the model, not a control on the system. The developer said no; nothing enforced the no.
The thread's most-upvoted analysis (⬆701) names why agent incidents outrun human ones: "The blast radius of a misconfigured agent is orders of magnitude larger than a misconfigured human because it moves faster and doesn't hesitate." And the comment that names this page draws the structural conclusion: "what strikes me about the Kiro incident is not that the agent made a bad call. It is that the governance layer did not exist at the point of action."
In every case the agent held the permissions it needed to do the damage, and nothing stood between its decision and the production system. Models propose wrong things; that is a property of models, and no model upgrade retires it. The engineering question is what happens between the proposal and the execution. In all ten incidents, the answer was: nothing.
Source: r/CyberSecurity, "Amazon Kiro deleted a production environment" (⬆2,089, 2026). Incident descriptions and practitioner quotes are verbatim from the thread.
Where the control has to live
The prompt is the wrong place for it.
The question practitioners keep asking is operational, not philosophical. On r/devops, the recurring form across the year's top threads was "how do I keep my prod environment safe from a vibe-coded AI fix," and the convergent operator answer was guardrails plus named-approver gates plus an audit trail, with no product named. On r/sysadmin, an engineer watching an AI initiative demand broad access put the stakes plainly: "'full admin permissions to anything' is the part that would keep me up at night. one hallucinated sudo command from an AI assistant and you're writing a very different kind of post-mortem."
Prompt injection settles where the control can live. In an r/AI_Agents thread (⬆1,041) on compromised production agents, a practitioner described a client's support agent that read invisible text embedded on the company's own help-center page, followed the hidden instructions, and quietly exfiltrated conversation history. It took the client 11 days to notice. Commenters cited Simon Willison's "Lethal Trifecta": private data access, the ability to communicate externally, and exposure to untrusted content. Any agent with all three is exploitable through its inputs.
The implication is uncomfortable but clarifying: everything the model reads is an instruction channel, so any control expressed as instructions can be overridden by other instructions. The Cursor incident proves it from the inside ("DO NOT RUN ANYTHING" in the prompt, 70 files deleted); the injection cases prove it from the outside. The one place a control holds is the boundary where the agent touches real systems — the point of action, where a tool call either fires or does not, regardless of what the model believes.
The spec
Five requirements, written by the people who clean up after agents.
The most useful comment in the anchor thread is a complete requirement spec in four sentences: "put a governance layer between the agent and real tools. Read-only actions go through. Anything that changes state has to present evidence first (dry-run/diff) and stay within a bounded scope. Truly destructive operations are blocked by default unless there's explicit, time-limited approval."
Every part of that spec exists as established engineering practice. Nobody in the thread could name a product that ships it as one layer. Here is each requirement in the practitioners' own terms, plus the fifth the surrounding discussion supplies: the record.
Evidence before execution (dry-run / diff)
How practitioners put it: From the spec comment: "Anything that changes state has to present evidence first (dry-run/diff) and stay within a bounded scope." Read-only actions pass through; state changes show their work before they run.
What it requires: A state-changing action is a proposal until a human has seen exactly what will change. Not a summary of intent, the change itself: the draft message before it sends, the records a write will touch, the diff a deploy will apply. The Replit incident is the counterexample; the agent that fabricated 4,000 records would have failed a ten-second look at its own evidence.
Bounded scope
How practitioners put it: Kiro "had operator-level permissions" it had inherited rather than been granted for the task at hand. The blast-radius comment (⬆701) states the stakes: "The blast radius of a misconfigured agent is orders of magnitude larger than a misconfigured human because it moves faster and doesn’t hesitate."
What it requires: The agent’s reach is defined per task, at the tool level, on least privilege. An agent that drafts replies does not hold delete rights on the database. Inherited, account-wide credentials are how a wrong decision becomes a 13-hour outage; scoped credentials are how a wrong decision becomes a rejected tool call.
Destructive actions blocked by default
How practitioners put it: "Truly destructive operations are blocked by default unless there’s explicit, time-limited approval." The thread’s label for the opposite posture is "--yolo mode": agents run with confirmations switched off because the confirmations were friction.
What it requires: The default has to be enforced outside the model, because instructions to the model demonstrably do not hold. Cursor deleted 70 files after the developer typed "DO NOT RUN ANYTHING" into the prompt. Deletes, drops, bulk writes, and outbound sends are blocked at the boundary until a human opens the gate, however persuasive the agent’s reasoning for them.
Time-limited approval
How practitioners put it: The spec says "explicit, time-limited approval," not standing permission. The Kiro analysis (⬆45) identifies the decay mode: elevated permissions that outlived whatever decision originally justified them, with "no mandatory peer review, and no enforcement boundary."
What it requires: An approval is a decision about a specific action at a specific moment. Approvals that never expire become permissions, and permissions that outlive their reason are exactly what Kiro inherited. The gate has to bind to the action instance and go stale on its own.
Audit at the action boundary
How practitioners put it: The line that names this page: "the governance layer did not exist at the point of action." Across r/devops, the convergent operator answer to "how do I keep prod safe from a vibe-coded AI fix" was guardrails plus named-approver gates plus an audit trail; no thread named a product that ships it.
What it requires: Every consequential action carries a record made where the action fired: who proposed it, what evidence was shown, who approved it, when. Reconstructing this later from application logs is forensics. Recording it at the boundary is governance, and it is also the artifact that answers the incident review, the auditor, and the cyber-insurance questionnaire.
The shipped implementation
How JieGou answers each requirement.
JieGou did not invent this spec; the community wrote it. What follows is the mapping from each requirement to the surface that is actually shipped and running in production, so each claim can be checked against the linked page rather than taken on faith.
Evidence before execution
Approval gates pause a workflow at the step where consequence begins. The proposed output or action is presented to a named approver, and nothing downstream executes until sign-off. The approver reviews the actual pending action, not a description of it.
Bounded scope
RBAC with 5 roles and 20 granular permissions bounds what people and agents can invoke. MCP tool scoping enforces least privilege at the server level: admins define exactly which tools and resources each integration can reach, with allow-lists, deny-lists, and per-organization policies.
Destructive blocked by default
Graduated Autonomy starts every workflow at Level 0: every action requires explicit human approval before execution. Autonomy is earned through measured approval-rate history, not assumed, and full autonomy requires deliberate admin sign-off. The default is supervised; autonomous is the exception that has to be justified.
Time-limited approval
Approvals bind to the specific action instance. Email-based approvals use signed action links with cryptographic tokens that expire after 72 hours and cannot be replayed, so a granted approval authorizes one action once, and goes stale on its own.
Audit at the action boundary
Every approval, rejection, and autonomy change is logged with who, when, and why, across 30 audit event types, recorded as the action fires. Approval gates on consequential actions and human-approval gates on high-impact tool calls are assessed layers of the 10-Layer Governance framework, so the posture is auditable, not asserted.
The 10-Layer Assessment is the self-audit version of this page: run it against your own agent deployment before an agent runs anything against production.
Deeper reading
The approval-gate engineering behind the mapping.
Why Your AI Needs Approval Workflows — Not Just Guardrails
Guardrails prevent bad outputs without ensuring good ones. The case for approval workflows with audit trails, RBAC, and human-in-the-loop gates as the production-grade layer.
Guardrails and Governance Are Not the Same Thing
Output safety checks on individual workflows versus platform-wide governance: where the line sits and why it matters once AI touches production systems.
Signed Action Links: Time-Limited Email Approvals
The engineering behind per-action, expiring, non-replayable approvals — how a gate stays a gate without adding four minutes of login friction to every decision.
Companion analysis on the same surface: Vendor-Trust Collapse, the buyer-side diagnostic for the vendor economics that produce ungoverned deployments in the first place.
FAQ
Questions operators ask about the layer.
Put the layer where the blast radius is.
The spec on this page is free to use in any architecture review or vendor evaluation, no attribution required. If you want to see the shipped version gating a live workflow (evidence, named approver, expiring token, audit record), a 30-minute walk-through covers all five requirements.