How should an AI agent access company data?

Your AI agent sounds impressive in a demo. Then you put it in front of a real business question — "What is the current stock level for product X?" or "Which invoices from this customer are still open?" — and it either halts, guesses, or returns an answer that was accurate three weeks ago. The problem is almost never the AI model itself. The problem is data access: how the agent reaches your company's information, how fresh that information is, and whether the access is safe enough to trust in production.

This article walks through every major method an AI agent can use to access business data, the trade-offs of each, and the governance guardrails that separate a reliable business tool from a liability.

Why does data access make or break an AI agent?

An AI language model, on its own, knows nothing about your company. It has no idea what your current order backlog looks like, which of your customers have overdue payments, or what your warehouse holds right now. Every answer it gives about your business has to come from somewhere — a tool call, a retrieved document, a database query, an API response.

When that data pipeline is fragmented — customer records in your CRM, financial data in your ERP, operational history in a FileMaker system, contracts in a SharePoint folder — the agent either works with incomplete information or you spend months building custom connectors before it can do anything useful.

The fragmentation problem compounds with staleness. An agent that was trained or loaded with a static data export from last month will confidently answer questions about a reality that no longer exists. A sales manager asks: "Is customer Van der Berg still within their credit limit?" The agent says yes — because the export it was given didn't include the three invoices raised last Tuesday.

Reliable AI agents need live, governed, scoped access to your actual systems. Not a copy. Not a dump. The real thing — through the right interfaces.

What are the main ways an AI agent can access company data?

There is no single right answer. Most production AI deployments use a combination of these methods, each suited to a different type of data or query.

1. REST APIs — the standard workhorse

For most modern business systems, a REST API is the cleanest way for an AI agent to request data. The agent sends a structured HTTP request, the system returns a JSON or XML response, and the agent uses that to formulate its answer or take its next action.

A concrete example: a customer service agent needs to check the status of an order. Rather than having access to the entire database, it calls GET /orders/{id} on your order management API and receives exactly what it needs — no more.

Why this matters: REST APIs let you scope access tightly. You expose only the endpoints the agent needs. You add authentication (OAuth 2.0, API keys, JWT tokens). You log every request. You rate-limit. You version. This is far safer than giving the agent a direct database connection.

Gotcha: Many internal business systems don't have a REST API out of the box. If your data lives in a legacy ERP or a custom-built FileMaker application, you may need to build or configure one before this approach works — but that investment pays dividends beyond the AI use case.

2. FileMaker Data API — live access to operational data

If your business runs on a FileMaker platform, the FileMaker Data API is the correct way to expose that data to an AI agent. It provides token-authenticated, record-level access to your FileMaker databases over HTTPS — without the agent ever touching the underlying file directly.

A logistics company, for example, might have its entire shipment tracking and warehouse management system in FileMaker. An AI agent can call the FileMaker Data API to retrieve current shipment status, flag exceptions, or even write back a status update — all through a controlled, auditable interface.

Key point: The FileMaker Data API supports field-level filtering, which means the agent only ever sees the fields you deliberately expose. You keep sensitive fields — salary data, personal identification numbers, internal margin figures — completely invisible to the agent at the API level.

3. ERP and CRM integrations — connecting the financial backbone

For financial and customer data, your ERP (Exact Online, AFAS, SAP, Microsoft Dynamics, Netsuite) and CRM (Salesforce, HubSpot, Pipedrive) are the authoritative sources. Most enterprise-grade ERPs and CRMs now offer REST or OData APIs.

A practical scenario: an AI agent helping account managers prepare for sales calls needs to know a customer's purchase history, outstanding invoices, and credit limit. This data lives in the ERP. The agent calls the ERP's API, retrieves the specific customer record, and surfaces a pre-call summary — without anyone having to open the ERP, run a report, or copy figures into a document.

Trade-off to know: ERP APIs often return large, nested data structures. An AI agent that calls them naively will consume enormous token counts and slow down. The right approach is to build a thin middleware layer — a small service that calls the ERP, extracts only the relevant fields, and returns a lean, agent-friendly response. This middleware also becomes the place where you enforce access rules and audit logging.

4. RAG (Retrieval-Augmented Generation) — for documents and unstructured knowledge

Not all business knowledge lives in databases. Product manuals, contracts, internal procedures, support ticket histories, meeting notes — this is unstructured content that no REST API will neatly serve.

RAG (Retrieval-Augmented Generation) solves this. Documents are chunked, converted into vector embeddings, and stored in a vector database (such as Pinecone, Weaviate, pgvector, or Chroma). When the agent receives a question, it first queries the vector database for the most semantically relevant chunks, then passes those chunks as context to the language model alongside the question.

Concrete example: a technical support agent at a manufacturing firm needs to answer a question about a machine fault code. The answer is buried in a 400-page PDF service manual. RAG retrieves the relevant section in milliseconds and the agent answers accurately — without anyone having pre-indexed that specific fault code manually.

