WorkOS horizon shows why autonomous code factories need tighter governance

At a glance

What this is: WorkOS’s Horizon is an internal autonomous code factory that combines event-driven orchestration, sandboxed execution, and shared context to speed software delivery while preserving human review.

Why it matters: It matters because agentic development changes how IAM, PAM, and NHI controls govern execution, tokens, sandbox access, and approval boundaries across engineering workflows.

👉 Read WorkOS's full analysis of the Horizon autonomous code factory

Context

The core problem is not code generation, it is orchestration, context, and trust. When software work moves from a human-paced loop to an event-driven agent loop, identity controls have to decide who or what can trigger work, which tools may be used, and how much of the delivery chain remains under human review.

In Horizon, WorkOS is treating agent execution as a governed runtime problem rather than a prompt problem. That makes the post useful for IAM and security teams because it shows the control pressure points that appear when autonomous code assistants are granted sandbox access, scoped tokens, and chained workflow permissions.

Key questions

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. Require per-run identity, scoped credentials, signed triggers, and human approval before merge. The key is not to stop automation, but to ensure every autonomous action has a bounded lifecycle, a clear owner, and an auditable trail from trigger to release.

Q: Why do autonomous code factories complicate least-privilege design?

A: Because privilege is no longer set once at provisioning time and left untouched. An autonomous agent can choose the next action, request more context, and continue across multiple steps, so least privilege has to be expressed at runtime across the sandbox, the trigger, and each tool in the chain.

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. If a merged change can immediately unblock and launch the next autonomous task, the environment starts behaving like a chained execution system, not a series of discrete approvals. That means access review and release governance must cover dependency-driven re-entry paths.

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.

Technical breakdown

Event-driven agent orchestration and webhook trust

Horizon normalizes external signals such as project changes and issue status updates into work items that can launch long-running agent sessions. That means the security boundary is not the model prompt, but the webhook, the signature check, and the orchestration logic that decides whether an event becomes execution. Once an event is accepted, the agent can keep working across multiple steps, which makes identity, context, and lifecycle controls part of the same trust surface. In practice, this is where teams either preserve control or create an unattended execution path.

Practical implication: treat webhook ingress as an identity boundary and require strict signature validation, filtering, and scoped execution policies.

Cloud sandboxes as isolated execution identities

A cloud sandbox is more than a test environment when agents can run builds, inspect logs, and make changes inside it. In Horizon’s design, each run gets isolated, reproducible, and independently verifiable execution, with egress controls used to limit what the agent can reach. That makes the sandbox a non-human execution identity with its own privileges, lifespan, and containment rules. The important technical shift is that the sandbox is where least privilege becomes enforceable at runtime, not just at provisioning.

Practical implication: define each sandbox as a separately governed NHI workload with explicit egress, short-lived credentials, and per-run teardown.

MCP context, short-lived tokens, and delegated tool access

Horizon uses a custom MCP server and scoped tokens to connect agents with logs, errors, chat history, and repository actions without exposing broad credentials directly to the agent. This is a classic delegation chain: human identity, issue ownership, scoped GitHub access, sandbox runtime, and tool-mediated context access all intersect. The technical risk is not merely secret leakage, but over-broad trust in a chain where each link extends the agent’s effective reach. When agents can retrieve context and then act on it, tool access becomes part of the authorisation model, not an afterthought.

Practical implication: inventory every tool exposed through MCP-style context layers and apply separate authorization, logging, and revocation paths to each one.

Threat narrative

Attacker objective: The objective is to gain durable, trusted execution inside the delivery pipeline so work can be created, modified, and advanced with minimal human friction.

1. Entry begins when an approved webhook or ticket transition triggers a new agent session inside the orchestration layer, turning business workflow events into execution requests.
2. Escalation occurs when the sandbox, scoped tokens, and connected tools give the agent enough reach to inspect context, generate code, and prepare pull requests across multiple systems.
3. Impact is the creation of a self-reinforcing delivery loop where agent work is re-queued, dependency chains advance automatically, and human review becomes the last control before production changes land.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Event-driven code factories turn webhooks into identity-bearing execution paths. The governance mistake is to treat webhook handling as plumbing rather than as delegated authority. Once a ticket transition can spawn sandboxed work, the authorisation model extends beyond the user who clicked the button. Practitioners should read this as a control-plane problem, not a developer productivity story.

