Learn

What Is Vault Mode for AI Agents?

Published July 20, 2026

Vault Mode is Agenaxy's trusted-connections mode for sensitive AI work. It allows a run to use only approved model and tool destinations, while unapproved network access is blocked at the operating-system level.

If a step needs a destination outside the allowlist, it stops and tells the user why.

Short definition

Vault Mode keeps an AI agent inside a user-defined set of trusted connections and makes every other network path fail closed.

Vault Mode is not simply “offline mode” and it is not only a local-model selector. A trusted model may run:

On the same machine.
On another machine or server the user controls.

Pair Vault Mode with a local model when no model context should leave the machine. Approve a model on your own server when that server is inside the boundary you intend to trust.

Key facts

Files, chats, rules, run history, and artifacts remain on the user's machine.
Vault Mode uses an allowlist of trusted model and tool connections.
Web search, external uploads, remote connectors, and other unapproved destinations are blocked.
Scripts and commands run in an operating-system sandbox that denies unapproved network access.
A blocked step fails visibly and explains the reason.
A local model can keep the model step entirely on the machine.
An approved remote server receives the task context sent to it; Vault Mode does not label that remote call as local.

What Vault Mode controls

Model connections

Only approved model destinations can connect. The user can approve a model running on the same machine or a model endpoint on infrastructure they control. All other model connections are denied for the Vault run.

This makes model trust explicit. A model is not permitted merely because it is available in another mode or configured elsewhere.

Tools that send data out

Tools that would send information to an unapproved destination are blocked. This includes web search, external upload tools, remote connectors, and arbitrary network calls from scripts or commands.

The exact problem is broader than “which model runs?” A local model combined with an unrestricted upload tool is not a sealed workflow. Vault governs the network paths around the model as well.

Script and command execution

Scripts and commands run under an operating-system sandbox that denies network access outside the approved boundary. This is an enforcement layer below the agent's instructions.

An application prompt can ask a command not to connect. An OS sandbox can prevent the connection. Vault Mode relies on the enforceable boundary.

Failure behavior

When a step requires an unapproved destination, the correct outcome is failure, not improvisation.

The run reports that the connection is blocked. It does not:

Switch to a different cloud model.
Turn on a remote connector.
Upload the file through another tool.
Hide the blocked step behind a generic success message.

The trusted boundary is not weakened automatically just to finish the task.

Standard mode vs Vault Mode

	Standard	Vault Mode
Purpose	Everyday work with flexible model and tool choices	Sensitive work limited to trusted connections
Model selection	Cloud or local, chosen per task	Only approved model destinations
Network tools	Available under normal permissions	Unapproved destinations blocked
Script network access	Governed by the task's normal sandbox policy	Denied outside the trusted boundary at the OS level
Blocked dependency	The user can change the task configuration	The step stops and explains why
Durable work	Stored on the user's machine	Stored on the user's machine

Standard and Vault use the same local-first work surface. Vault adds the stricter connection policy.

Vault with a local model

When Vault Mode uses a model running on the same machine, the model context does not need to cross the network. Unapproved network tools and script connections are also blocked.

This is the strictest Vault configuration for a supported task:

Files and durable work stay on the machine.
The model runs on the machine.
Unapproved outbound tools cannot connect.
The action record remains attached to the run.

Whether a task can complete this way depends on the local model and local tools available. Vault does not pretend an unavailable capability exists; the step can fail and tell the user what is missing.

Vault with a model on your own server

A user may trust a model running on a server they control. Vault Mode can allow that destination while continuing to block every other model and tool connection.

This configuration is not the same as local-only execution. The context sent for the task leaves the local machine and reaches the approved server. The useful boundary is that the destination is explicit, controlled, and limited to the allowlist.

What stays on the machine

Agenaxy keeps the durable working site on the local machine:

Files supplied to the workbench.
Chats and instructions.
Rules used for the work.
Run history and the structured action record.
Produced artifacts.

Agenaxy also works on copies of files supplied to a chat, leaving the originals untouched. Vault Mode adds connection control; it does not replace the source-integrity boundary.

What can still leave

