“Which components run where?”
Ask for it in writing, component by component. The answer is usually more nuanced than the marketing page
AI coworker
Our answer
All of it, in your account
Nothing routed through us
Nothing routed through us
Self-hosted AI agents, without the vendor control plane
If you have already decided the problem is where the software runs, this is the short version: the coworker is deployed into your own cloud account, under roles your team issues, and nothing of ours sits between you and it.
A self-hosted AI agent runs on infrastructure the customer owns — their cloud account or their own hardware — rather than in the vendor's tenancy. The word is doing less work than it looks: most products described this way still run a vendor-side control plane, so the question that matters is which components land in your account, which stay in theirs, and what crosses between them.
Three things a vendor might mean by it
The word is on a lot of pricing pages and means something different on most of them. These are the three arrangements you will actually be offered.
See how deployment works →Your own instance, isolated from other customers, running in the vendor's cloud. Better than shared, and it does not change the answer to “where is our data processed”, which is the question the security review actually asks.
The workload runs in your cloud while orchestration, configuration and often the logs route through the vendor. This is the common case and the one worth pressing on: if their service goes down or goes away, find out what stops.
The whole deployment lives in your account. No console of ours, no queue through us, no copy of your data anywhere we can reach. This is the arrangement here, and it costs us the telemetry every vendor would rather have.
What “in your own cloud” actually commits us to
Eight properties that follow from the deployment model rather than from a setting somebody can change later.
Your account, your region
Deployed into an AWS, Azure, GCP or DigitalOcean account you already own, in the region you already chose.
Your IAM
It assumes roles your team issues, scoped per system, at the narrowest permission the job needs.
No vendor control plane
There is nothing of ours sitting between you and it. No console we log into, no queue that routes through us.
Your network reach
Running inside your perimeter, it reaches the internal systems a hosted agent has no route to at all.
Your audit logs
Every action lands in the logging you already collect, not in a vendor dashboard you have to request access to.
Your egress rules
It operates under the network and egress policy your team already enforces, including the deny-by-default ones.
Your off switch
One action from your team revokes all of it, and nobody has to be on a call with us for that to work.
Your model choice
Which model it calls, and from where, is a deployment decision rather than something baked into the product.
Deployed into an account you already own
The provider matters less than the three things underneath it: you control the account, the network policy, and the IAM.
The four facts a security review is actually asking about.
None of these are configuration. They follow from where the software runs, which is why they survive the second meeting.
Get a demoYour VPCis where it runsAWS, Azure, GCP or DigitalOcean — the account is yours
No copyof your data reaches usThere is no hosted version and there is not going to be one
Your IAMissues every credentialScoped per system, revocable without involving us
Your logshold the whole trailWritten where your team already looks for it
The question most vendors do not answer
“Does anything leave our network?”
Prompts, documents and logs each need their own answer. A single yes-or-no covering all three is not an answer
Your reviewerWhere do the prompts go?
AI coworkerNamed at build time, in writing.
“What if you disappear?”
The deployment is in your account. A vendor-side control plane fails this question the moment it is asked
Continuity
AI coworkerIt keeps running. The infrastructure is yours.
See the security page →Self-hosted, private, on-premise
Three words vendors use interchangeably, and the questions that tell them apart.
A self-hosted AI agent runs on infrastructure the customer owns — their cloud account or their own hardware — rather than in the vendor's tenancy. The word is doing less work than it looks: most products described this way still run a vendor-side control plane, so the question that matters is which components land in your account, which stay in theirs, and what crosses between them.
Not quite, and vendors use all three loosely. On-premise usually means your own hardware in your own building. Self-hosted usually means your cloud account. Private is the vaguest of the three and often means nothing more than a dedicated tenancy inside the vendor's cloud, which is a different thing entirely. Ask which components run where and the words stop mattering.
Ask three questions in writing. Which components run in our account and which in yours? Does any customer data, prompt, or document leave our network in normal operation? And if your company disappeared tomorrow, would the deployment keep working? The third one is the most revealing, because a vendor-side control plane fails it immediately.
AWS, Azure, GCP and DigitalOcean are the ones we deploy into today. What actually matters is less the provider than whether you control the account, the network policy, and the IAM — those are the three things the architecture depends on.
That is a deployment decision rather than a fixed property of the product, and it is worth taking seriously: a coworker running entirely inside your account that calls a model API outside it has still moved data across a boundary. Which model, hosted where, and what is sent to it are all set during the build and written into what your security review sees.
No. We build it and run it beside your team; the deployment being in your account changes who holds the data, not who does the work. That distinction is the whole point — the alternative products that put you in control also tend to put you in charge of maintenance, and those are separable.
Yes, and this is the practical reason teams end up here rather than the compliance one. An agent inside your network can reach the on-premise ERP, the internal database, and the tool behind the VPN — none of which a hosted product can see without you exposing them.
“Two products can do the same thing and still fail different security reviews. That is usually the whole comparison.”
Security reviewre: self-hosted agent
Which components run in the vendor cloud?
the question that separates them✓ None of ours doPut an AI coworker
inside your own cloud.
Bring the deployment constraint that ruled the last three vendors out. It is usually the reason this exists.
Get a demo