Ask what the AI can do, what it can see, where data goes and what happens when something fails. Request the exact scopes it needs, whose identity each call uses, which actions need approval, a data-flow diagram that includes model providers, retention for prompts and logs, and the behaviour when a model, tool or permission check is unavailable.
Permissions: what can the AI actually do?
"Is it secure?" invites a reassuring answer. Ask questions that need a specific one.
- Which exact scopes or API permissions do you need, and why each one? Ask to see the list before any access is granted.
- Are permissions enforced by our systems, or only described in the prompt? Instructions in a prompt are not access control.
- Does the AI act with each user's own permissions, or through a shared service account? A shared account lets a user reach, through the AI, data they could not reach directly.
- Can we block specific actions? For example, deleting records, sending external email or changing payment details.
- Which write actions need human approval, and what does the approver see?
- What happens when a user's access changes or their account is disabled? Their pending work should stop with them.
- How quickly can we revoke the integration's access entirely?
- What stops content the AI reads from instructing it to act? A retrieved email or document can carry instructions. The OWASP Gen AI Security Project ranks prompt injection first among risks for applications built on language models.
Ask them to demonstrate a refused action with a real test account, not describe one. The post on how AI agents connect securely describes the pattern a good answer follows.
Data boundaries: what can it see, and where does the data go?
Ask for a data-flow diagram of the integration, then work through it:
- What enters the AI system from ours? Whole records, or only the fields a task needs?
- What is sent to the model provider, and in which region is it processed?
- Which subprocessors can receive our data?
- Can our data be used to train or improve models? Get the answer in the contract, not the sales call.
- What is stored? Prompts, outputs, files, embeddings, traces and logs are all data stores, each with its own retention.
- How is personal data kept out of logs and traces? See keeping personal data out of AI agent logs.
- Do search and retrieval obey the same permissions as direct access? A search index built with an administrator's access will leak.
- How are tenants, business units or regions kept apart?
The post on stopping an agent reaching data it should not see goes into each of these. Our AI data boundaries, PII and access control page describes how we design them.
Fallbacks: what happens when something fails?
Every integration fails sometimes. The question is whether it fails safely. Ask the company to fill in a table like this for your workflow:
| Failure | Acceptable behaviour | Warning sign |
|---|---|---|
| Model provider unavailable or slow | Queue the work, switch to a tested alternative, or hand it to a person | Silent errors, or users left waiting with no message |
| Tool call times out | Limited retries with an idempotency key, then escalation | Unlimited retries, or retries that repeat a write |
| Permission check cannot be completed | Refuse the action and record why | Proceed and check later |
| Output fails validation | Reject it and record the case for evaluation | Pass it downstream anyway |
| Low confidence or conflicting evidence | Route to a person with the evidence attached | Pick the most likely answer and act |
| Budget or step limit reached | Stop, keep partial work, notify an owner | Keep spending |
Also ask how the integration is paused: who can do it, how fast, and what happens to work already in progress. The post on what an agent should do when a tool call fails covers the mechanics.
Which providers integrate enterprise AI agents with APIs, databases, and SaaS tools?
Three kinds of provider do this, and they leave different work to you:
- Integration platforms provide connectors to common SaaS tools and databases, and increasingly expose them as actions agents can call. They reduce plumbing, but you still decide what each action may do and who approves it.
- SaaS vendors' own agents work well inside their product. They are less suited to workflows that cross into systems the vendor does not own.
- Engineering companies build the tool contracts, adapters and approval paths in your own code, including for internal APIs and older systems no connector covers.
Many estates use more than one. Whichever you choose, ask: who writes the contract for each tool the agent can call, who enforces the permission behind it, and who fixes the adapter when a SaaS provider changes its API? If the answer to the last question is unclear, the integration will break quietly one day.
Standard protocols can help an agent discover and call tools, but they do not decide what the tools may do. The post on when an agent needs a protocol like MCP or A2A covers that choice, and our enterprise AI integration page describes how we build these connections.
Which enterprise AI integration services include monitoring, evaluation, and ongoing support?
"Ongoing support" can mean a helpdesk or it can mean someone who keeps the AI behaving well. Ask what is actually included:
- Quality monitoring, not only uptime. Are outcomes, escalations and reviewer rejections watched, or only errors and response times?
- Evaluation on every change. Does the test suite re-run when a prompt, a tool, a data source or the model changes?
- Model changes and retirements. Who notices when the provider updates or retires a model, and who re-tests? See what happens when a model is deprecated.
- Upstream changes. Who handles a SaaS API version change, an expired credential or a schema change in a source database?
- Incidents. Is there a runbook, a named responder and a pause switch?
- Cost. Is running cost tracked per task and kept within agreed limits?
- Ownership. Who is the named operator after launch? The post on who operates an AI agent after it is built describes the roles.
Our AI agent maintenance and support page sets out what we include. For questions about scope, acceptance and handover rather than the integration itself, see what to ask an AI agent vendor before signing.
Answers that should worry you
- "The model is instructed not to do that."
- "We use one service account to keep it simple."
- "Logs keep everything, for debugging."
- "It retries until it succeeds."
- "Monitoring comes in a later phase."
- "Support means you raise a ticket."
Each is a sign that the hard parts of the integration have not been designed yet. To go through these questions against your own estate, talk to CodeDTX.
Frequently asked questions
Should an AI integration use the end user's permissions or a service account?
Where possible, the end user's, carried through each call and enforced by the system being called. A shared service account lets any user reach, through the AI, whatever that account can reach. Where a service account is unavoidable, scope it to the narrowest set of operations, check the user's own entitlement before each call, and record both identities in the audit trail.
How do we stop our data being used to train AI models?
Check the terms of every model provider and subprocessor in the data flow, and choose plans or deployment options whose terms exclude training on your data. Put the commitment in your contract with the integration company as well. Then reduce what is sent in the first place: only the fields a task needs, with personal data removed or masked wherever the task allows.
What is a sensible fallback when the model provider is unavailable?
It depends on the workflow. For work that can wait, queue it and process it when the provider returns. For urgent work, switch to an alternative model that has passed the same evaluation suite, or route the task to a person with the context attached. What is never acceptable is failing silently or leaving users without a clear message.
How often should an AI integration be evaluated after go-live?
On every change that could alter behaviour: a prompt, a tool, a data source, a permission or the model itself. Between changes, monitor outcomes continuously and sample real tasks for review on a regular schedule. Add cases from production failures and reviewer rejections to the test suite, so each problem found once is checked automatically from then on.
