18 min

Integrating With the Customer's Systems, Safely

Connect AI to the tools people use, with least access, real permissions and early security review.

Lesson 5 of 10

0 done

In plain English

The value appears when AI works inside the systems people already use. Map every system you touch. Ask for the least access that works. Check each person's permissions in code, not in the prompt. Start security and legal reviews in week one, because they take time.

Least access: Giving only the smallest permissions needed for the job.
Service account: A login made for software, not for a person.
MCP: A standard way for AI tools to connect to other tools and data.

Picture it

Safe connection to customer systems

Users and their permissions

Checked in code

Your solution

Service account, no secrets in prompts

Connectors

APIs or tool servers

Customer systems and data

Read-only where possible

A prototype on the side is not a solution. The value appears when the AI works inside the systems people already use. That means logins, permissions, data rules and security review. This lesson shows how to connect AI to a customer's systems without putting them at risk.

Map the systems first

List every system the solution reads from or writes to. Next to each, write the owner, the way to connect and the access level. This map becomes the center of your security conversation.

systems-map.md

SYSTEM          | OWNER      | CONNECT VIA   | READ / WRITE | DATA SENSITIVITY | APPROVAL NEEDED
Ticket tool     | IT ops     | API key       | read, add note | medium         | IT security
Customer CRM    | Sales ops  | OAuth         | read only      | high (personal)| Privacy officer
Shared drive    | Finance    | Service login | read only      | high           | Finance head
Email           | IT ops     | Shared mailbox| send drafts    | medium         | Team lead

Give the least access that works

Ask for the smallest access that does the job. Read-only where possible. A service account for the solution, not a person's login. Short-lived keys that expire. Separate keys for testing and for real use.

Never put secrets in prompts, code files or chat messages.
Keep keys in the customer's secret store.
Let the AI draft, and let a person or a fixed rule perform risky writes.
Record every action the solution takes, so you can answer who did what and when.

Respect who can see what

People in the company see different data. The solution must respect that. If it searches company documents, it should only return what the asking person may read. Pass the user's identity through, and check permissions in your code. Never trust the model to keep a secret.

⚠A single missing permission check can show one person another person's private data. Test this on purpose with two users of different rights.

Ways to connect

APIs: the usual way. Ask what the customer already exposes.
Tool servers such as MCP: a standard way to offer tools to AI. Good when the customer has several AI tools.
Automation platforms: quick for simple flows, with limits you must check.
Files and mailboxes: the fallback for old systems. Slower, but often the only option.

Where the AI runs

Some customers will not send data outside their network. Ask early. Options include a private cloud setup, a model that runs in their own cloud account, or a deployment on their own servers. Each choice affects cost, speed and which models you can use. Write the answer into the spec.

Security and procurement take time

Large organizations have reviews: security questionnaires, privacy checks, vendor approval and legal terms. These can take weeks. Start them in week one, while you prototype. Prepare short answers: what data you handle, where it goes, who can see it, how long you keep it and how you delete it.

→Keep a ready security pack: a one-page data flow diagram, a list of subprocessors, your retention rules and your incident contact. It saves days on every project.

Key takeaways

✓Map every system you touch, with the owner, the connection and the access level.
✓Ask for the least access that works: read-only, service accounts, short-lived keys and no secrets in prompts.
✓Enforce user permissions in code. Never rely on the model to keep a secret.
✓Start security and procurement reviews in week one. Prepare a standard security pack.

Hands-on exercise

Make a systems map and a security pack outline

Pick an AI project idea. List every system it would read from or write to.
For each system, fill in owner, connection, read or write, sensitivity and approver.
Mark which writes could do harm. Decide whether a person must approve each one.
Draw a simple data flow: where data starts, where the AI sees it, where results go. Write three sentences on how you delete data.

Check yourself

Q1What does least access mean?show answer

Give the solution only the smallest permissions that let it do the job, such as read-only access and short-lived keys.

Q2Why must permission checks live in code, not in the prompt?show answer

A model can be tricked or can make mistakes. Code checks cannot be argued out of their rules.

Q3Why start security review early?show answer

Reviews can take weeks. Starting in week one means you are not blocked when the prototype is ready.

← Prototyping on the Customer's Real Data Rollout, Handover & Keeping the Customer's Trust →