# How enterprises automate software development privately

> How enterprises automate software development when source code cannot leave their control: private deployment, data residency, air-gapped operation, model control, and telemetry privacy, with recent AI tooling incidents and customer examples.

URL: https://factory.com/articles/how-enterprises-automate-software-development
Published: 2026-06-24
Updated: 2026-10-23

Large enterprises automate software development by handing scoped work to agents that read repositories, run builds, call models, and open pull requests. The question that decides most rollouts is where that work happens. An agent with access to a monorepo, build credentials, and a model endpoint is a new path for source code and secrets to leave the organization, so security teams now evaluate deployment, data residency, model control, and telemetry before they evaluate productivity.

The examples below come from published security advisories, Factory documentation, and customer-authored case studies. They do not speculate about private deployments that have not been announced.

## Why privacy now decides how enterprises automate software development

Incidents since mid-2025 show that developer tooling, including AI coding tools, sits directly on the software supply chain. As of October 2026, the following are documented by the vendors or government agencies involved.

In July 2025, AWS reported in [security bulletin AWS-2025-015](https://aws.amazon.com/security/security-bulletins/AWS-2025-015/) (CVE-2025-8217) that an inappropriately scoped GitHub token in the build configuration of the Amazon Q Developer extension for VS Code let a threat actor commit malicious code that was automatically included in version 1.84.0. AWS states the code failed to execute because of a syntax error, and it released version 1.85.0 and removed 1.84.0 from distribution.

In August 2025, malicious versions of the Nx build system were published to npm. The [Nx maintainers' advisory](https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c) describes code that scanned the file system, collected credentials, and posted them to new repositories under the victim's GitHub account. [Socket's research team reported](https://socket.dev/blog/nx-packages-compromised) that the payload also invoked locally installed AI command-line tools to search for sensitive files, which it described as one of the first documented supply chain attacks to do so.

The same month, Microsoft published CVE-2025-53773, a command injection vulnerability in GitHub Copilot and Visual Studio that could let an attacker execute code locally. It is listed in the [Microsoft Security Update Guide](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53773). In May 2026, Microsoft's security research team [disclosed two Semantic Kernel vulnerabilities](https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/), CVE-2026-25592 and CVE-2026-26030, in which prompt injection could reach code execution through the agent's tools. Both have been fixed.

Package registries remain the larger exposure. CISA's [April 2026 alert](https://www.cisa.gov/news-events/alerts/2026/04/20/supply-chain-compromise-impacts-axios-node-package-manager) describes how two published Axios versions pulled in a malicious dependency that downloaded a remote access trojan. In August 2026, Singapore's Cyber Security Agency [reported a Shai-Hulud variant](https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-009/) that had compromised more than 1,300 npm package versions and advised organizations to treat credentials on affected systems as potentially compromised.

None of these incidents depended on a model misbehaving. They depended on what the developer environment could reach: tokens, environment variables, the network, and tools that run commands. An agent that installs dependencies and runs tests inherits that same exposure, which is why enterprises draw the boundary first and automate inside it.

## Where code and context go during agent work

A coding agent creates four separate data paths, and each needs its own placement decision. Factory's [privacy and data flows documentation](https://docs.factory.com/enterprise/privacy-and-data-flows) describes them for Droid, Factory's agent.

**The working copy.** Droid reads and edits files on the machine where it runs, which can be a laptop, a CI runner, a container, or a VM inside the customer network.

**Model requests.** Context selected for inference travels to the configured model endpoint. Factory documents that with enterprise endpoints such as Azure OpenAI, AWS Bedrock, and Google Vertex AI, traffic goes directly to the provider's API, and prompts and responses are not stored in Factory cloud in that configuration.

**Session coordination.** The control plane coordinates sessions and stores their context. Whether Factory or the customer hosts it is the main difference between deployment options.

**Telemetry.** Metrics, traces, and optional message content can go to Factory, to the customer's own collector, or nowhere.

Treating these as one decision is the most common evaluation mistake. An approved model provider answers the inference question without answering where session context is stored. [AI code data residency](https://factory.com/articles/ai-code-data-residency) follows each path in more detail. Factory's published deployment comparison shows how control-plane ownership and operating responsibility shift between options.

## Private deployment, data residency, and air-gapped operation

Factory supports a range of boundaries, and enterprises often run more than one across teams. Factory's [deployment patterns](https://docs.factory.com/enterprise/network-and-deployment) cover cloud-managed, hybrid, and fully airgapped operation.

With [Factory Managed](https://factory.com/deployment/factory-managed), Factory operates the control plane while Droid runs on customer machines and model traffic can still go through the customer's own gateways. With [Factory Private](https://factory.com/deployment/factory-private), the customer hosts the control plane in its own VPC or on-premises environment and takes responsibility for upgrades and recovery. [Factory Managed vs Private](https://factory.com/articles/factory-managed-vs-private) compares the operating trade-offs.

Organizations with European residency requirements can use Factory's dedicated EU deployment, which runs its own backend, database, and inference endpoints in Europe. Factory documents that session content for EU organizations is stored in Europe and that their LLM requests go only to EU-region endpoints.

For classified or disconnected networks, Factory ships a dedicated [airgap build](https://docs.factory.com/enterprise/airgapped-deployment). In Airgap Mode, Droid skips sign-in, offers only customer-configured models, and disables update checks, session sync, crash reporting, and Factory telemetry. The documentation is explicit that Airgap Mode is cooperative and that isolation must come from the customer's own network controls and sandbox egress rules. Cloud features such as session sharing and Factory-hosted analytics are unavailable in that mode. [Air-gapped AI development](https://factory.com/articles/air-gapped-ai-development) walks through validating a fully offline workflow.

Blackstone's requirements show how this plays out in a regulated firm. The [Blackstone case study](https://factory.com/case-studies/blackstone) records that the firm needed agents to run inside its existing technology environment, and that Factory supported deployment inside its data center.

> "It was absolutely critical to ensure that agents ran inside of our data center, under our control, underneath our observation."
> John Stecher, CTO at Blackstone

## Model control and telemetry privacy

Model choice is a privacy control as much as a cost decision, because the model endpoint receives repository context. Factory is model-independent by design. With [Bring Your Own Key](https://docs.factory.com/model-independence/byok), an organization points Droid at its own provider accounts, an internal gateway, or self-hosted models, and the airgap build requires at least one such custom model. [Self-hosted models for confidential source code](https://factory.com/articles/private-ai-model-gateways) covers gateway routing and credential handling.

Administrators enforce those choices centrally. Factory's [Enterprise Controls](https://docs.factory.com/enterprise/hierarchical-settings-and-org-control) apply organization policy for permitted models, command permission rules, sandbox settings, and managed hooks across laptops, CI, and airgapped machines. Factory's safety documentation describes Droid Shield, which scans for secrets during git commit and push operations. Droid Shield keeps secrets out of commits. It cannot stop malware already running on a machine, which is why the sandbox and egress controls in the rollout below carry most of the weight against incidents like Nx and Shai-Hulud.

Blackstone framed the same requirement from the governance side. "Model choice was a big one," says Monty Hall, CTO of Data, Cloud and Developer Experience at Blackstone. "We didn't want lock-in with any single lab or provider and thus constrain innovation. We also have very strict controls around governance and security."

Telemetry is the path most often overlooked. Factory's [telemetry privacy controls](https://docs.factory.com/enterprise/telemetry/privacy) state that spans, including all message content, never reach Factory's collector in any configuration, and that message content export to a customer collector is off by default. Setting `telemetry.granularity` to `aggregate` removes user identity, commit hashes, and pull request references from every datapoint at the source, which supports works council agreements and similar rules. [AI agent telemetry inside private networks](https://factory.com/articles/ai-agent-telemetry-privacy) covers choosing what to collect.

Nav, a fintech serving small businesses, described the privacy requirement in its [case study](https://factory.com/case-studies/nav).

> "As a fintech company handling sensitive financial data, we were concerned about how to leverage AI while maintaining strict data privacy and security standards. Factory provided us with a secure, controlled way to unify our engineering context without compromising our compliance requirements. The difference between that and having sensitive information flowing into random LLMs is night and day."
> Gian Perrone, CTO at Nav

## What enterprises report after automating inside the boundary

A private boundary does not have to limit the scope of the work. Several of Factory's customer case studies describe large automation programs run under strict controls.

Blackstone uses Droids across the software development lifecycle, including code review, testing, documentation, and larger engineering tasks. On one project, a requirements document and working proof of concept that previously would have taken product managers and engineers about a month took one engineer roughly a week and a half.

[Comarch](https://factory.com/case-studies/comarch), the European IT services company, set out to build its own internal software factory without giving up the human governance layer built from decades of experience. Its engineers hand long-running work to Factory Missions, which coordinate agents across planning, implementation, testing, and fixes. In a scoped XSLT modernization project, work that Comarch estimated would take 10,000 man days was completed with Factory in 45 days. Comarch also reports a 40% efficiency gain among its engineers.

> "Humans work with joy throughout the day. Factory finishes the work, which is then picked up by the human the next morning."
> Dr. Łukasz Bolikowski, Chief AI Officer at Comarch

[Chainguard](https://factory.com/case-studies/chainguard) builds hardened open-source packages, so supply chain security is its core business. Staff Engineer Josh Wolf ran a single Droid session for two weeks across six repositories and built 80 packages. "Like most real engineering problems, our use cases require a lot of context from various upstream sources and across multiple internal repositories," Wolf says. "Specifically at Chainguard, where we juggle both our internal codebases and an ever-growing chunk of the open source ecosystem."

## How a private enterprise rollout typically progresses

Enterprises that automate software development under strict data controls tend to settle the boundary before they widen the scope of the work. A common sequence, drawn from Factory's documentation and the case studies above, looks like this.

1. **Classify the data and choose the boundary.** Decide which repositories may use a Managed control plane, which require Factory Private, and which require airgapped operation. Record the decision per repository rather than per team.
2. **Fix the model routes.** Configure approved providers or internal gateways through BYOK and block every other model in organization policy.
3. **Lock down the execution environment.** Run higher-autonomy work only inside sandboxed containers or VMs with short-lived credentials, restricted egress, and dependencies from approved internal mirrors. This is the control that limits a compromised package like the ones in the 2025 and 2026 npm incidents.
4. **Pilot on one team.** Start with the Droid CLI on a single team and measure cycle time, review outcomes, and policy violations.
5. **Configure telemetry deliberately.** Send metrics to an internal collector, keep message content export off unless an audit requires it, and use aggregate granularity where per-person analytics are not permitted.
6. **Widen to long-running work.** Once review and audit processes hold, move to [Missions](https://docs.factory.com/missions/overview) for multi-feature and migration projects.

Exercise the negative cases at each step. A prohibited command should stay prohibited, an unapproved model should not be selectable, and an outbound request to an unlisted host should fail. Factory's [compliance, audit, and monitoring](https://docs.factory.com/enterprise/compliance-audit-and-monitoring) documentation covers the audit evidence that security reviewers typically request, and Factory's [security page](https://factory.com/security) summarizes its certifications.

Factory's sovereign software development whitepaper covers the deployment and governance decisions behind this sequence in more depth.

## Frequently asked questions

### How do enterprises automate software development?

They hand scoped work to agents that read repositories, run builds, call models, and open pull requests, and they decide first where that work happens and what it can reach.

### Why does privacy decide enterprise rollouts?

An agent with access to a monorepo, build credentials, and a model endpoint is a new path for source code and secrets to leave the organization. Recent incidents depended on what the developer environment could reach, such as tokens, the network, and tools that run commands.

### Where does code go during agent work?

A coding agent creates separate data paths. Droid reads and edits the working copy on the machine where it runs, and context selected for inference travels to the configured model endpoint. Each path needs its own placement decision.

## Further reading

- [Self-hosted AI agents and control-plane ownership](https://factory.com/articles/self-hosted-ai-agents)
- [On-prem AI development inside your security boundary](https://factory.com/articles/on-prem-ai-development)
- [Factory Private architecture inside your boundary](https://factory.com/articles/factory-private-architecture)
- [What the PHP vulnerability means for enterprise](https://factory.com/articles/php-vulnerability-enterprise)
- [CVE explained: what PHP2Shell tells security teams](https://factory.com/articles/cve-explained)
- [Factory enterprise documentation](https://docs.factory.com/enterprise)