Learn

Local AI vs Cloud Agents: What Leaves Your Machine?

“Local AI” and “cloud agent” are useful labels, but they do not answer the question most people actually care about:

What leaves your machine, for which task, and under whose control?

A model can run in the cloud while the durable work stays local. A desktop app can open local files while sending their contents to a required cloud service. A local model can still use tools that contact the internet. The real boundary is the combination of storage, model context, tools, execution, and history.

Short answer

  • Local model: the model runs on hardware you control. This removes the cloud model call, but other network tools may still send data unless they are restricted.
  • Cloud agent: the model, execution environment, or durable workspace runs on a vendor's infrastructure. The vendor boundary is part of normal operation.
  • Local-first workbench: the durable work stays on your machine, while a cloud or local model can be selected for each task.
  • Agenaxy Vault Mode: only trusted model and tool connections are allowed; unapproved network access is blocked at the operating-system level, and blocked steps report why they stopped.

The five boundaries to inspect

1. Data at rest

Where do files, chats, rules, run history, and artifacts remain after the task is over?

This is the durable home of the work. It may be a vendor account, an office-suite tenant, a repository, or a local machine. “The file started locally” does not answer where the conversation, extracted content, and result now live.

2. Model context

What exact information is sent to the model?

A cloud model must receive some context over the network. The boundary can be broad, such as an uploaded workspace, or narrow, such as the relevant text and instructions for one assigned task. A local model receives its context on the local machine.

3. Tools and connectors

Can the agent search the web, upload a file, call an API, or use a remote connector?

Even when the model is local, a tool can send data out. A trustworthy privacy boundary therefore controls tools and destinations, not only the model name.

4. Execution

Where do scripts and commands run, and what prevents them from opening an unapproved connection?

An application setting can ask a tool not to use the network. An operating-system sandbox can enforce that restriction below the tool itself. The second is a stronger boundary because the command cannot simply ignore an application-level instruction.

5. Run history

Where is the record of plans, tool calls, file access, and outputs stored?

The audit trail can reveal as much about the work as the final file. A complete comparison includes the durable run record, not only source files and model calls.

Comparison by boundary

Pattern Durable work Model context Tools and execution Typical control point
Cloud chat assistant Vendor account Prompt, attachments, and chat context go to the vendor Vendor-managed Account and product settings
Cloud agent workspace Vendor-hosted workspace Workspace context is available to the hosted agent Vendor-hosted tools and sandboxes Workspace administrator and vendor controls
Office-embedded agent SaaS tenant Context comes from data inside the suite Suite-managed services and connectors Tenant policy
Desktop file agent Local files plus vendor session Selected file content commonly reaches a cloud model Local app plus remote model or connectors App permissions and vendor account
Local model with ordinary tools Local machine Model context stays local Network behavior depends on each tool Local configuration
Local-first workbench, Standard Local machine A cloud model gets the assigned task's context, or a local model gets it locally User-selected tools under normal permissions Per-task model and tool choices
Agenaxy Vault Mode Local machine Only an approved model connection receives task context Unapproved destinations blocked by an OS sandbox Trusted-connections allowlist

How Agenaxy draws the boundary

Standard mode

Standard mode is for everyday work. Files, chats, rules, run history, and artifacts remain on your machine. You choose a model for the task.

If you select a cloud model, Agenaxy sends the context needed for that task. It does not give the model unrelated chat history or access to the rest of your machine. If you select a local model, the model call remains local.

Standard mode is flexible by design. Network tools may be available when the task needs them and the user allows them.

Vault Mode

Vault Mode is for work that needs a stricter boundary. It changes the rule from “use the services selected for this task” to “connect only to destinations on the trusted allowlist.”

In Vault Mode:

  • Tools that send data to unapproved destinations are blocked.
  • Only approved model connections can be used.
  • Scripts and commands run in an operating-system sandbox that denies unapproved network access.
  • A blocked step fails and explains why.
  • Agenaxy never switches to an unapproved model or service automatically.

An approved model can run on the same machine or on a server you control. Pair Vault Mode with a local model when the task should remain entirely on the machine.

