APIs Before Agents: Giving AI Access to Your Systems Safely

Every AI agent demo I’ve sat through this year has the same moment. The presenter types a request in plain English, and the agent looks up a customer, checks an order, drafts a reply, and updates the CRM, all in about ten seconds. The room is impressed. Then someone from IT asks the only question that matters: “What would it take to give it that kind of access to our business systems?”

For most mid-size organizations, the honest answer is “more than you think, and it’s not the AI part.” Agents don’t have magic access. They act through APIs and connectors, using an identity someone gave them, with whatever permissions that identity holds. If your systems don’t have usable APIs, the agent can’t do anything. If they do, and nobody thought about the identity and permissions, the agent can do far too much.

Why this comes before the agent project

Early AI tools were read-only by nature. You pasted text into a chat window, and you got text back. The risk was mostly about what you pasted. Agents change that. An agent that can call an API can create records, send email, change prices, or grant access, and it does so at machine speed, on the strength of instructions written in natural language that it can misread.

That means the access layer, not the model, is where your controls actually live. Choosing the smartest model doesn’t make an agent safe. Giving it a narrowly scoped identity, read-only by default, with every action logged, does.

There’s also a practical reason to sort this out first. Connecting AI to tools is getting much easier. Open standards like the Model Context Protocol (MCP) and a growing list of vendor connectors mean a motivated employee can wire an assistant into a business system in an afternoon. If IT hasn’t set the rules for how that access works, people will make up their own.

Here’s how the assessment asks the question, and the 0 to 4 ladder I score it against:

D4. Can AI tools get to your data programmatically?

0. No; data is exported by hand when needed
1. A few systems have APIs, but we don’t use them
2. Some APIs or connectors in use, built one-off
3. Most key systems are reachable through APIs or standard connectors
4. A managed integration layer with access controls covers our key systems

Level 2 is where a lot of teams sit, and it’s the riskiest place to start an agent project. One-off integrations usually mean one-off credentials: a service account created years ago by someone who has since left, with admin rights because that was quicker, and a password in a script on a file server.

The five rules I give teams before any agent gets access

1. One identity per integration. Every agent, automation, or connector gets its own service account or app registration. Never a person’s account, and never a shared “integration” account that five tools use. When something goes wrong, you need to know which integration did it, and you need to be able to turn off one without breaking the others.
2. Read-only first. Every new AI integration starts with read access. Write access is a separate request, approved separately, after the read-only version has run long enough for you to trust what it does.
3. Least privilege, scoped to the use case. If the agent needs to read open orders, it gets access to orders, not the whole ERP. Most modern APIs support scoped permissions; use them even when “full access” is easier to configure.
4. Humans approve consequential writes. Anything that moves money, changes what a customer sees, or changes who has access goes through a human approval step. The agent drafts; a person confirms.
5. Log every call. You should be able to answer “what did this integration do last Tuesday?” from logs, not from memory. If a system doesn’t log API activity, that’s a reason to keep AI read-only on it.

Identity is doing most of the work in that list, and it’s why I treat identity as the control plane for AI. The details are in identity is your AI control plane.

The asset: an AI access worksheet

Before any AI tool connects to a business system, fill in one row per system. I’d start with the systems your first use case needs, then extend it to your top ten.

• System: for example, “CRM” or “ticketing.”
• API available? Yes, no, or “yes, but only on a higher license tier.” Check the vendor’s documentation, not the sales deck.
• Authentication method: OAuth app registration, API key, or username and password. Prefer OAuth where the system supports it.
• Integration identity: the named service account or app registration this integration will use. If it doesn’t exist yet, write “to create.”
• Access needed: read, write, or both, and which objects. Be specific.
• Data sensitivity: public, internal, confidential, or regulated.
• Logging: does the system record API activity, and for how long?
• Where the secret lives: a secrets vault or managed identity, never a script, spreadsheet, or chat message.
• Business approver: the data owner who agrees this access is appropriate.

Then apply one decision rule: if any row has “regulated” sensitivity and no logging, or has no business approver, the integration stays read-only or doesn’t happen. Everything else can proceed on the five rules above.

A 30-day sequence to get from level 1 or 2 to level 3

Week 1: inventory. List your key business systems and fill in the “API available” and “authentication method” columns. This is desk research, mostly vendor documentation. You’ll find at least one system where the API needs a license upgrade; note it and move on.

Week 2: clean up existing integrations. Find every integration that already exists. Replace personal accounts and shared credentials with dedicated identities, move secrets into a vault, and remove admin rights nobody can justify. This is the unglamorous part, and it pays for itself even if you never deploy an agent.

Week 3: set the standard. Write the five rules above into a one-page integration standard. Make it the checklist for every new connector, including the ones inside SaaS products that ask for OAuth consent to your tenant.

Week 4: first governed connection. Pick the system your first AI use case needs and connect it the right way: dedicated identity, read-only, scoped, logged, approved by the data owner. That becomes the template for every connection after it.

If you’re not sure which system that is yet, the source-of-truth map will tell you which system is authoritative for the questions your use case needs to answer.

Mistakes I see at this stage

Approving OAuth consent without reading it. Many AI tools ask for tenant-wide permissions during setup. A user clicks accept, and a third-party app can now read every mailbox. Restrict who can consent to apps in your identity platform, and review the grants that already exist.

Treating an agent vendor’s connector as someone else’s problem. If a SaaS agent connects to your CRM, it does so with credentials you issued. The access is yours to govern even if the code is theirs.

Skipping logs because the pilot is small. Pilots become production quietly. Turn on logging on day one, and route it to wherever your security team already looks. More on that in observability for AI.

Building a big integration platform first. A managed integration layer is level 4, and it’s worth having eventually. You don’t need it to connect your first use case safely. The five rules and a vault get you most of the way.

Who should do this work

This sits right between infrastructure, security, and development, which is exactly why it often doesn’t get done. In most mid-size teams it lands best with whoever is already building automations, working closely with whoever owns identity. If nobody on your team builds with APIs yet, that’s a skills gap worth closing on purpose, and it’s the subject of growing one AI builder on staff.

Where does your team actually stand?

Programmatic access is one of 24 questions in the AI Readiness assessment, which covers six dimensions: data, security, infrastructure, skills, use cases, and governance. The free version is 10 questions and gives you a score in a few minutes.

Get your free AI Readiness Score →

Want to see what the full assessment covers first? Flip through a complete 38-page sample report.

Related guides

• Identity Is Your AI Control Plane: SSO, RBAC, and Access Reviews
• Where Should Your Business Data Live Before AI?
• Observability for AI: Logging What Your Assistants Do
• You Need One AI Builder on Staff. Here’s How to Grow One
• The 6-Dimension AI Readiness Framework, Explained