Notifications
Clear all
Topic starter
06/06/2026 1:48 am
TL;DR: Access review processes assume access persists long enough to be reviewed; Horizon’s design shows why that assumption starts to break when work is generated, executed, and re-queued by agents, according to WorkOS. WorkOS describes Horizon as an internal autonomous code factory that turns webhooks, cloud sandboxes, and custom MCP-based context into an event-driven development loop, while keeping humans in the review path and tightening egress controls around agent execution.
NHIMG editorial — based on content published by WorkOS: The self-driving codebase, Building Horizon at WorkOS
Questions worth separating out
Q: How should security teams govern autonomous coding agents in software delivery pipelines?
A: Treat the agent, its sandbox, and its tool access as a single governed execution path.
Q: Why do autonomous code factories complicate least-privilege design?
A: Because privilege is no longer set once at provisioning time and left untouched.
Q: What breaks when agents can trigger their own next tasks after a merge?
A: The assumption that human intervention naturally resets the control loop breaks down.
Practitioner guidance
- Classify agent sandboxes as governed NHI runtimes Assign each sandbox its own lifecycle owner, logging policy, egress policy, and teardown requirement so one run cannot inherit trust from another run.
- Treat webhook triggers as delegated authority Require signature validation, event filtering, and per-event authorization before any ticket, status change, or merge event can launch agent execution.
- Scope every tool exposed through MCP-style context layers Document which logs, chats, repos, and issue trackers the agent can reach, then review those entitlements separately from the primary sandbox token.
What's in the full article
WorkOS's full post covers the operational detail this analysis intentionally leaves for the source:
- The end-to-end Horizon workflow across Linear, Notion, Figma, GitHub, and sandbox execution.
- The infrastructure tradeoffs behind Cloudflare Sandboxes, including egress controls and lifecycle APIs.
- The custom MCP server design used to connect logs, errors, Slack, and repository context.
- The practical lessons from turning internal engineering work into an event-driven agent system.
👉 Read WorkOS's full analysis of the Horizon autonomous code factory →
Autonomous code factories: what Horizon means for IAM teams?
Explore further
06/06/2026 3:08 am
Autonomous development collapses the assumption that work can be governed only at assignment time. That assumption was designed for human-paced delivery, where a ticket, an owner, and a review queue create natural control points. It fails when the actor is autonomous because the system can generate the next task, choose the next tool, and re-trigger execution without waiting for a new human decision. The implication is that governance has to move from assignment records to runtime behaviour.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 44% of developers are reported to follow security best practices for secrets management, exposing a persistent behaviour gap across delivery teams.
A question worth separating out:
Q: What is the difference between a code assistant and an autonomous code factory?
A: A code assistant helps with a task the human is already driving. An autonomous code factory receives triggers, selects work, executes across tools, verifies output, and queues the next task with far less human direction. The distinction matters because governance has to cover runtime authority, not just code completion.
👉 Read our full editorial: WorkOS horizon shows why autonomous code factories need tighter governance
