Somewhere in your product's docs, there is a page called "Install the agent."

Maybe yours calls it the collector, the connector, or the gateway. It's the component customers run inside their own environment so your product can reach data that will never be sent to you: the analytics proxy, the security collector in the VPC, the log forwarder, the on-prem gateway, the webhook relay for the enterprise that won't open an inbound port.

It runs in networks you can't see, with credentials to systems you don't own. And at most companies, nobody operates it.

How it's born

No roadmap meeting approves the agent. It starts as a workaround:

1. 1

   A support scriptweek one

   An enterprise prospect can't send you the data, so a support engineer writes a script that runs on their side and pushes results out. The deal closes.

2. 2

   An installermonth three

   A second customer needs it. The script becomes a Docker image, then a Helm chart, then a docs page with a name.

3. 3

   A dependencyyear one

   Your largest accounts all run it. Features assume it exists. Sales includes it in the pitch.

4. 4

   Production software, minus the production parttoday

   It has versions nobody upgrades, permissions nobody reviews, and outages nobody can see. No team owns it.

By the last step, every node of this system lives in a different company's infrastructure, and nobody is running it. Some customers are eighteen months behind. One granted it admin because that made the install error go away. Another put it behind a proxy you learned about during the outage it caused. When it breaks, you debug through screenshots and pasted logs.

The most access, the least engineering

Your main product has release engineering, on-call, and a threat model. The agent has none of that: no roadmap approved it, no budget created it, no team owns it.

It is also the component with the most access: it sits inside the customer's network, holds credentials to their systems, and ships their data out. The least-engineered component holds the most sensitive position. That shows up in three places:

Security reviews. The agent is the part of your product a security team reads most carefully — it's the part inside their network. If its permissions accumulated one support ticket at a time and you can't state which versions run where, the review goes badly. And it goes badly on your largest deals, because those are the customers who require the agent.

Incidents. An outage in your cloud pages someone. An outage in the agent arrives as a support ticket — "the dashboard stopped updating" — hours later, and the investigation runs through the customer's hands.

Ownership. Every other production system in your company has a team. The agent has whoever touched it last. Versioning, upgrades, and permission scoping are nobody's job, so they don't happen.

Deployment into customer environments, updates you don't control, permissions a reviewer will read, observability without access — that is the BYOC problem set. Most teams have it without ever deciding to do BYOC.

The only decision is whether it's designed

You don't get to decide whether you deploy into customer environments. If your product needs data that can't leave, and enterprise customers exist, you already do. The only decision left is whether the component is designed.

Designed means the agent is treated as production software: a defined footprint (what it runs on, what it stores, what it can reach), a release process, health you can observe, a security story you can present, and an owner.

Undesigned means what most teams have today: a version spread nobody can state, permissions nobody would volunteer in a security review, and a support queue that fills with "the agent stopped sending data."

Closing that gap does not require a rewrite. Most teams assume it does, so they postpone it. But the component usually works. What it's missing is a control plane: something you run that knows what's deployed where, which versions are live, whether each instance is healthy, and can say so in a security review. The agent was always a data plane running in someone else's cloud. It never had the other half.

Where Alien fits

That's the half Alien provides. It attaches over an outbound-only connection to the component you already ship and gives you the inventory, health, and update path it never had — no rewrite, no migration, no new install story for the customers already running it. When the agent is worth treating as a full product, you define it in alien.ts and Alien handles its releases, permissions, and rollbacks.

Either way, the first step is the same: treat the agent as part of the product. For your largest customers, it already is.

---

The deployment model the agent grows into is in what is BYOC?, and the first design question it forces — where login happens and where credentials live — is in authentication for BYOC apps.