Agent factories still need boring permissions

The agent-factory conversation keeps drifting toward speed. More tasks. Longer runs. Fewer humans touching the keyboard.

Fine. But speed is the least interesting part if the system cannot explain what happened.

Cloudflare's Agent Development Lifecycle post argues that agents should move beyond code generation into the rest of the software lifecycle. The useful part is not the new acronym. It is the checklist hiding underneath it: programmatic operations, isolated previews, reproducible checks, event-driven work, atomic changes, permissions, and learning from prior runs. GitHub is moving in the same direction from the security side. Its 2026 Actions roadmap talks about deterministic workflow dependencies, workflow execution protections, scoped secrets, and runner observability. Its third-party coding-agent validation already runs CodeQL, dependency checks, and secret scanning on code produced by tools like Claude and Codex.

Sources: Cloudflare on the Agent Development Lifecycle, Cloudflare Agents and traces, GitHub security validation for third-party coding agents, GitHub workflow execution protections, GitHub Actions 2026 security roadmap.

Autonomy moves the bottleneck

Implementation used to be expensive. Now it can be cheap enough to become noisy.

That does not remove the bottleneck. It moves it. Review, deployment, incident response, ownership, secrets, and rollback become the scarce parts. The agent can create the patch faster than the organization can prove the patch is safe.

I see this in small systems too. A cron job that writes two blog posts is easy to imagine. The hard part is proving the links work, the sources exist, the writing is not filler, the build passes, the PR merged through the right gate, and the live URLs return the expected content. The same shape appears in code: writing the change is often easier than proving the change belongs in production.

That is why the boring controls matter. They are not enterprise paperwork. They are the parts that keep automation from turning into cleanup.

Traces beat confidence

An agent saying "I verified it" is not verification.

Cloudflare's Agents product records spans for agent invocations, model calls, tool execution, approval events, token usage, and worker resources. The important design choice is replay. A trace lets someone inspect what the agent saw, what tool it called, what it wrote, and where the time or money went.

That is a much better object than a polished summary.

Summaries are useful after the fact. Traces are useful when the summary is wrong. If an agent publishes to the wrong account, leaks a private URL, retries a broken provider ten times, or patches the wrong workflow file, the postmortem needs raw sequence, not vibes.

The practical rule: every agent action that can change external state should leave an audit object a second agent can read without trusting the first agent's prose.

Permissions should be visible before the run

GitHub's workflow execution protections are interesting because they move trust out of scattered YAML and into policy. Actor rules control who can trigger workflows. Event rules control which events can run. Evaluate mode lets teams see what a policy would block before enforcing it.

That is the right mental model for agents.

A good agent platform should answer these questions before the run starts:

Who triggered this?
Which repo, account, or integration can it touch?
Which events are allowed?
Which writes are staged for review?
Which secrets are unavailable by design?
What stops the run if policy changes underneath it?

If those answers live only in a prompt, they are not controls. They are suggestions with better typography.

Validation needs to happen where the work lands

GitHub's third-party agent validation matters because it does not depend on which coding assistant produced the diff. CodeQL, dependency checks, and secret scanning run on the generated code before the PR is finalized.

That is the healthy pattern. Do not make the agent's brand the trust boundary. Make the repository's gates the trust boundary.

The same applies outside code. A social post should be checked against the platform schema and provider state. A CMS entry should be checked by the production renderer. A news brief should be checked against source URLs. A deployment should be checked at the live route, not at the moment the merge button turned purple.

The work counts when the destination verifies it.

The boring stack is the product

The agent demo is the easy sell. Watch it open files, write code, and pass tests. It feels like the future because the screen moves by itself.

The future I trust is less cinematic:

• constrained permissions,
• staged writes,
• source-visible claims,
• traces a reviewer can replay,
• CI that classifies platform failure separately from code failure,
• live smoke checks after deployment.

That stack will feel slow to people who only measure typing. It will feel fast to anyone who has had to clean up a confident automation run at 2am.

Agent factories do not become serious when they write more code. They become serious when the boring parts are first-class: permissions, evidence, review, rollback, and receipts.