Connecting AI Agents To Internal Systems Without Sending Data Off-Premise

Written by ARSA Writer Team



Blogs

INTEGRATION

Connecting AI Agents To Internal Systems Without Sending Data Off-Premise

A retrieval system that answers questions from your document store is a read-only problem. An agent that raises a purchase order in your ERP, closes a ticket in your service desk, or adjusts a limit in a core banking record is a write problem, and the architecture that solves the first one does very little for the second. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing cost, unclear value and inadequate risk controls (Gartner, June 2025). Most of what follows is about the third of those.

THE PROBLEM

What Changes The Moment An Agent Can Write

A retrieval pilot fails quietly. The answer is wrong, a person notices, and the document gets read by hand instead. An agent with write access to a live system fails loudly and asymmetrically: a wrong ledger entry, a credit note against the wrong customer, a ticket closed on a fault that is still open. The blast radius is set by the permissions the connector holds, and by nothing else.

Two things then follow. The first is that the credential matters more than the model. An agent holding a service account with broad ERP write scope is a broad ERP write capability regardless of how carefully it was prompted. The second is that the data path stops being a single question about inference. A retrieval query sends a document fragment somewhere. An agent working a live process sends the schema, the record contents, the intermediate reasoning, and the tool call arguments, repeatedly, across a session that can run for minutes. When that path terminates at a hosted endpoint outside your network, every one of those is an egress event.

Prompt injection is the reason this stays uncomfortable. The Cloud Security Alliance and several 2026 threat-modelling papers describe the same shape: the model decides at runtime which tool to invoke and with what arguments, so content the agent reads can steer what the agent does, and conventional perimeter controls were never designed for a decision-maker that sits inside the request path (Cloud Security Alliance, 2026). A supplier email, a PDF field, or a comment in a ticket becomes a potential instruction. You cannot prompt your way out of that. You can bound it architecturally.

ARCHITECTURE

Where The Boundary Actually Sits

There are three separate boundaries in an agent deployment, and teams routinely secure one of them and assume the other two came along.

The Inference Boundary

This is the one everybody asks about first: does the text of our records reach a third-party endpoint. Running an open-weight model on hardware you own answers it. ARSA runs inference on customer infrastructure in every product it ships, and operates no cloud inference service, so the question has one answer across the portfolio rather than one answer per product.

The Connector Boundary

The agent reaches your systems through connectors, and the Model Context Protocol has become the common way to express them. The protocol’s own authorization specification now requires clients to send an RFC 8707 resource indicator so a token is bound to the specific server it was issued for, and requires servers to validate that they are the intended audience (modelcontextprotocol.io). That closes the confused-deputy hole. It does not narrow what the underlying service account can do, which remains your job.

The Commit Boundary

This is where an agent deployment either holds or does not. Every connector ARSA builds is read-only by default, and every write is staged for explicit human approval before it commits. The agent prepares the transaction and a person commits it. There is no autonomous write mode to switch on later under delivery pressure, which is the only version of this control that survives contact with a deadline.

CONTROLS

The Questions Worth Asking Before The Build

Scope the service account to the transactions the process actually needs, then verify that scope inside the target system rather than in the agent’s instructions. Your ERP already has role-based access control; the agent should inherit a role, and contextual queries should respect the controls you already run. Keep the audit trail on the same side of the firewall as the data, because an approval log that lives with a third party is evidence you do not fully control. And decide early which processes are worth this at all: the work that pays for an agent is usually the recurring, structured, multi-system task that consumes a person’s afternoon, rather than the interesting one-off.

SPECIFICATIONS

What An On-Premise Agent Deployment Requires