What RAG is not: RAG is not a replacement for structured data access. It is excellent for document retrieval and fuzzy, semantic questions. It is a poor fit for precise numerical queries ("What was our revenue last quarter?") — those belong in a proper database query, not a similarity search.

5. Vector databases — the memory layer

Vector databases deserve their own mention because they are increasingly used for more than document RAG. They also store agent memory: previous conversation summaries, user preferences, historical interactions, and learned patterns about a specific customer or workflow.

An AI agent handling repeat customer queries can store a vector summary of every resolved ticket. When a customer contacts again, the agent retrieves their history semantically — "last time this customer called, it was about a billing discrepancy on their quarterly invoice" — without reading through raw logs.

The key architectural decision: what goes in the vector store versus what gets queried live? Documents and historical context belong in the vector store. Current operational data (inventory levels, open orders, live account balances) should always be queried live through an API. Never embed real-time data into a vector store and expect it to stay accurate.

6. MCP (Model Context Protocol) — structured tool use at scale

MCP, introduced by Anthropic and now gaining adoption across AI frameworks, is a standardised protocol for how AI agents describe, request, and receive the results of tool calls. Think of it as a formal contract between the agent and the tools it can use — instead of each integration being ad hoc, MCP creates a consistent interface.

For a business deploying multiple AI agents across different workflows, MCP is significant because it makes tool definitions portable and inspectable. An agent built to query your CRM can describe its tools in MCP format; another agent built for HR queries can reuse the same framework. Audit logs, access scoping, and error handling become consistent across all agents rather than being reinvented each time.

Practical implication: If you are building AI agents now and expecting to scale to multiple agents or multiple systems within 12–18 months, designing your integrations to be MCP-compatible from the start is worth the upfront investment. It reduces the fragmentation problem at the architectural level.

7. Webhooks — pushing data to the agent in real time

So far, the methods above are all pull: the agent asks for data when it needs it. Webhooks reverse that flow — push: your system sends a notification to the agent when something happens.

Example: a purchase order is approved in the ERP. The ERP fires a webhook to the AI agent's endpoint. The agent receives the event, looks up the supplier's delivery lead times via the supplier API, checks the current warehouse level via the warehouse API, and automatically creates a follow-up task — all without anyone triggering it manually.

Webhooks are the foundation of event-driven AI agents: agents that react to business events rather than waiting for a human to ask a question. They require careful design (idempotency, retry logic, authentication of the incoming payload) but unlock genuinely autonomous workflows.

How should access be governed and secured?

Giving an AI agent access to company data without governance is like handing a contractor a master key to every room in the building. The technical question of how the agent accesses data and the governance question of what it is allowed to access are equally important.

Role-based access control (RBAC) for agents

AI agents should be granted the minimum access required to perform their defined function — nothing more. This is the principle of least privilege, applied to agents.

In practice:

• An agent that answers customer service queries needs read access to order records and customer profiles. It does not need access to payroll, internal financial reports, or other customers' data.
• An agent that processes purchase approvals needs write access to a specific workflow table. It does not need write access to the product catalogue or the user account table.

Implement this by creating dedicated service accounts for each agent, each with scoped API credentials. Never give an agent a human user's credentials. Never share credentials between agents with different access needs.

Audit logging — every call, every time

Every data request made by an AI agent should be logged: timestamp, agent identity, endpoint called, parameters passed, data returned (or a hash of it), and whether the request succeeded. This is not optional — it is the baseline for debugging, compliance, and incident response.

When something goes wrong (and eventually it will), you want to be able to answer: "What did the agent access? What did it see? What did it write?"

Data masking and field-level filtering

Do not rely solely on RBAC at the API level. Apply data masking at the field level for sensitive data — personal identification numbers, IBAN details, medical records, salary bands. Even if an agent is authorised to query a customer record, it does not need to see the raw IBAN unless it is specifically performing a payment task.

Build masking into the middleware or API layer, not into the agent's prompt. An instruction like "don't mention the customer's ID number" in a system prompt is not a security control — it is a guideline the model may or may not follow consistently.

Compliance and data residency

For businesses operating under GDPR, NEN 7510, ISO 27001, or sector-specific regulations, the question of where data goes when an AI agent processes it matters enormously. If your agent calls an external LLM API (OpenAI, Anthropic, Google), the data you pass in the context window leaves your infrastructure — at least temporarily.

Options to manage this:

• Use a self-hosted or private deployment of the language model (e.g. Azure OpenAI with your own tenant, or a locally hosted open model).
• Implement data minimisation: pass only the minimum necessary context — identifiers, not raw personal data — and resolve the full record on your own infrastructure after the agent's response.
• Review your LLM provider's data processing agreement (DPA) and ensure it covers your obligations to data subjects.

What is the right architecture in practice?

For most mid-size businesses, the most robust pattern is:

