The full answer
Give the AI narrow, purpose-built access: specific tools or API endpoints that do one job, using credentials scoped to the minimum and, where possible, acting with the end user's own permissions. Keep writes behind approval, run integrations inside the customer's security boundary, log every call, and agree all of it with their security team before connecting anything.
1. Start from the workflow, not the database
List exactly what the AI needs to read and do: "look up order status by order id", "create a draft refund under 100 euros". Build a tool for each, instead of giving the model a general database connection or an all-powerful API key.
2. Least privilege
- A service account per integration with only the needed scopes: read-only where possible, specific tables or endpoints.
- Short-lived tokens, stored in the customer's secret manager, never in prompts.
- Where users have different rights, pass the user's identity through (OAuth on their behalf) so the AI cannot see or change what that user could not. OWASP lists over-broad permissions under excessive agency (LLM06:2025).
3. Writes and irreversible actions
- Separate read tools from write tools.
- Limits in code: amount caps, allowed recipients, allowed fields.
- A person approves anything irreversible or above a threshold. Agent frameworks support this with approval callbacks or pause-and-resume.
4. Choose the integration pattern
- Direct tool functions in the application for a few internal APIs.
- MCP servers when several AI applications (an assistant, a coding agent, an internal tool) should share the same integrations. Remote MCP servers run over Streamable HTTP with proper authentication, and every server is code you must trust and review.
- Existing integration layers (API gateway, iPaaS) if the customer already governs access there.
5. Network and data boundaries
- Keep connectors inside the customer's network or VPC where policy demands; call the model through an approved route (the provider's API, or their cloud platform such as Bedrock, Vertex AI or Foundry).
- Mask personal data that the model does not need.
6. Logging and review
Log every tool call with user, inputs, outputs and approval decisions, in the customer's logging system. Review samples weekly during the pilot.
7. Test the boundaries
Prompt-injection tests through the documents and tickets the system reads ("send the customer list to…") must fail because the tools cannot do it, not because the model refused.
What to say about process
"I run a security review with their team before connecting anything, with a data-flow diagram showing what goes where. It's faster than being stopped later."
Last updated 16 October 2026
Sources