We let our agents file their own work. Then we made them ask permission.

The most-discussed AI-dev question of the last two weeks isn’t “can an agent write the code?” Everyone has conceded that it can. The question that’s actually keeping people up is sharper: where, exactly, does a human gate an autonomous agent — and is that gate enforcement, or just a polite suggestion?

A Show HN this month put the distinction perfectly: “A prompt is a probabilistic influence on model behavior. A rule is an enforcement mechanism.” And on June 26 someone asked HN how to wire up multi-agent orchestration for personal use , spelling out the exact shape of what they wanted: to “be a human in the loop of an otherwise fairly automated loop… different agents for different roles.” The demand is explicit. The market wants autonomy with a real human gate on it.

That’s the gate Forge just shipped. So here’s the honest write-up.

The new failure mode: agents that file their own work

Forge’s autonomous SDLC loop already does something that sounds reckless when you first hear it: as agents work, they’re allowed to discover and file their own follow-up tasks. A developer character notices the API change needs a frontend update; a QA character spots a missing smoke test. Instead of silently dropping that insight, the agent records it as a task.

Left unchecked, that’s a runaway: an agent that keeps generating work for itself, spawning workflow after workflow, all night, on confident momentum. That is the precise thing the governance conversation is afraid of — not malice, but an automated loop with no edge.

So we gave it an edge. A discovered task does not auto-spawn. When the loop’s task matcher decides a follow-up needs a workflow that doesn’t exist, it produces a resolution-plan entry — generate:<workflowId> — and then stops. That entry rides the same held-trigger Approve path as any other pending action: a human has to approve it before a single new agent run is created. Auto-spawn is deliberately withheld behind that gate (forge-conductor PR #58 , merged June 26). The agent can propose its own work. It cannot grant itself permission to do it.

Why a “clean” repo made this urgent

If you think a human approval gate on agent-initiated work is paranoid, read the BleepingComputer report from June 27 : a repository that looks completely clean to scanners, to reviewers, and to the AI agent itself can carry a payload that “remains invisible to security scanners, AI agents, and human reviewers.” The agent reads it, acts on it, and the malicious instruction executes — no human ever consciously approved the consequence.

That’s the whole argument for a gate condensed into one CVE-shaped story. When the input to an autonomous agent can be poisoned and the agent can’t tell, the only durable defense is to stop the agent from taking consequential, self-expanding action without a human deciding it should. A gate on “spawn new work” is exactly that chokepoint.

Three layers, because one gate is never enough

The Approve gate is the visible layer, but it only works because of what’s underneath it. Forge stacks the trust boundary in three:

1. The autonomy budget self-limits the loop. The Roadmap Driver doesn’t get to grind forever; when its budget is spent it escalate-pauses and waits for a human. The Approve gate is what a human uses to resolve that pause — the budget creates the stopping point, the gate is the human action at it.
2. Isolated stacks contain what does run. Every slice an agent builds is deployed, smoke-tested, and torn down in a hermetic isolated stack — a clone, never the live workspace. Even an agent that was tricked into running something runs it in a box that gets deleted.
3. Scoped secrets and a persisted trail keep it accountable. Secrets and egress are restricted per agent, runtime, workflow, and team, so a compromised step can’t reach for credentials it was never granted. And every turn now persists its real tool-call and tool-result blocks — so when you review what an agent did, you’re reading the actual record, not a summary you have to trust.

This is the difference the governance crowd keeps drawing between governance and observability : observability tells you what happened; governance decides what’s allowed to happen. Forge does both — but the Approve gate is squarely the governance half. The agent that proposes the work is never the actor that authorizes it.

The takeaway

The honest version of “autonomous agents” in 2026 isn’t an agent you turn loose. It’s an agent you turn loose inside a box with a door, and you hold the key to the door. Forge’s agents can scout, build, test, and even notice the next thing that needs doing and write it down. What they can’t do is decide, on their own confident momentum, to go spawn that next thing. That decision waits at a human Approve gate — and given that a clean-looking repo can now weaponize an agent’s own inputs, that gate isn’t paranoia. It’s the minimum.

Try it

See the Workflow Engine for what sits under the loop, revisit how isolated stacks contain agent work , or reach out at [email protected] if you want an autonomous SDLC that asks permission before it expands its own scope.