1. AI agent (the reasoning layer — GPT-4o, Claude, Gemini, or an open model)
2. → calls tool functions defined via MCP or a function-calling framework
3. → tool functions hit a middleware/API gateway (your own controlled service)
4. → the gateway enforces RBAC, audit logging, and data masking
5. → the gateway calls the source systems (FileMaker Data API, ERP API, CRM API, vector database)
6. → results flow back up the chain to the agent

The agent never has a direct database connection. It never holds credentials to source systems. It only knows that it can call specific, named tools — and the rest of the access stack is invisible to it.

This architecture also means that if you switch the underlying language model (a near-certainty over a multi-year horizon), your entire data access layer is untouched. You swap the reasoning layer; everything below it stays the same.

Step-by-step: setting up governed data access for an AI agent

1. Map your data sources. List every system the agent will need to query: ERP, CRM, FileMaker, document stores, legacy databases. For each, note whether an API already exists or needs to be built.
2. Define the agent's minimum data scope. For each data source, specify exactly which records, fields, and operations (read/write) the agent requires. Reject everything else.
3. Create dedicated service accounts. One service account per agent, with scoped credentials. Document who owns each account and when credentials rotate.
4. Build or configure the API/middleware layer. This is where RBAC, field masking, and audit logging live. Do not skip this layer to save time — it is the control plane for everything.
5. Add RAG for unstructured content. Identify document types the agent needs to reference. Set up a chunking and embedding pipeline. Choose a vector store. Define a refresh schedule.
6. Implement webhook listeners for event-driven tasks. For any workflow where the agent should react to a business event (not just answer a question), set up webhook endpoints with proper authentication and retry handling.
7. Test with adversarial queries. Ask the agent questions it should not be able to answer — e.g. data from another customer, salary information, restricted financial fields. Verify it returns nothing, not a guess.
8. Review audit logs regularly. Set up alerts for unusual patterns: unexpectedly high request volumes, failed authentication attempts, queries for fields outside the agent's normal scope.

Checklist: is your AI agent's data access production-ready?

• Every data source has an API or middleware interface — no direct database connections
• The agent uses a dedicated service account with scoped, rotatable credentials
• RBAC is enforced at the API/middleware layer, not only in the prompt
• Sensitive fields (IBAN, BSN, salary, medical data) are masked or excluded at the API level
• Every agent request is logged with timestamp, identity, endpoint, and parameters
• RAG pipeline has a defined document refresh schedule — stale embeddings are identified and updated
• Webhook endpoints authenticate incoming payloads and handle retries idempotently
• LLM provider DPA has been reviewed for GDPR/NEN 7510 compliance
• Adversarial access tests have been run and passed
• A named owner exists for each service account and integration

FAQ

Can't we just give the AI agent read-only access to the database directly? Technically possible, but strongly inadvisable. Direct database access bypasses every governance layer — there is no audit log, no field-level masking, no rate limiting, and no way to scope queries to specific record sets. A single poorly formed query can return thousands of records the agent was never meant to see. An API layer costs time upfront but eliminates a category of risk entirely.

How do we handle data that changes constantly, like inventory levels? Always query live via API — never cache this in a vector store or static context. Build your middleware to call the source system at query time and return a fresh result. Accept that this adds latency (typically 100–500ms) and design your agent's UX accordingly.

What if our ERP or CRM doesn't have a good API? This is more common than vendors admit. Options in order of preference: (1) use the vendor's official API even if limited; (2) use an integration platform (Make, n8n, Zapier for simpler cases) to expose a clean endpoint; (3) build a scheduled sync to a structured intermediate store that does have an API. Direct database polling is a last resort and requires strict controls.

How often should RAG document indexes be refreshed? Depends on how frequently source documents change. For product catalogues updated weekly, a nightly refresh is fine. For compliance documents or contracts that change rarely, a weekly or event-triggered refresh (on document upload) is sufficient. The key is having a defined, monitored process — not relying on someone remembering to update it.

Is MCP a standard we need to adopt now, or can we wait? For a single-agent, single-workflow deployment today, MCP is optional. For anything involving multiple agents, multiple tool integrations, or expected growth, adopting MCP-compatible patterns now avoids a painful migration in 18 months. The overhead is low if you build for it from the start.

What about AI agents that need to write data back, not just read it? Write access requires even tighter controls. Scope write permissions to specific tables or fields only. Require a confirmation step (human-in-the-loop) for any write that affects financial records, customer-facing data, or inventory. Log write operations with before/after values. Start with read-only agents and add write access incrementally, after the read pipeline is stable and audited.

---

Data access architecture is where most real-world AI agent projects either succeed or stall — and getting it right is as much a business governance decision as a technical one. If you're working through how to connect an AI agent to your company's systems — whether that's a FileMaker operational database, an ERP like Exact Online or AFAS, or a mix of document stores and live APIs — Loggix can help you design the access layer properly from the start: building the middleware, configuring the integrations, and making sure the agent only ever sees what it's supposed to see. Understanding how agents are structured in the first place is a useful starting point if you're still mapping out the broader picture.