Vault Mode is intentionally precise, not absolute marketing language.

Data can leave the local machine when the user has approved a remote destination inside the Vault boundary. For example, a model on the user's own server receives the context sent for its task.

Data can also leave later through a deliberate user action outside the run, such as exporting an artifact to another service. Vault cannot govern a copy after the user intentionally moves it elsewhere.

When to use Vault Mode

Vault Mode is appropriate when:

A contract, policy, or personal decision limits which services may receive the work.
Customer exports or internal documents should be processed by a local model.
A creative archive should stay private until publication.
The user wants a known, reviewable set of model and tool destinations.
A blocked capability should stop rather than trigger an unapproved remote substitute.

Standard mode is usually the better fit when flexible web access or a cloud model is part of the intended workflow and the user accepts those explicit calls.

What Vault Mode is not

Not a claim that every task is offline

Vault can allow an approved server. Use a local model when the task must stay entirely on one machine.

Not a promise that an approved service sees nothing

A remote approved model sees the task context sent to it. The allowlist controls where a connection may go; it does not erase the data transmitted through an approved connection.

Not a substitute for reviewing the output

Vault controls the execution boundary. It does not guarantee that the model's analysis is correct.

Not a compliance certification

Vault Mode is a technical control. Compliance still depends on the selected model, approved infrastructure, configuration, data, jurisdiction, contracts, and organizational policy.

Not an automatic downgrade

If the trusted configuration cannot complete a step, Vault reports the failure. It does not quietly weaken the boundary to finish the task.

How to evaluate a trusted-connections mode

Ask these questions:

Is the boundary an allowlist or only a label?
Does it cover tools and scripts as well as models?
Is network denial enforced below the application layer?
What happens when a required connection is blocked?
Does the interface show when the strict mode is active?
Can the user distinguish a local model from an approved remote server?
Is the run record stored locally and available for review?
Are original source files preserved?

How Vault Mode fits the Agenaxy value model

Vault is one of three connected promises:

A vault you own. The durable working site remains on the local machine.
Models you choose. The model is selected per task rather than owning the workspace.
A record you can inspect. Plans, tool calls, and files touched remain attached to the run.

Source integrity is the fourth practical safeguard: files supplied to a chat are copied for the run, so the originals remain unchanged.

For the broader product category, read What Is a Local-First AI Agent Workbench?. For a neutral comparison of boundaries, read Local AI vs Cloud Agents: What Leaves Your Machine?. For concrete workflows, read Use AI on Work You Would Not Paste Into Chat.

Key takeaways

Vault Mode means trusted connections only.
It covers models, tools, connectors, scripts, and commands.
Unapproved network access is blocked at the operating-system level.
A blocked step fails and explains why.
A local model keeps the model context on the same machine.
An approved remote server still receives the context sent to it.
Vault is a technical boundary, not a compliance certification.

FAQ

Is Vault Mode the same as local-only mode?

No. Vault Mode's defining behavior is trusted connections only. This allows a model on a server you control while still blocking every unapproved destination. Pair Vault with a local model when the task should remain entirely on the machine.

Does Vault Mode require a local model?

No. A local model is the strictest option, but a model on an approved server you control can also be allowed.

Can anything connect to the public internet in Vault Mode?

Only a destination that is explicitly part of the trusted allowlist. Unapproved web search, upload, connector, model, script, and command connections are blocked.

What happens when a tool tries to connect somewhere unapproved?

The operating-system sandbox denies the connection. The step fails and reports the reason.

Will Agenaxy use another model if the approved model is unavailable?

No. Vault Mode has no silent fallback. The run reports the failure instead of switching to an unapproved service.

Does Vault Mode stop an approved remote model from seeing task context?

No. An approved remote model receives the context sent for its task. To keep model context entirely on the machine, use a local model.

Does Vault Mode protect my original files from modification?

Original-file protection is a separate Agenaxy safeguard. Files supplied to a chat are copied for the run, and working files and artifacts are written separately.

Is Vault Mode available on the public website?

No. The website explains Agenaxy and accepts private beta requests. Vault Mode is part of the desktop workbench, not a browser-based product runtime.