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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: An internal autonomous code factory uses event-driven agents, secure sandboxes, and custom context to keep software work moving while humans remain in the review path.
Why it matters: It matters because identity teams now have to govern agent-run development loops, short-lived repository tokens, and approval boundaries that behave differently from traditional human-led workflows.
Context
Autonomous code factories are development systems where agents do more than draft code. They take incoming work signals, plan tasks, execute changes in isolated runtimes, verify the result, and queue the next unit of work.
The governance problem is not just access control. It is deciding how identity, context, and approval behave when the actor can keep re-entering the workflow, reuse toolchains, and trigger follow-on work without a human resetting the loop first.
WorkOS’s Horizon example is useful because it treats autonomy as an operating model, not a demo. The article describes a review-first system that still exposes the pressure points identity teams need to govern: scoped tokens, sandbox isolation, and human handoff boundaries.
Key questions
Q: What breaks when autonomous code factories re-queue work without a human resetting the loop?
A: The break is the assumption that approval on one task closes the governance cycle. In an autonomous code factory, merge completion can immediately trigger follow-on work, so identity and access controls must cover the next run, not only the current review. Otherwise, authority accumulates across chained execution cycles instead of ending at approval.
Q: Why do short-lived tokens still need strict scope controls in agentic development?
A: Because lifespan and scope are different controls. A short-lived token can still authorize too much if the agent can combine multiple tools, context sources, and repository actions inside the same run. The real risk is compound authority during execution, not just credential persistence.
Q: What are the signs that an autonomous development workflow is exceeding its intended boundary?
A: Look for agents that can re-enter the workflow automatically, retrieve broad context from multiple systems, and continue task generation after merge without explicit governance checkpoints. Those signals show the system has moved from task automation to self-propagating execution, which requires tighter run-level controls and sandbox boundaries.
Q: How should teams govern autonomous code factories across sandbox, identity, and review controls?
A: Teams should separate execution from verification, broker context through controlled surfaces, and keep humans in the approval path for merges and re-queued work. The goal is not to slow agents down indiscriminately, but to make every run use the minimum access and the narrowest viable trust boundary.
Technical breakdown
Event-driven agent orchestration in code factories
Horizon is built around webhook-triggered work rather than a single user session. That means the orchestrator receives external signals, normalises them into tasks, and spins up long-running agent sessions in a sandbox where code can be written, tested, and re-queued. The important shift is that task initiation, execution, and follow-on scheduling are no longer bound to a human’s immediate attention. The workflow becomes stateful across multiple systems such as Linear, GitHub, and internal context sources. For identity governance, that turns the development loop into a distributed control plane with many trust edges, not a simple user-to-tool interaction.
Practical implication: Treat the orchestration layer as an identity boundary and define which events are allowed to trigger agent execution.
Scoped tokens and tool access for autonomous development
The Horizon design uses short-lived GitHub tokens, repository-scoped app tokens, and custom MCP-mediated access to internal context. That matters because agentic development is not just about getting a model to write code. It is about constraining which credentials, tools, and data sources the agent can touch during each run. Short-lived credentials reduce exposure, but they do not by themselves solve the trust problem if the agent can combine multiple tools and context streams inside one execution cycle. The control question shifts from broad user entitlement to per-run authority, credential scope, and explicit access brokerage.
Practical implication: Map every agent workflow to the minimum tool and token scope needed for that run, then block all other access paths.
Secure sandboxes and egress controls for agent verification
A cloud sandbox is more than a convenience layer for autonomous code systems. In Horizon, it is the execution boundary that isolates concurrent runs, supports reproducible builds, and allows outbound traffic to be proxied through controlled egress paths. That design is especially important for prompt injection, data exfiltration, and cross-environment contamination risks. If an agent can fetch context, run builds, and contact external services without egress governance, the sandbox stops being a control and becomes a transport layer. The architecture therefore depends on lifecycle APIs, network policy, and verification separation as much as on model quality.
Practical implication: Keep agent execution, verification, and outbound access in separate control planes so a single run cannot cross trust boundaries unnoticed.
Threat narrative
Attacker objective: The practical objective in the risk model is not classic intrusion, but uncontrolled execution breadth that lets an autonomous workflow expand its own operational reach.
- Entry begins when external work signals such as webhooks create a new autonomous run and hand it into the orchestration layer.
- Credential access occurs through scoped GitHub tokens, repository app tokens, and MCP-mediated context access that the agent can use during execution.
- Escalation happens when the agent re-queues dependent work after merge and continuously re-enters the workflow with fresh tasks and context.
- Impact is compounded development-side change velocity, where the system can keep producing and chaining work faster than manual review cycles alone can absorb.
Breaches seen in the wild
- Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Autonomous code factories collapse the assumption that work moves only when a person advances it. Horizon shows a model where tasks can be created, split, implemented, verified, and re-queued by agents in response to system events. That is materially different from ordinary developer automation because the workflow itself becomes the unit of governance. Practitioners should read this as a shift from user-session control to run-cycle control.
Short-lived credentials are necessary in autonomous development, but they are not sufficient governance. Horizon still depends on GitHub tokens, repository-scoped app access, and brokered context access. The deeper issue is that an agent can combine multiple legitimate permissions within one run, so the governance question becomes how much compound authority a single execution cycle may assemble. The implication is a tighter model of per-run entitlements and access brokerage.
Secure sandboxes are now identity controls, not just infrastructure controls. Once an agent can write code, run tests, inspect logs, and call out to tools, the sandbox defines the trust boundary around the identity. That makes egress policy, lifecycle control, and environment separation part of IAM-adjacent governance for autonomous systems. Practitioners should treat sandbox boundaries as an enforceable access policy for machine-run development.
Review-first workflows still need machine-speed governance around follow-on work. Horizon keeps humans in the merge path, but the article makes clear that the next task can be triggered automatically after merge. That means approval is no longer the same as closure. The practitioner takeaway is that governance must cover what happens after one task completes, not only whether the current task was reviewed.
Agentic development introduces a context surface problem that classic IAM does not model well. Horizon relies on logs, errors, conversations, and custom MCP context to make decisions. That creates a named governance gap we can call context surface control: the need to bound which runtime context an agent can see, combine, and carry forward. Teams should assume context is part of the access model, not just an input to the model.
What this signals
Context surface control: autonomous development systems now need governance over logs, errors, chat history, and issue context as first-class access surfaces. If an agent can combine those inputs freely, IAM has silently expanded into runtime context management.
Review-first operating models remain useful, but they do not eliminate the need to govern what happens after merge. The next control boundary is the re-queued task, because that is where autonomous systems turn a single approved change into a continuing workflow.
Purpose-built sandboxes change the unit of trust from the developer workstation to the agent run. That shift pushes practitioners to think about sandbox lifecycle, outbound access, and context brokerage as part of identity governance for autonomous systems.
For practitioners
- Define run-level access boundaries Document which credentials, tools, and data sources an autonomous coding run may assemble in a single execution cycle, then deny any cross-run privilege carryover.
- Separate execution from verification Use distinct sandboxes or runtime profiles for code writing, testing, and browser or security verification so the same agent path cannot blend all three trust functions.
- Broker context through controlled surfaces Treat logs, errors, conversations, and issue context as governed inputs and expose them through a mediated context layer rather than direct broad access.
- Make merge completion non-final Extend approval logic beyond pull-request review so post-merge re-queuing, dependency unblocking, and follow-on task creation all remain visible to governance.
Key takeaways
- Autonomous code factories shift governance from human task assignment to machine-run execution cycles that can keep generating work after merge.
- The article’s risk signal is not only speed, but compound authority across tokens, sandboxes, and context surfaces inside one autonomous run.
- Practitioners should control run-level access, isolate execution from verification, and treat post-merge re-queuing as part of the governance boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Horizon centers on agent-run access, scoped tokens, and execution boundaries. |
| Recommendation — Apply ASI03 to bound agent privileges per run and prevent compound authority across tool chains. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The workflow relies on short-lived tokens and brokered access for autonomous runs. |
| NHI-05 — Overprivileged NHI | The article repeatedly stresses scoped repository tokens and least-privilege sandbox access. | |
| NHI-08 — Environment Isolation | Horizon depends on separate sandboxes for planning, writing, and verification. | |
| Recommendation — Harden machine authentication paths so autonomous runs never receive broader trust than required. Review every agent token and sandbox grant for excess scope and remove unused permissions. Segregate agent runtime environments so one run cannot contaminate another or cross trust zones. | ||
| NIST Zero Trust (SP 800-207) | Least privilege and explicit trust boundaries | The article frames egress controls, sandbox boundaries, and controlled context as trust boundaries. |
| Recommendation — Enforce explicit trust boundaries around every agent execution path and outbound connection. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about who and what the autonomous system can access during each run. |
| Recommendation — Continuously validate agent entitlements against PR.AA-05 and revoke any permission not needed for the run. | ||
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.
- Run-level access: The specific credentials, tools, and data sources available to one autonomous execution cycle. This is narrower than general account access because the relevant control question is what the agent can assemble during a single run, including context, tokens, and outbound connections.
- 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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org