Read the full mechanism and its limits in What Is Vault Mode for AI Agents?.

“Task-scoped” in plain terms

Suppose a folder contains a contract, meeting notes, previous reports, and customer records. You ask a cloud model to rewrite one paragraph from the contract.

  • A broad cloud-workspace pattern may make the uploaded workspace available to the hosted agent.
  • A task-scoped pattern sends the paragraph and instructions needed for that rewrite.
  • A local-model pattern processes the paragraph on the local machine.

Task-scoped does not mean “nothing left.” It means the remote model receives a defined slice for a defined task rather than the entire working site.

Why a local model is not the whole privacy answer

A local model removes one network path: the model API call. It does not automatically control:

  • Web search queries.
  • External file uploads.
  • Remote connectors.
  • Scripts that open network connections.
  • Where chats and run history are stored.
  • Whether original files are modified.

That is why Vault Mode governs trusted connections and execution, not just model selection.

Why a cloud model is not automatically the wrong choice

A cloud model may be the best tool for a task. The meaningful questions are:

  • Did the user choose it?
  • What context did the task send?
  • Were unrelated files and chats excluded?
  • Is the call visible in the action record?
  • Can the user choose a local model or a stricter mode for another task?

Standard mode is designed for this explicit, task-scoped use. Vault Mode is available when the connection boundary matters more than access to an unapproved cloud service.

Which pattern should you choose?

Choose a cloud workspace when hosted collaboration, scheduling, and centralized administration are the priority.

Choose an office-embedded agent when the work already lives inside that suite and its tenant is the intended boundary.

Choose a desktop file agent when acting on selected local files is enough and a required cloud model is acceptable.

Choose a local model with ordinary tools when you are comfortable configuring and auditing the surrounding toolchain yourself.

Choose a local-first workbench when the durable work should stay on your machine, models should remain replaceable, and the result needs an inspectable record.

Choose Vault Mode when the work must be limited to a known set of machines and services, and a blocked connection should fail rather than be hidden.

Questions to ask any AI agent product

  1. Where are files, chats, run history, and artifacts stored after the task?
  2. What exactly is sent to a cloud model?
  3. Can I use a local model without moving the work?
  4. Which tools can connect to the network?
  5. Is the network boundary enforced by the operating system or only by an app setting?
  6. What happens when a required service is not allowed?
  7. What happens when a required model or connector is blocked?
  8. Can I inspect the plan, tool calls, and files touched?
  9. Are my original files preserved?

Key takeaways

  • “Local” and “cloud” describe components, not the complete data boundary.
  • Inspect storage, model context, tools, execution, and run history separately.
  • A local-first workbench keeps the durable working site on your machine while allowing per-task model choice.
  • Standard mode can use task-scoped cloud calls.
  • Vault Mode limits the run to trusted connections and enforces the restriction at the operating-system level.
  • A local model inside Vault Mode is the configuration where no model context needs to leave the machine.

FAQ

Does Agenaxy ever use the internet?

Yes, when a selected cloud model or allowed network tool requires it. Standard mode supports those explicit calls. Vault Mode allows only connections on its trusted allowlist.

Does a cloud model receive all my files?

No. A cloud model receives the context for the task assigned to it, not unrelated chats or the rest of the machine.

Does Vault Mode mean offline-only?

No. Vault Mode means trusted connections only. A local model works entirely on the machine; a model on an approved server you control can also be allowed.

What happens if Vault Mode blocks a required connection?

The step stops and tells you why instead of using an unapproved service.

Can a local model still leak data through a tool?

A local model alone does not stop a web search, external upload, connector, or script from using the network. Vault Mode addresses that wider boundary by blocking unapproved destinations.

Is Vault Mode a compliance certification?

No. It is a technical connection and execution boundary. Whether a workflow meets a law, contract, or internal policy still depends on the data, configuration, approved services, and the user's obligations.

Do the original files stay unchanged?

Yes. Agenaxy works on a copy of the files supplied to a chat and writes working files and artifacts separately.

Was this useful?