- ·An agent with no system access is a demo.
- ·The hard part is safe, audited read and write into core systems.
- ·Keep the connection inside the network. Never bridge core data to a public API.
- ·Scope permissions tightly: least privilege, per workflow.
Every impressive agent demo hits the same wall the moment it meets a real enterprise: the systems that hold the data are old, on-prem, and carefully guarded for good reason. SAP, Oracle, and Dynamics are the system of record, and an agent that cannot read and write to them safely is a clever toy. The interesting engineering is not the model. It is the connection.
Why integration is the real work
Reading a document is the easy half. The valuable half is doing something with the result inside the system that runs the business: matching it, posting it, updating a record, raising an exception. That means talking to enterprise software that was never designed for an AI agent, with its own permissions, its own quirks, and a change-control process that does not forgive surprises.
Reaching the systems without leaving the network
The cloud answer to this is to bridge your ERP out to a hosted service. For regulated data that is exactly the move you cannot make. The on-prem answer is to run the agent and its connectors inside the same network as the systems, so reads and writes never cross the firewall. The agent reaches SAP the way an internal application would, and the regulated data it touches never becomes someone else's traffic.
Least privilege by default
An agent should hold the narrowest set of permissions its one workflow needs, and not a single right more. If a workflow only posts approved invoices, the agent cannot delete records or read payroll, because it was never granted the access. Least privilege turns the worst-case mistake from a breach into a blocked action, and it is what lets a security team sign off on giving software any access at all.