Scoped tokens are necessary but not sufficient when the context layer can widen effective access. Horizon’s use of short-lived credentials and linked identity is directionally sound, but the real challenge is that tool-mediated context can expand what the agent can do after the token is issued. That makes privilege analysis dynamic, not static. The practitioner takeaway is that identity governance must include the context surface, not just the credential.

Cloud sandboxes create a new class of managed NHI that sits between CI, developer tooling, and autonomous agents. This is a named governance space with its own lifecycle, logging, and egress obligations. The technical pattern is neither ordinary workload identity nor ordinary developer access. Teams need to recognise sandbox execution as a first-class NHI domain with explicit containment and revocation semantics.

Review-first design reduces risk, but it does not erase the governance burden created by autonomous execution. Human approval at pull-request time is a useful brake, yet the system still accumulates delegated actions, stored context, and chained dependencies before that review happens. That means the control objective shifts from stopping every action to constraining what autonomous work is allowed to become before a human ever sees it.

From our research:

• 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.
• For a deeper lens on secret exposure and AI-assisted abuse, see DeepSeek breach and use it to pressure-test your runtime controls.

What this signals

Autonomous execution changes the unit of governance from user session to work session. That is why sandbox lifecycle, event validation, and tool scoping now matter as much as commit hygiene. The control plane has to understand when work starts, what it can touch, and how it is forced to stop before the next autonomous action begins.

Identity blast radius becomes the more useful concept than account count. A single agent can bridge tickets, code, logs, chat, and deployment systems if the context layer is loosely governed. That makes egress policy, scoped context, and per-tool revocation the practical variables that determine whether the programme stays containable.

With 6 distinct secrets manager instances on average, per The State of Secrets in AppSec, fragmented control surfaces will struggle even more when agents are the ones moving data between them. The programme response should be to simplify where trust is granted, not to assume another review checkbox will absorb the risk.

For practitioners

• 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.
• Limit agent reach with explicit egress controls Proxy outbound traffic, maintain allowlists, and log every external call so the sandbox cannot exfiltrate data or widen its own context through unapproved endpoints.
• Redesign review gates around runtime evidence Require deterministic artefacts such as test output, screenshots, and DOM snapshots before merge so human approval is based on proof, not on agent assertions.

Key takeaways

• Horizon shows that autonomous software delivery is really a governance problem wrapped in productivity language.
• The biggest risk is not code generation itself but delegated execution that can re-trigger, widen context, and outpace human review.
• Teams need sandbox-level lifecycle control, signed triggers, scoped tool access, and evidence-based merge gates before autonomous coding becomes routine.

Key terms

• Autonomous code factory: An autonomous code factory is a software delivery system where agents receive triggers, select work, run tools, verify output, and queue the next task with limited human direction. In practice, it is a governed execution loop, not just a coding assistant, so lifecycle and approval controls become part of identity security.
• Sandbox lifecycle: Sandbox lifecycle is the start, pause, resume, and teardown pattern that governs a temporary execution environment. For autonomous agents, it is an identity control surface because the sandbox holds permissions, context, and data access for a bounded run and must be revoked as deliberately as it is created.
• Context surface: The context surface is the set of logs, issues, chats, documents, and repositories an agent can query to make decisions. It is more than data access because it shapes behaviour, so security teams must govern it like an authorisation boundary rather than a convenience layer.
• Delegated execution path: A delegated execution path is a chain where one identity or event authorises another system to continue work across tools and environments. In autonomous workflows, the path can outlive the original human action, so practitioners must control trigger validation, scope, and revocation at each link.

Deepen your knowledge

Autonomous code factories, event-driven agent orchestration, and sandbox governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic development workflows, it is worth exploring.

This post draws on content published by WorkOS: The self-driving codebase, Building Horizon at WorkOS. Read the original.