Item Requirement
Inference location Customer infrastructure, or single-tenant hosting in a region you choose
Outbound connection at inference time None required; air-gapped operation supported
Minimum accelerator for a software-only node 48 GB
ARSA Sovereign 48 48 GB accelerator, 128 GB ECC memory, 8 TB storage, from $26,900
ARSA Sovereign 96 96 GB accelerator plus dedicated 24 GB document accelerator, 20 TB storage RAID 1, from $44,900
Sovereign OS, software only, per node $14,900 per year, or $39,000 perpetual plus 18% maintenance
Packaged connectors Odoo, SAP, Zoho, over Model Context Protocol
Write behaviour Read-only by default, every write staged for human approval
Model updates on a closed network Signed offline packages, transferred by your own approved media process
Feasibility assessment $4,500, two weeks, deducted from the project fee within 90 days
Pilot deployment $20,000, eight weeks, bounded scope, measured against agreed KPIs

LIMITS

What This Architecture Does Not Do

It does not give you a frontier-scale model. ARSA Sovereign runs a 27B-class open-weight vision-language model, which is capable on document extraction, structured summarisation, form generation and ERP workflow execution, and is behind a frontier hosted model on the hardest open-ended reasoning. If your requirement is maximum raw capability and your data is allowed to leave the building, a hosted API is the right answer and ARSA will say so.

It does not remove the approval queue. Staging every write means somebody reviews the transactions, and the saving comes from the preparation rather than from the sign-off. Processes with thousands of daily low-value writes are a poor fit for this pattern.

It does not make the economics automatic. Genuinely bursty, occasional workloads are cheaper in the cloud. The three reasons clients move on-premise are data residency, cost at scale and vendor deprecation risk, and if none of the three applies to you, the move is hard to justify.

It also does not solve integration by connector alone. A process that nobody can describe end to end in writing is a process an agent cannot execute, which is why ARSA charges for a feasibility assessment before anyone writes code, and why some assessments end in a documented no.

SEQUENCE

How The Work Is Staged

A problem-led engagement starts with the $4,500 feasibility assessment: an operational diagnosis, a technical feasibility judgement against your actual data and infrastructure, a cost model, and a go or no-go recommendation, delivered in two weeks. The fee is deducted from the project fee if you contract within 90 days. Pilot deployment follows at $20,000 over eight weeks on a bounded scope, and a production programme runs from $60,000. Each stage carries into the next, so nothing is rebuilt. The full engagement ladder, including the camera-led path for vision projects, is set out on the services overview.

Connectors are supported for models and hardware ARSA did not supply, which matters if you have already standardised on something. If you want to talk through a specific process before committing to an assessment, start here.

Frequently Asked Questions

Can An Agent Write To Our ERP Without A Person Approving It?

No. Connectors are read-only by default and every write is staged for explicit human approval before commit. This is architectural in everything ARSA builds, and there is no autonomous write mode available to enable.

Does Any Of Our Data Reach ARSA Or A Third Party?

No. Retrieval, inference and fine-tuning all run on infrastructure you control. Where ARSA hosts on your behalf, it is a single-tenant instance in a region you choose, and no document, query or result reaches ARSA.

Can This Run Fully Air-Gapped?

Yes. No outbound connection is required at inference time. Model updates and licence activation are delivered as signed offline packages and transferred through your own approved media process.

Will It Integrate With Systems ARSA Did Not Supply?

Yes. Model Context Protocol connectors are built for ERP, CRM, ticketing and document management systems, including where the model and the hardware came from someone else.

How Do You Limit Damage From Prompt Injection?

By bounding capability rather than by prompting. The service account is scoped to the transactions the process needs, the target system enforces its own role-based access controls, connectors are read-only by default, and every write waits for a human. An injected instruction can at worst produce a transaction a person then declines.

Which Model Do You Run, And Who Owns A Fine-Tuned One?

Open-weight models under permissive licences, selected per workload during the assessment rather than by default. Your data remains yours in every case. A model adapted exclusively on your data for your use case is typically yours to use, while the base weights stay under their original open-weight licence.

Talk To The Team That Builds These

If you have a process that spans two or three internal systems and cannot send its data to a hosted endpoint, the integration architecture is the whole project. ARSA has been building and operating production AI systems since 2018, across defence, law enforcement and industrial deployments where the system has to keep working and the data cannot leave the building.

Read the detail on LLM And AI Agent Development, then book a feasibility assessment.

EN
ENEnglishIDBahasa Indonesia