Connect AI to Legacy Systems Without Unrestricted Access

Connect AI to an old business system through a narrow interface that your team controls. Give that interface access to the records needed for a named task, enforce permissions before data reaches the model, and route production changes through the system's approved transaction process. You can start with a bounded read workflow even when the ERP has no modern API.

Define the task before granting access

“Connect the ERP to AI” leaves the implementation team guessing. Start with a request a staff member can recognise: explain why a customer's order hasn't shipped, using the order status and permitted warehouse records. Name the staff role, business unit, and decision the answer supports.

Write down the information the task needs. For an order enquiry, that may include the order identifier, line quantities, shipment status, and relevant hold reason. Payroll tables and supplier bank details have no role in that answer. Agree the allowed response and the next step when the required information is missing.

A May 2026 systems-administration discussion describes a request for full ERP API access even though the system has no API and its existing integrations use database connections or remote commands. It captures a practical reader concern: how to deliver an AI workflow without handing over every existing integration privilege. The thread doesn't establish how often this happens.

Separate the first release from later actions. An assistant that explains an order status can hand staff a source link and a draft response. Creating a replacement order needs its own business rules and release decision. Our guide to when an assistant should read, recommend, or act covers that operating choice.

Ask for a small written access contract. It should state the permitted population, fields, data age, and operations. The process owner signs off on what the workflow means; the source-system owner confirms what the interface can enforce. Keep that contract with the implementation so a later request for “just another field” receives a deliberate review.

Choose a connection the old system can support

Inventory the interfaces that actually exist in your installed version. Check the vendor's supported API, reporting tools, documented integration routines, and existing exports. A cloud product's current API documentation doesn't prove that your older on-premises edition has the same interface or licensing.

I would start with a vendor-supported interface that preserves the application's rules. If the task only needs a daily report, a curated export may meet the requirement with less operating work than live access. Match the connection to the task's freshness requirement and the source owner's support capacity.

A reporting view needs a maintained definition. “Available stock” may depend on allocations or holds that a raw quantity column doesn't show. Have the business reviewer compare representative results with the source application's own screen. Record the approved meaning and the situations the connector can't answer.

Keep direct database writes out of the design unless the vendor explicitly supports that integration path. An update to an order table may bypass validation or leave related records inconsistent. A supported transaction routine can enforce rules that aren't visible in the table schema.

Set a read budget with the source operator. Bound result sizes, concurrent calls, and query duration, and test the workload against a representative environment. A connector with no write permission can still overload a production database. A replica or export also needs a clear lag indicator before staff rely on its answer.

Trace the identity at every hop

Draw the request path from the staff member to the AI application, connector, and source system. For each hop, identify the account that authenticates, the permissions it has, and how the application carries the staff member's permitted scope. Network reachability alone doesn't answer those questions.

Microsoft's on-premises data gateway documentation gives a concrete example: the Windows service account that runs the gateway differs from the account used to connect to an on-premises data source. Reviewing the gateway's service identity doesn't establish the database permissions behind it. Other products have their own identity arrangements, which your team needs to inspect.

Use a dedicated connector identity for the bounded workflow where the system supports it. Give a read connector no production write grant. Keep a later approved-action component on a separate identity so an explanation task can't gain transaction privileges through a shared account.

Google Cloud's service-account guidance recommends dedicated accounts with access to necessary resources and warns about permissions that let people impersonate more privileged accounts. Its cloud-specific mechanisms don't automatically apply to an old ERP. The design question travels across systems: who can use, change, or obtain the credentials of your connector identity?

Keep credentials in the approved server-side credential store, outside prompts and browser code. Prefer supported short-lived credentials where available. If a legacy integration requires a long-lived password, assign its rotation and revocation to a named operator and test those procedures. Document the dependency so a departing employee's personal login doesn't become an invisible production requirement.

Restrict records and fields before retrieval

Read-only describes an operation, and you also need a permitted population. A sales assistant that reads every customer account can disclose confidential records without changing anything. Apply the authorised user's scope and the workflow's scope together before returning content to the model.

OWASP's 2025 Excessive Agency guidance identifies unnecessary functions, permissions, and autonomy as causes of harm. Its examples include a read tool using an identity with write privileges and a document connector accessing other users' files through a shared privileged identity. A connector needs restrictions that the downstream system or trusted application actually enforces.

For the order enquiry, the server derives the permitted customer accounts from the authenticated staff identity. It validates the requested order against that population, selects approved fields, and returns a bounded result. The model can request an order lookup, but it can't supply a different staff identity or select a broader database account.

If the old system can't enforce the required row restrictions, build a reviewed adapter or a deliberately scoped data extract. Treat that adapter as a security boundary with its own tests. Don't assume that a prompt telling the model to ignore other customers compensates for an account that can read them.

Follow the records beyond the first query. Check the search index, response cache, downloadable attachment, and diagnostic log. Test what happens when a person's access changes after an answer enters the cache. Establish how revocation and deletion reach copied data, and prevent a cached response from crossing user or company boundaries.

