What is a private AI agent?

A private AI agent is one whose knowledge, tools, network access, and data retention are each deliberately scoped by the organisation running it. That's different from leaving each to whatever a platform or model provider defaults to. An agent earns the label "private" only when all four of these are controlled on purpose, not because a vendor states somewhere that its model doesn't train on customer data.

In short: self-hosting an agent, or choosing a model that doesn't train on customer data, can help. Neither alone makes an agent private; both matter, but what actually makes it private is controlling all four boundaries on purpose.

The rest of this covers what each boundary actually means, and how to control what an AI agent can access in practice. It also covers why self-hosting and a no-training clause are each necessary but not sufficient, and what to ask a vendor before trusting it with anything sensitive.

What actually makes an agent private, and what doesn't

Being private is a property of what an agent can reach, and what happens to what passes through it. It isn't a property of where it sits, or what a vendor's homepage claims.

What doesn't make an agent private

A few things do not, by themselves, make an agent private:

• A privacy policy promising good behaviour. Policies describe intent, not what the software can technically do.
• A "we don't train on your data" line from the model provider. One link in a longer chain, more on that below.
• Running on your own servers. Self-hosted software can log everything to a world-readable bucket just as easily as hosted software can.
• The word "private" sitting in the product name.

What actually determines it

What determines it is four boundaries, what Commt calls an agent's reach, each controllable on its own. That's what the agent knows, what it can do, what it can reach over the network, and what gets kept afterward. A platform can get any one of these wrong while nailing the other three, so all four need checking, not just the one a vendor happens to lead with.

What are the four boundaries that define a private AI agent?

Four things, each worth checking independently, because getting three right and one wrong still leaves a hole.

Knowledge. Which documents, databases, or knowledge bases can the agent actually read? A private agent's knowledge is limited to what's explicitly bound to it, agent by agent, rather than a shared pool everyone on the account can query by default. Retrieval-augmented generation (RAG) is one way to give an agent knowledge, but it's optional. An agent with no knowledge base attached can still be private, depending on the other three boundaries.

Tools. What can the agent do, beyond generating text? Every connector, API, or function call available to an agent is a door out of the conversation. It's often a door into another system too: a CRM, a ticket queue, a shared drive. Many of these tools reach an agent through MCP, the Model Context Protocol. MCP is an open standard that lets an agent discover and call tools and services, with no custom integration needed for each one.

A private agent's tool list is a scoped allowlist someone deliberately chose, not "everything the platform happens to support." Ask what's on that list and who set it.

Network. Where can requests originate from the agent, and where can they go? This is the boundary people get wrong most often, usually by assuming that turning off browsing turns off the network entirely. An agent whose toolset lacks a general-purpose web-browsing or web-search tool cannot fetch arbitrary URLs on its own initiative.

That's different from having zero outbound calls: a connector to Slack or Jira does make an outbound call, on purpose, to the one system it was wired to reach. The useful version of this boundary is "the agent can only talk to what it was told to talk to," not "the agent can't talk to anything."

Retention. What gets kept after the conversation ends, and for how long? This covers message content, but also the less visible stuff: request logs, execution traces, tool-call records, and anything an observability layer captures on the side. Execution traces are the step-by-step record of what an agent did, including its tool calls.

A private agent's retention is something the customer sets, rather than something the platform defaults to "forever, for troubleshooting." Deletion should mean the record is gone or irreversibly anonymised, rather than soft-deleted and still sitting in a backup someone can restore.

Private AI agents vs public AI assistants

A private AI agent and a general-purpose AI assistant differ in how deliberately their access is scoped, not in which one happens to run in the cloud.

A private agent can run in the cloud, browse the web, and call outside services. What makes it private is that each of those is a deliberate, checkable setting rather than an assumption inherited from a platform's defaults. That's true whether or not it's self-hosted or cut off from the network.

Is self-hosting the same as private?

Not the same thing. Self-hosting is one way to get some of these privacy properties, and for a real subset of buyers, it's the right way. But delivering the four boundaries above still takes deliberate configuration on top of it, whichever way you host.

Self-hosting wins when the requirement is about who has physical or administrative custody of the infrastructure. That covers a government agency, a defence contractor, or a bank operating under a rule that the workload has to run inside a boundary the vendor doesn't control. If that's the actual requirement, no amount of vendor promises about scoping and retention substitutes for it.

The cost side of self-hosting, for most buyers

