On-Prem AI Agents: How to Govern Agents You Host

Hosting AI agents on your own infrastructure solves one problem, where the data goes, and leaves the harder one untouched: what the agent is allowed to do. An agent is a model plus tools plus credentials, so the risk is set by those tools and credentials rather than by the data center. An on-prem agent with a broad service account can do more damage than a hosted one with a narrow token.

This guide covers what changes when agents run on-premises, a governance model built on identity, scope, approval and audit, the threats that matter most, and a rollout plan. It assumes you already have a model serving layer. If not, start with the self-hosted LLM stack guide.

What are on-prem AI agents?

On-prem AI agents are software agents, built on a language model that plans and calls tools, that run inside your own environment: a data center, a private cloud account or an isolated network. They read from internal systems, act on them and keep their state and logs in your infrastructure. The reasons to host them are the familiar ones: sensitive data, residency requirements, latency to internal systems, and the ability to run offline. See enclosed AI for the offline case.

If you are still deciding what an agent is, what are AI agents and AI agents versus chatbots are the starting points.

What changes when agents run on your infrastructure?

Hosting changes four things, for better and for worse.

The third and fourth rows are the trap. Proximity makes it tempting to give the agent a database account or a shell with wide rights, because it is easy. Resist that.

What threats matter most?

The OWASP Top 10 for LLM Applications 2025 is a useful checklist. It lists prompt injection as the top risk, sensitive information disclosure second, and includes excessive agency, supply chain and system prompt leakage among the ten. For agents, three dominate.

1. Prompt injection through content the agent reads. A document, email or web page contains instructions, and the agent follows them. A closed network does not stop an internal document from carrying a malicious instruction.
2. Excessive agency. The agent has more tools, more permissions or more autonomy than the task needs.
3. Over-broad data access. The agent can read everything its service account can, which may be more than the requesting user may see.

The practical principle is to contain these risks with identity, scopes and approvals, rather than relying on instructions in the prompt alone, because a prompt is advice to the model and not an enforcement mechanism. Our post on agent security risks shows what happens when you do not.

What is the governance model for an agent?

Four questions, answered for every agent before it runs.

Who is it? Give each agent its own identity, an owner, a risk level and a version. Treat it as a non-human identity with credentials that can be rotated and revoked. See non-human identity.

What can it touch? Define allowed systems, allowed actions and restricted actions. Use short-lived, narrowly scoped credentials, and for user-initiated tasks prefer the user's permissions or a strict subset.

When must a human decide? Set approval thresholds. A useful scale for controlled autonomy:

Start at L1 or L2. Move up only when the audit trail shows the agent behaves, and keep the highest levels for low-risk, reversible actions.

What gets recorded? Identity, data accessed, model used, output, tools called, policy applied, decision, approval, action and outcome. Without that chain, you cannot reconstruct an incident or answer a regulator.

What does that look like for a real agent?

Take a procurement agent as an illustration.

• Can: read approved supplier information, analyze contracts, compare pricing, prepare purchase recommendations and create draft purchase orders.
• Cannot: access unrelated employee data, approve its own high-value transaction, make payments or modify restricted records.
• Requires approval: purchases above a threshold, contractual changes and sensitive external communications.
• Records: identity, data accessed, model used, output, tools called, policy applied, decision, approval, action and outcome.

That is a short document, and writing it forces the right conversations. A Trust Profile in this spirit, with owner, risk level, approved models, data classification, permitted systems, allowed and restricted actions, approval rule, retention and audit, makes the answer inspectable. The agent governance page and governance platform page go further.

How do tools and MCP fit?

The Model Context Protocol has become a common way to connect agents to tools. It standardizes the connection, and it also standardizes the attack surface, because every MCP server is code that can read data and take actions. Vet servers like any dependency, run them with least privilege, pin versions and log every call. Our posts on MCP as an interoperability standard and MCP in hybrid integration cover the architecture, and the MCP security best practices page lists controls.

How do you monitor agents in production?

• Alert on unusual tool-call patterns, such as a sudden burst of reads or a new tool in use.
• Track cost and token use per agent, since runaway loops show up there first.
• Sample outputs for human review.
• Keep a kill switch per agent and a procedure to revoke credentials.
• Replay incidents from the audit trail.

For multi-agent setups, see behavior monitoring for agent clusters and multi-agent systems.

A rollout plan

1. Pick one narrow, reversible workflow with a clear owner.
2. Write the agent's profile: identity, scopes, approvals, records.
3. Build at L1 or L2 and log everything.
4. Red-team it: prompt injection through a document, a request that exceeds its scope, an attempt to read forbidden data.
5. Run in shadow mode, comparing its recommendations with human decisions.
6. Raise autonomy for the actions that proved safe and keep approvals for the rest.
7. Review quarterly.

Where does Swfte fit?

Swfte is designed for this pattern. Studio builds agents and workflows without code, Nexus captures every agent action, enforces policy in flight and traces each agent, identity and connection, and BuildX routes model traffic across 50+ models. Cortex places the coding agents engineers already use, such as Claude Code and Codex, under one policy and one audit trail on the desktop. For isolated infrastructure there is dedicated cloud. The agents, governance and infrastructure pages explain the architecture, and the guide to deploying an agent locally, in the cloud or hybrid shows the build side.

Swfte is designed to provide technical controls, governance mechanisms and evidence for deploying AI within your own regulatory, security and policy requirements. The exact posture depends on your use case, jurisdiction, deployment and configuration. To plan an agent deployment, contact the team.

Frequently asked questions

What are on-prem AI agents?

They are AI agents that run on infrastructure you control, reading from and acting on internal systems, with their models, state and logs kept inside your environment.

Are on-prem agents safer than hosted agents?

They keep data inside, which removes one risk. They do not remove prompt injection, excessive agency or over-broad access, and proximity to internal systems can raise the blast radius if credentials are too broad.

How much autonomy should an agent have?

Start with recommendations or approvals, and raise autonomy only for actions that are low-risk, reversible and proven in the audit trail. Keep human approval for high-value or irreversible actions.

What should we log for AI agents?

The agent's identity, the data it accessed, the model used, tools called, policies applied, approvals and the outcome. That chain lets you reconstruct decisions.

Do we need a gateway for agents?

It helps. A gateway centralizes model access, keys, routing and cost tracking, and it is a natural place to enforce data-class rules. See AI gateways.

Related: Swfte Connect is the gateway that holds provider keys and applies policy and limits to every request; see Connect security.