When definitions or ownership differ across departments, resolve that before expanding the connector. Our data ownership guide explains how teams approve shared meanings. An access decision needs an owner who understands both the sensitivity of the record and the business use.

Keep business data separate from authority

An order note or supplier attachment can contain instructions as well as facts. Treat retrieved text as input to the task. It mustn't change which tools the application offers, who the user is, or where the connector sends data. Keep those choices in trusted application configuration.

For example, an order note might tell the assistant to send the customer list to an external URL. The approved order-enquiry workflow has no customer-list export operation and no arbitrary destination tool. The application's permitted operations constrain what that text can cause, even if the model follows the instruction.

Pass only the data that the task needs. Remove unrelated fields before constructing the model context and confirm that the chosen model service fits your company's handling requirements. Don't include source-system passwords or access tokens in a tool response. Give staff a permitted source reference and freshness time with the answer.

A June 2026 preprint by Kaiyue Yang and colleagues, When Lower Privileges Suffice, studies agents choosing higher-privilege tools despite sufficient lower-privilege alternatives. The authors report that transient tool failures increase this behaviour and that prompt controls offer limited mitigation in their benchmark. This isn't a measured failure rate for your ERP; it supports testing what an agent attempts when its normal lookup fails.

Specify the fallback before release. A failed read should return a clear failure or route staff to the existing process. It mustn't unlock a general database tool, a remote command runner, or a more privileged account to rescue the answer.

Approve an exact production action

When the business case includes a write, expose a named operation with validated inputs. “Create a replacement order for this reviewed request” is a boundary your team can inspect. A generic tool that executes model-generated SQL or shell commands gives the implementation a much larger surface to control.

OWASP's AI Agent Security Cheat Sheet places authorisation outside the agent and requires approval to belong to the actor and exact tool call. It describes atomic consumption of approval and new approval when parameters change. A model-provided confirmation flag doesn't establish that a staff member approved the transaction.

Build the review screen around the actual business decision. For a replacement order, show the customer, source order, item identifiers, quantities with units, destination, and any expected charge. A reviewer needs to see what the system will submit, including consequences that a short natural-language summary can omit.

Bind the approved request to that exact payload and a limited validity period. Immediately before execution, the server checks the reviewer and current policy, then rechecks relevant source state. If the original order has already shipped or the quantity changes, stop and obtain a new decision.

Plan for an uncertain outcome. If the connection times out after submission, the ERP may have accepted the order even though the application didn't receive a response. Use a supported idempotency mechanism or transaction reference where available. Otherwise, reconcile the source state through a controlled exception process before anyone retries.

Work through an order enquiry

Consider an illustrative distributor with an older ERP and a customer-service team. A staff member asks why order 4821 hasn't shipped. The first release supports status explanations for the accounts assigned to that staff member; it doesn't create or change orders.

The application authenticates the staff member and resolves their account assignments. The connector checks that order 4821 belongs to an allowed account, then reads the approved status view using its dedicated reporting identity. It returns line quantities and the relevant hold information with a source timestamp.

The assistant explains that the order has a credit hold and links to the permitted source screen. It drafts a customer reply for staff review. The workflow doesn't expose account balances that the role can't see or offer a tool to remove the hold. A finance reviewer handles that decision through the existing process.

Now test a request for an order belonging to another customer. The connector denies the lookup before the model receives the record. Test the same identifier in an attachment link and a paginated search result so the team proves that the boundary holds across the actual interface.

If the company later adds replacement-order creation, finance and operations agree which cases qualify. The implementation adds a separate approved-action route using a supported transaction interface. The read release keeps its existing permissions. The team measures additional exception handling and support costs before deciding whether the expanded workflow earns its operating cost.

Test denials and assign operating ownership

Use an authorised test environment with representative roles and records. Alongside successful enquiries, demonstrate denied cross-customer access, a revoked account, a stale export, and an attempted write from the read component. Check bulk results and attachments, since a correct single-record lookup doesn't prove every retrieval path.

For approved actions, test changed quantities after review, expired approval, repeated submission, and a timeout with an unknown outcome. Record what the application does and what the operator must resolve. Don't conduct destructive permission tests against live customer records.

Give the source operator a way to stop the connector without stopping the ERP. Set alerts that distinguish failed authentication, policy denials, and source overload. Preserve enough restricted audit information to establish the actor, permitted operation, source reference, and outcome without copying complete sensitive records into general logs.

Assign maintenance explicitly. The source owner handles interface and schema changes; the application operator maintains the adapter and access tests; the process owner decides what staff do during failures. Our guide to AI workflow ownership after launch covers how those responsibilities fit together.

For an investor or operating partner, ask to see a permitted case and a denied case using the same deployed workflow. Ask who can revoke the connector, how long copied data stays accessible after revocation, and who pays for interface maintenance. Those demonstrations reveal operating obligations that a fluent answer alone can't show.

Release the bounded workflow when its owners can demonstrate the access contract and handle its failures. Expand it when a specific business task justifies more authority and the team can prove the new boundary. Each expansion needs its own evidence, support capacity, and measured benefit.