AI Agent Integrations: How They Work and How to Evaluate Them

What an AI agent integration actually does

An integration is a credentialed bridge between the agent and an external system. It typically holds an OAuth token or API key, exposes a set of operations the agent can call, and translates the agent's intent ("update the close date on this opportunity") into a specific authenticated API request.

Most integrations split into two halves, and the split matters more than anything else you will read about. The read half pulls data: account records, ticket history, calendar events, query results. The write half changes state: it creates a record, updates a field, sends an email, resolves a ticket, or triggers a workflow. Reads are reversible and low-risk. Writes are not. An agent that reads your CRM is a research assistant. An agent that writes to your CRM is doing the job.

A good integration also carries context about permissions. It should know that this particular agent, acting for this particular user or team, is allowed to read deals but not delete them, or update ticket status but not change billing. That scoping is what separates an integration you can trust in production from a generic API key that can do anything the underlying account can do.

Read vs write scopes: the line that defines risk

Every integration should be evaluated on its scopes before its features. A scope is the specific permission granted at connection time: read contacts, write deals, send messages, manage labels. OAuth providers like Salesforce, HubSpot, Google, and Slack expose granular scopes, and the difference between a safe deployment and a dangerous one is usually whether you requested the narrowest set or the broadest one.

Read scopes let an agent answer questions and assemble reports. A sales agent with read-only access to HubSpot can summarize pipeline movement every Monday and post it to Slack without ever changing a record. That is genuinely useful and carries little downside, because nothing in your system of record changes.

Write scopes are where value and risk both jump. An agent that can update Salesforce records can keep stale fields current, log activities, and move deals forward automatically. The same write scope, ungoverned, can also overwrite a rep's notes, change a forecast, or mass-update the wrong segment. This is why write access deserves least-privilege scoping, human-in-the-loop approval on sensitive actions, and a log of every change. Read more on that pattern in our piece on human-in-the-loop AI agents.

Connector vs real action: why the distinction matters

A connector is plumbing. It means the agent can authenticate to a tool and call its API. A real action means the agent can complete a unit of work end to end, with the guardrails a human operator would have. Plenty of platforms ship a long list of connectors and stop there, leaving you to wire up the actual behavior yourself.

Picture the gap concretely. A connector to Zendesk lets the agent fetch a ticket. A real action lets the agent read the ticket, check the customer's order in your database, draft a reply, route it through an approver if it touches a refund, post the response, and record what it did. The first is a building block. The second is the thing you actually wanted to buy.

When you evaluate a platform, push past the integration logo wall. Ask to see one full action run through to completion, including how a write is approved and where it is logged. If the demo only shows data flowing in, you are looking at a connector, not an agent that does work.

How OAuth and least-privilege fit together

OAuth is the standard handshake that lets an agent act in a tool without ever holding a user's password. The user authorizes the connection, the provider issues a token tied to specific scopes, and the agent uses that token to make calls. Tokens can be short-lived and revoked, which is exactly what you want for something acting on your behalf.

Least-privilege means requesting only the scopes the agent needs for its actual job, and nothing more. If a reporting agent never writes, it should connect read-only. If a support agent only works one queue, its access should be bound to that queue, not the whole help desk. Over-scoping is the most common and most dangerous integration mistake, because an over-scoped token becomes a single point of failure: if it leaks or the agent misbehaves, the blast radius is everything the token could touch.

Role-based access control sits on top of scopes. Scopes say what the connection can do at the API; RBAC says which agent, user, or team is allowed to invoke which action. Together they let you run one agent for the sales team and another for finance, each constrained to its own data, even when both connect to the same underlying CRM. For the full picture, see what RBAC for AI agents covers.

How to connect a tool safely, step by step

The sequence above is the difference between an integration you can defend in a security review and one you cannot. Each step closes a specific gap. OAuth removes shared passwords. Narrow scopes shrink the blast radius. RBAC keeps one team's agent out of another team's data. Approval gates stop irreversible writes from happening silently. Logging makes the whole thing auditable.

Skip any one of these and you create a real hole. An over-scoped token with no approval gate and no log is how an agent quietly mass-updates the wrong records and no one notices for a week. The steps are cheap to follow up front and expensive to retrofit after an incident.

A worked example: the Monday pipeline report