That's a different calculation from the one facing buyers who lack a custody requirement, which is most of them. For that group, what gets underweighted is the cost on the other side. Self-hosting an agent platform means your team now owns model updates, security patching, and scaling under load. It also means building the same knowledge, tool, network, and retention controls a hosted vendor would otherwise maintain. Getting those four right is the hard part, regardless of who runs the servers.

A self-hosted deployment only stays private if someone actually staffs it, keeping its logging tight and its connector scope narrow. Skip that, and it's just as exposed as a badly run hosted setup, misconfigured somewhere your own team can't see. Most teams lack a standing platform security function. For them, a hosted vendor that publishes and enforces the four boundaries above will beat a self-hosted setup with no one dedicated to hardening it.

Does "the model doesn't train on my data" mean the agent is private?

Not by itself. A no-training commitment from a model provider covers exactly one hop: the moment your prompt reaches that specific model. It says nothing about everything else that happens to your data on the way there and back.

What sits between your message and the model

Between a user's message and a model's response there's usually a platform layer.

• Request logs and whatever the agent's tools returned.
• An orchestration or agent framework, the layer that sequences an agent's steps and tool calls, which may retain transcripts for debugging.
• Analytics or tracing systems capturing payloads for observability, meaning visibility into what the system did, used for debugging and monitoring.
• Any subprocessors sitting underneath, the other companies the vendor relies on to run parts of its service.

A no-training clause is silent on all of it. A platform can honestly say the model provider doesn't train on your data, while still storing full conversation transcripts indefinitely in its own database. It might also ship tool-call payloads to a third-party logging service, or give a wide internal team read access to customer traces.

Privacy is a property of every hop, not the last one.

Treat a no-training commitment as answering one question, not the whole audit.

9 questions to ask before choosing a private AI agent platform

Ask questions specific enough that a vendor without the right architecture can't dodge them.

• Which knowledge bases can this specific agent read, and can I see that list, not just the account-wide one?
• What tools or connectors can the agent invoke, and who chose that scope, me or your default?
• Is there a browsing or web-search tool available to agents on your platform, and if not, is that a setting or an architectural fact?
• Your connectors make outbound calls; where exactly do those calls go, and is that list fixed or something the agent decides at runtime?
• What message content do you store by default, and for how long, before I change anything?
• If I delete a conversation, is the record gone, retained and anonymised, or retained and just hidden from my dashboard?
• Where do request logs and execution traces live, and who at your company can read them?
• Does your "we don't train on customer data" statement cover your own platform logging and your subprocessors, or only the underlying model?
• If I self-host instead, what operational burden moves to my team, and have you sized it honestly?

A vendor with a genuinely private architecture can answer all nine specifically. A vendor selling "private" as a feature usually stalls around the third one.

Are private AI agents offline?

Not necessarily. A private agent can run in the cloud and still have tightly controlled access to knowledge, tools, networks and retained data. Privacy is about controlling what an agent can reach and what happens to its data, not whether it's connected to anything. A fully disconnected agent is one specific configuration, not a requirement for being private. What matters is that its network access, however much or little, was set on purpose, rather than left to a platform's default.

Are private AI agents only for enterprises?

Not just enterprises. Any business that needs control over what an AI system can reach benefits, including customer support, sales, operations and internal knowledge workflows. How much control is needed depends on the data and systems the agent touches, rather than the size of the company running it.

Key takeaways

• Private is defined by controlled access, not by where an agent runs.
• Knowledge should be scoped explicitly, agent by agent, rather than shared across an account by default.
• Tools and connectors need an explicit allowlist someone chose on purpose, not whatever a platform happens to ship.
• Network access is a deliberate, configurable setting, not a single blanket switch.
• Retention should be a policy the customer sets, with deletion meaning the record is gone or irreversibly anonymised.
• Self-hosting can help with a genuine custody requirement, but it doesn't automatically make an agent private.
• A no-training policy from a model provider covers one hop in the chain, not the whole path your data takes.

What does this look like in practice?

Commt, an AI agent platform, scopes each of the four boundaries by design:

• Knowledge. An agent reads only the knowledge bases explicitly bound to it, with RAG optional rather than assumed.
• Tools. Which tools and connectors an agent may reach is set by the customer, from a list of twenty connectors available at launch.
• Network. Web browsing and web search are available to agents, and customers can disable them when creating an agent.
• Retention. No message content is stored by default, with retention and deletion set by the customer, meaning the record is deleted or anonymised.

It's one example of applying the checklist above, not the only correct shape a private agent can take.