Connecting an AI agent to your systems: ERP, CRM, email
An agent with no access to your tools can only answer. Connected to email, the CRM or the ERP, it becomes useful, and it also becomes a new user of your information system. How you connect it decides what an error or a hijack can cause.
Published September 22, 2026
Three decisions before the first connection
Connecting an agent to a business tool means answering three questions, in this order:
- With which permissions does the agent access the tool?
- By which means: a connector supplied by the platform, an in-house API, an MCP server?
- Which operations of the tool can the agent call: read, create, update, delete?
Most incidents with connected agents come from one of these decisions being taken by default rather than chosen. This guide goes through them one by one. It complements the buying checklist in the guide enterprise agentic AI platform, which turns these points into requirements.
With which permissions: delegated or service account
This is the most structural decision, and the one most often made for convenience.
| Access mode | Principle | What it allows | What it risks |
|---|---|---|---|
| User's delegated permissions | The agent authenticates on behalf of the person, who consented to the connection | The source tool's permissions apply as they are; the log names the right person | Each user must connect their account; some older tools do not support it |
| Service account | A single technical account, often very broad, used for everyone | Quick to set up, one secret to manage | The agent sees everything; a user gets through it what they cannot open; the tool's log only shows the technical account |
| Personal API key | Each user pastes a key generated in the tool | The person's permissions, without directory integration | Keys often too broad, rarely rotated, stored without control |
The rule to remember: the agent must never be able to do what the person using it cannot do themselves. Delegated permissions, through the authorisation mechanisms most office suites and SaaS applications offer, are the default target.
A service account is not forbidden, but it should be kept for cases where the agent works on data with no individual owner, such as a product catalogue that is public within the company, and with a scope cut down to the strict minimum.
An agent shared by several users must not use the connection of the person who built it. Otherwise, every user of the agent inherits its creator's permissions.
Native connectors, in-house APIs, MCP servers
There are three technical ways to link an agent to a tool. They are not mutually exclusive.
Supplied and maintained by the platform. Operations described, authentication handled, updates tracked by the vendor.
Built by your teams for a specific business tool. Full control, but maintenance and security are yours.
An open standard for exposing tools to an agent. Fast integration, quality varying with whoever wrote it.
The Model Context Protocol (MCP) describes itself as an open standard for connecting AI applications to external systems. It genuinely simplifies integration: a tool exposed over MCP can be used by different clients. But an MCP server is still code that describes and executes actions. Before plugging one in, ask the same questions as for any third-party software:
- Who wrote it and who maintains it? A server published by the tool's vendor does not have the same standing as a personal project.
- Where does it run? A server hosted by a third party sees the data exchanged with the tool.
- What does it expose? The list of operations and their nature (read, write, execute) must be known and filterable.
- What does it tell the agent? Tool descriptions are read by the model. A modified description can steer its behaviour: a server must not be able to change its descriptions without the administrator knowing.
Expose operations, not systems
“Connecting the agent to the CRM” means nothing until the operations are chosen. A CRM exposes dozens of actions; an agent preparing sales meetings uses three. Every unnecessary operation widens what an error can cause.
| Tool | Operations to open first | Operations to put under approval | Operations not to expose without a proven need |
|---|---|---|---|
| Read, search, prepare a draft | Send, forward | Delete, create forwarding rules | |
| Calendar | Check availability | Create or change a meeting | Delete other people's events |
| Documents, file sharing | Search, read | Create, edit a document | Delete, change sharing rights |
| CRM | Look up accounts and contacts | Create an opportunity, update a record | Delete, bulk export |
| ERP | Look up orders, stock, invoices | Create an order, change an entry | Approve a payment, change master data |
| Ticketing | Read, search, comment | Change a status, reassign | Bulk close, delete |
The third column relies on human approval: the agent prepares, a person confirms while seeing the exact action. The fourth is not a permanent ban, but an opening to be justified case by case.
Risks specific to connecting an agent
The OWASP list of LLM application risks groups under the name “excessive agency” the damage caused by an agent with too much functionality, too many permissions or too much autonomy. Applied to connections, that gives four concrete risks.
Injection through content read
An agent that reads emails, tickets or web pages also reads what a third party wrote there. An instruction hidden in a message can try to make it forward documents or change a record. The defence does not rely on the model: it relies on limited permissions and on approval of actions that write or send.
Leaks through a sending tool
An agent that can both read sensitive documents and send messages outside combines the two conditions for a leak. Splitting those capabilities across agents, or putting every outbound send under approval, breaks the chain.
Data sent to the model
Everything the agent reads in your tools goes to the model doing the reasoning. If that model is hosted by an external provider, the CRM extract or the email read leaves your perimeter. The choice of model is therefore part of the connection choice.
Connection secrets
Access tokens, API keys, service accounts: they must be stored encrypted, never exposed to the model, and revoked automatically when a user leaves or a connection is removed.
Frequently asked questions
Should the ERP be opened to an agent from day one?
Rarely. The ERP carries financial and accounting effects that are hard to undo. Start with tools where the agent reads and prepares (email, documents, tickets), measure the quality of its proposals, then open the ERP read-only before any write.
Is an MCP server found online safe?
Not by default. The protocol is an exchange standard; it says nothing about the quality or intent of the code implementing it. Treat it like any software dependency: origin, where it runs, operations exposed, and the same catalogue and approval as native connectors.
How do you revoke an agent's access?
With delegated permissions, by removing the user's connection or disabling their account: the agent loses access at the same time as the person. With a service account, the secret itself must be revoked, which cuts access for every user of the agent.
Where SmartAGT fits
SmartAGT, deployed on-premise, offers connectors to Outlook, Teams, SharePoint, OneDrive, Dynamics 365, Gmail, Google Calendar, Google Drive, Jira, Confluence, GLPI and Slack, as well as MCP servers. Each connector acts with the permissions of the connected account.
Any write or execute action is paused until a person confirms it, and the decision is logged. Available connectors and those in testing are listed on the Integrations page, business use cases on the Use cases page.