A RevOps manager named Priya wants pipeline hygiene handled without her chasing reps. She connects an AI agent to HubSpot with read access to deals and write access to a single custom field, plus Slack with permission to post to one channel. The Gmail connection is read-only, used only to confirm whether a contact replied.

Every Monday at 8am, the agent runs. It reads the pipeline, flags deals with no activity in 14 days, and updates the "needs attention" field on each. Because updating a field on dozens of records is a bulk write, the agent pauses and posts the proposed changes to Slack for Priya to approve. She taps approve, the writes go through, and the agent posts a clean summary to the team channel.

Two weeks later, a rep asks why a deal got flagged. Priya opens the audit log, sees the exact field change, the timestamp, and her own approval, and answers in thirty seconds. No mystery, no finger-pointing. That is what governed integrations buy you: not just the work getting done, but a clear record of how. The same pattern drives our guide to automating weekly reports with AI.

Why 3,000+ integrations only matter if they are governed

A large integration catalog is genuinely useful, but only as raw reach. Three thousand connectors means you probably will not get stuck because your niche tool is missing. It does not mean any of those connections are safe to give write access to out of the box.

Breadth becomes valuable the moment it is paired with governance. The same controls have to apply whether the agent is touching Salesforce or an obscure internal API: scoped tokens, RBAC, approvals on risky writes, and a uniform audit log. When governance is consistent across every connection, a big catalog turns into a real advantage, because you can onboard a new tool and trust it the same day.

When governance is bolted on per integration, or missing entirely, breadth becomes a liability. Each new connector is another ungoverned door. The right way to read a 3,000+ number is as a question: does the same approval, RBAC, and audit model apply to all 3,000, or only to the dozen the vendor demoed? Browse how this works across tools on our integrations page.

Common integration mistakes to avoid

Most integration trouble traces back to a handful of avoidable decisions made early, usually in the rush to get something working. These are the ones that come back to bite teams.

• Granting write scopes when the job only reads, because it was the default option, which leaves a powerful token sitting unused until something goes wrong.
• Using one shared API key across every agent and team, so you can never tell which agent made which change and you cannot revoke access narrowly.
• Treating a connector as a finished action, then discovering in production that nothing routes risky writes through a human.
• Skipping audit logs because the demo worked, which leaves you unable to answer the first hard question a customer or auditor asks.
• Over-trusting the integration count and under-testing the actual actions, so you buy reach you never validate.
• Never rotating tokens or pruning old connections, which lets dormant access pile up as quiet risk.

A decision framework for evaluating integrations

Use these rules to decide how much access to grant any given integration. They keep the easy cases easy and force a real conversation on the risky ones.

Match access to the job, not the catalog. The question is never "what can this connector do" but "what does this agent actually need to do."

• Use read-only when the agent's job is to report, summarize, or answer questions, because nothing in your system of record needs to change.
• Add scoped write access when the agent maintains data (updating fields, logging activity), and pair it with an audit log from day one.
• Require human-in-the-loop approval when a write is irreversible, customer-facing, or affects money: refunds, bulk edits, outbound sends.
• Apply RBAC the moment more than one team shares a tool, so the sales agent and the finance agent cannot reach into each other's data.
• Prefer a smaller set of governed actions over a long list of connectors when you have to choose, because governed work ships and ungoverned work stalls in review.
• Re-evaluate scopes whenever the agent's job changes, since access granted for an old task is exactly the kind of risk that lingers.

Where Onpilot fits

Onpilot treats every integration as governed by default. Agents connect to your CRM, support tools, and data sources through OAuth, request least-privilege scopes, and act under role-based access control, so a sales agent and a finance agent stay in their own lanes even on a shared system. With 3,000+ integrations available, reach is rarely the problem; the controls travel with each connection.

Crucially, Onpilot agents take real action and then deliver finished work to Slack, Teams, WhatsApp, the web, or your API, on a schedule when you want it. Sensitive writes route through human-in-the-loop approval, and every read and write lands in an audit log. The result is the thing this whole guide argues for: integrations you can actually trust with production data, because the governance is built in rather than bolted on.

If you are weighing platforms, the test is simple. Ask to see one full action, including the approval step and the log entry, end to end. That single demo tells you more than any integration count ever will.