On-Premise AI Agents: What Changes Air-Gapped?

On-premise AI agents are tool-using LLM systems that reason, call functions, and take actions entirely inside your own infrastructure, with no dependency on a hosted model or an external API. Running an agent air-gapped changes four things a read-only assistant never has to solve: the tool-call boundary (what the agent may reach), action approval (which steps a human must confirm), sandboxing (how tool execution is contained), and observability (how you audit what the agent actually did). This page explains what an on-premise AI agent is, how air-gapping reshapes each of those four controls, and how to deploy one so its blast radius stays bounded. It is general engineering guidance, not legal advice.

What is an on-premise AI agent?

An on-premise AI agent is an LLM that runs in a loop of reason, act, and observe: it decides on a step, calls a tool to perform it, reads the result, and continues until the task is done, with the model and every tool hosted inside infrastructure you control. The difference from a plain retrieval assistant is the ability to act. A RAG assistant reads your documents and returns text. An agent can also query a database, file a ticket, move a record, or trigger a workflow.

That extra capability is what raises the stakes. A RAG assistant’s worst-case failure is a wrong answer. An agent’s worst-case failure is a wrong action taken on a real system. So the core design question for on-premise AI agents is not “how smart is the model” but “what can it touch, and who confirms the risky steps.” Teclops AI builds these as custom AI agents scoped to your permission model, deployed inside the client’s own infrastructure.

What changes when an AI agent runs air-gapped?

What changes when an AI agent runs air-gapped is that every capability it uses must exist inside the isolated network, because the agent cannot reach out. A cloud agent can call a weather API, a payments provider, or a hosted search tool mid-task. An air-gapped agent has none of those escape hatches, and that constraint is a feature: it forces every tool to be a known, local, auditable service.

The shift touches four boundaries at once:

• Model serving. The reasoning model is an open-weight LLM served on local GPUs, not a hosted endpoint, so no prompt or intermediate step leaves the perimeter.
• Tool surface. Every tool the agent can invoke is an internal service. External SaaS integrations are unavailable by construction, not by policy.
• State and memory. The agent’s scratchpad, task history, and any long-term memory are stored inside the air gap, never in a vendor’s system.
• Updates. New model versions and tool code are staged, verified, and carried in through an approved transfer path, the same discipline covered in what air-gapped AI means and how it works.

How do you bound the blast radius of an on-premise agent?

You bound the blast radius of an on-premise agent by controlling the set of tools it can call, because an agent can only ever do what its tools let it do. Prompt wording is not a security boundary; the tool list is. A useful mental model: classify every tool the agent might get on four axes before you grant it.

Tool axis	Low risk	High risk
Direction	Read (query, search, summarize)	Write (create, update, delete)
Reversibility	Reversible (draft, propose)	Irreversible (send, pay, submit)
Scope	Row-level, single record	Bulk, cross-record, admin
Confirmation	Auto-execute allowed	Human approval required

The rule that follows: grant read, reversible, narrow-scope tools freely, and gate every write, irreversible, or bulk tool behind explicit human approval. This is least privilege applied to agency. An air-gapped deployment makes it enforceable, because the agent physically cannot substitute an unapproved external tool for a blocked internal one.

How does action approval work for an air-gapped agent?

Action approval for an air-gapped agent works by inserting a human-in-the-loop checkpoint between the agent’s decision and the tool actually running, for any action classified as high risk. The agent proposes the action and its arguments, a person with the right role reviews it, and only an explicit confirmation lets the tool execute. Low-risk read tools run without a prompt so the agent stays useful.

Three properties make this workable rather than a bottleneck:

1. Typed, whitelisted tools. The agent chooses from a fixed catalog of functions with validated arguments, so it cannot invent a call the system does not recognize.
2. Role-aware gating. Whether a step needs approval, and who can grant it, follows the same role and row-level permissions the rest of the stack uses. An agent acting for a user inherits that user’s limits.
3. Approval as an audit event. The confirmation, the approver, and the exact arguments are logged, so every high-risk action has a named human attached to it inside the perimeter.

How do you sandbox agent tools without cloud dependencies?

You sandbox agent tools without cloud dependencies by running each tool in an isolated local execution environment that has only the access it needs and no path to anything else. In a cloud setup, teams often lean on a managed sandbox service; air-gapped, you build the same containment from local primitives: process isolation, restricted service accounts, and network segmentation inside the air gap itself.

The controls that matter most for on-premise agent sandboxing:

• No lateral network. A tool that reads one database should not be able to reach an unrelated system, even inside the isolated zone.
• Least-privilege credentials. Each tool uses a scoped service account, so a compromised or confused agent cannot escalate.
• Input and output validation. Tool arguments are validated before execution, and tool results are treated as untrusted text, which blunts prompt-injection attempts that try to smuggle instructions through retrieved or returned content. Teclops AI covers that attack class in how to prevent prompt injection in enterprise RAG.
• Resource limits. Timeouts and rate limits cap how far a runaway loop can go before it is stopped.

How do you audit and monitor an air-gapped agent?

You audit an air-gapped agent by writing its full trace to systems inside the perimeter, where the unit of record is the tool call, not just the final answer. For an agent, the audit question is behavioral: what did it decide, what did it call, with what arguments, who approved it, and what came back. All of that must be reconstructable from local logs, because there is no external observability SaaS to fall back on.

A complete air-gapped agent trace records, per step: the model’s reasoning summary, the tool invoked, the validated arguments, the approver for gated actions, the tool result, and a timestamp, all in a tamper-evident log. This is what lets an internal reviewer answer “why did the agent do that” after the fact, and it is the same audit posture Teclops AI applies across its on-premise stack. The security and deployment approach describes the controls that back it.

Cloud agent vs on-premise agent: a deployment comparison

The table compares a hosted, cloud-connected agent against an air-gapped on-premise agent on the axes a security lead evaluates.

Property	Cloud-connected agent	Air-gapped on-prem agent
Where the model runs	Provider’s servers	Local GPUs inside the perimeter
Tool surface	Internal and external APIs	Internal services only
Data leaving the boundary	Every model call and tool hop	None
Action approval	Depends on the platform	Enforced locally, role-aware
Sandbox	Managed service	Local isolation you control
Audit trail	What the provider exposes	Full, tamper-evident, internal
Failure blast radius	As wide as connected tools	Bounded by the local tool catalog

The cloud agent reaches further with less setup. The air-gapped agent trades that reach for containment: a smaller, fully known set of things it can do, all of it visible and provable inside your walls.

Where do Teclops AI agents fit an on-premise stack?

Teclops AI builds on-premise AI agents as custom AI agents that reason, act, and integrate with your systems, scoped tightly to your processes and your permission model, and deployed inside your own infrastructure. For teams whose starting point is document question-answering rather than actions, Samvad AI provides the source-cited, permission-aware RAG layer an agent reasons over, answering only from your own documents, citing the exact passage, and writing a tamper-evident audit log, on-premise, air-gapped, or hybrid by configuration.

The right sequence is usually to prove the read-only assistant first, then add tools one at a time behind approval, widening the agent’s authority only as fast as you can audit it. If you want an agentic deployment evaluated and contained inside your own perimeter, reach the Teclops AI team at teclops.ai@gmail.com or see more on the blog.