Who Can See What? A Plain-English Guide to AI Permissions and Customer Data

Yesterday we talked about AI safety in broad terms.

Today, let’s zoom in on one question that deserves its own discussion:

Who can see what?

That sounds like an IT question.

It is really a business question.

Because once you start connecting AI to email, calendars, files, customer records, call transcripts, CRMs, and internal documents, the AI may become useful precisely because it can access information.

And that creates a new responsibility.

You need to decide how much access it actually needs.

Not:

“What can we connect?”

But:

“What should we connect?”

Those are very different questions.

Start with a simple example

Imagine you want an AI assistant to help your sales team prepare for customer calls.

The useful version might need access to:

• the customer’s contact information,
• recent CRM notes,
• prior sales conversations,
• the current opportunity,
• and upcoming appointment details.

That makes sense.

But suppose the setup screen also offers:

Connect your entire Google Drive

Connect every company inbox

Connect accounting

Connect HR documents

Connect all customer records

More access might make the system look more powerful.

It does not necessarily make it better.

If the assistant only needs sales information, giving it access to payroll files does nothing useful.

It simply expands what the system can see.

A good rule is:

Access should have a reason.

If you cannot explain why the AI needs something, it probably should not have it.

Think in rooms, not buildings

Picture your company’s information like an office building.

You probably would not give every employee a master key that opens:

• the owner’s office,
• accounting,
• HR files,
• the server room,
• the supply closet,
• and every customer file.

Instead, people get access to the rooms they need.

Your AI systems should work the same way.

A customer-service assistant may need customer-service information.

A sales assistant may need sales information.

An accounting automation may need invoice information.

None of those automatically needs access to everything else.

This idea has a name in security:

least privilege.

In plain English:

Give a person or system the minimum access needed to do its job.

Permission is not the same as capability

This distinction matters.

A tool may be capable of reading:

• your inbox,
• your calendar,
• your contacts,
• your cloud drive,
• and your CRM.

That does not mean you should enable all five.

Software companies often make integrations easy.

Click a button.

Sign in.

Approve access.

Done.

That convenience can make it easy to skip the most important question:

What exactly did I just approve?

Before connecting a business system to an AI tool, slow down long enough to read the permission screen.

You do not need to be a cybersecurity expert.

Look for plain questions:

• Can it read data?
• Can it create data?
• Can it edit data?
• Can it delete data?
• Can it send messages?
• Can it act as me?

Those are meaningful differences.

An AI tool that can read your calendar is different from one that can create and cancel appointments.

A tool that can draft an email is different from one that can automatically send it.

A tool that can inspect CRM records is different from one that can change them.

The more powerful the permission, the more deliberately you should grant it.

Read access and action access are not the same

Here is a useful way to divide permissions.

Each step increases the consequence of a mistake.

That does not mean you should never give AI action permissions.

It means action permissions deserve more thought than read permissions.

For a first version, you might use:

AI reads → AI recommends → Human acts

Later, if the workflow proves reliable, you may decide to automate more.

Not every employee should see every AI conversation

There is another side to permissions.

It is not only what the AI can see.

It is what employees using the AI can see.

Imagine you build an internal AI assistant connected to company documents.

An employee asks:

“What is our vacation policy?”

Fine.

Then:

“What is everyone’s salary?”

If the AI has access to a compensation spreadsheet and the employee does not normally have access to that file, you have a permissions problem.

AI should not become a shortcut around your existing access rules.

A useful principle:

If an employee should not be able to open the source document, they generally should not be able to retrieve its contents through AI either.

The interface changed.

The underlying permissions should not disappear.

Separate customer data by purpose

Customer data is another area where businesses can accidentally collect or expose more than they need.

Imagine an AI assistant helping schedule service appointments.

It may reasonably need:

• customer name,
• phone number,
• service address,
• appointment availability,
• and perhaps basic service details.

It probably does not need:

• unrelated payment information,
• old internal employee notes,
• every file the company has ever stored about the customer,
• or information from unrelated departments.

Ask:

What is the purpose of this workflow?

Then give the system information that supports that purpose.

This is a much better approach than dumping everything into one giant data pool because “AI works better with more context.”

Sometimes more context helps.

Sometimes it creates noise.

And sometimes it exposes information the system never needed.

Use three data buckets

You can make this very simple.

For AI purposes, think about company information in three buckets.

The exact buckets will depend on your company.

The point is to stop treating all data as if it carries the same risk.

The “Would I hand this employee the folder?” test

Here is a useful shortcut.

When deciding whether to connect an AI system to a source, imagine the AI were a human employee.

Would you hand that employee the entire folder?

Suppose the job is:

Schedule appointments.

Would you give the scheduler access to every employee’s tax paperwork?

No.

Then the scheduling AI probably does not need it either.

Suppose the job is:

Prepare sales-call briefs.

Would you give the salesperson the customer’s CRM history?

Probably.

That permission makes more sense.

Thinking about AI as a job role can make access decisions much easier.

Be careful with shared accounts

Small businesses often use shared logins because they are convenient.

Everybody knows the password.

Everybody uses the same account.

Nobody is completely sure who changed what.

AI makes that model even harder to manage.

Whenever possible, give employees individual accounts.

That makes it easier to:

• know who has access,
• remove access when someone leaves,
• assign different permission levels,
• and investigate what happened if something goes wrong.

The same concept applies to AI platforms.

A company account with managed users is generally easier to control than five employees independently connecting random personal accounts to company information.

What happens when an employee leaves?

This is one of the simplest tests of whether your permissions are organized.

Imagine an employee gives notice tomorrow.

Could you quickly answer:

• Which AI tools do they have access to?
• Which company systems are connected?
• Which API keys or credentials do they know?
• Which shared accounts do they use?
• Which automations depend on their account?

If that feels impossible to answer, create a basic access inventory.

It can be a spreadsheet.

Include:

That is not exciting work.

It is very useful work.

Watch the service accounts too

Sometimes the person using the AI is not the one holding the permission.

An automation may use:

• an API key,
• a service account,
• an integration login,
• a CRM token,
• or another machine-to-machine credential.

Those deserve the same attention as employee accounts.

Ask:

• Who owns this credential?
• Where is it stored?
• What can it access?
• Does it still need that access?
• What happens if we need to revoke it?

Do not paste important credentials into random prompts, spreadsheets, chat threads, or public code repositories.

Treat machine credentials like passwords.

Because functionally, that is what many of them are.

Permissions should match the stage of the project

Remember the smallest useful version from a few days ago?

Apply the same thinking to permissions.

If you are testing an AI email assistant, you may not need to connect every company inbox on Day 1.

Test one inbox.

If you are building an internal knowledge assistant, you may not need the entire company file system.

Start with one approved folder.

If you are testing lead follow-up, the AI may not need permission to edit every CRM field.

Give it only the fields it needs.

Expand access when the use case earns it.

Not before.

Review the connections you already have

Here is a useful exercise that has nothing to do with buying new AI.

Open the software your business already uses.

Look for sections called:

• Connected Apps
• Integrations
• Authorized Apps
• API
• Permissions
• Third-Party Access

You may find connections you forgot existed.

Old calendar tools.

Former employees.

Trial software.

Browser extensions.

Automation experiments.

Apps that made sense two years ago but are no longer used.

If something no longer has a business purpose, remove the connection.

Good permission management is not only about deciding what gets access.

It is also about removing access that is no longer needed.

Ask vendors better questions

When evaluating an AI product, do not only ask:

“What can it do?”

Also ask:

“What does it need access to?”

Useful questions include:

• What systems does it connect to?
• Can permissions be limited?
• Can access differ by employee?
• Can we restrict which folders or records it sees?
• Can we disable automatic actions?
• Can we remove our connection later?
• What happens to our data if we stop using the service?
• Does it keep activity logs?
• What security and privacy documentation does the vendor provide?

You may need additional questions depending on your industry, customers, contracts, and legal obligations.

The important part is recognizing that permissions belong in the buying decision.

Give customers fewer surprises

Permissions also connect to trust.

If your business begins using AI inside customer-facing processes, think about what customers would reasonably expect.

For example:

A customer who submits a service request expects you to use that information to handle the service request.

They may be less comfortable discovering that unrelated sensitive information was fed into five different AI tools for no clear reason.

You do not need to turn every interaction into a legal seminar.

But use customer information for legitimate business purposes, understand the tools processing it, and make sure your privacy practices accurately reflect what your business does.

If your industry has special legal or contractual requirements, get the appropriate professional guidance rather than assuming a general-purpose AI workflow automatically complies.

A practical permission ladder

When you build a new AI workflow, try moving up this ladder only as needed.

You do not need to start at Level 5 just because the technology supports it.

Start where the business value exists.

Move upward deliberately.

The 10-minute permission audit

Pick one AI workflow your business currently uses or wants to use.

Write down:

If you can answer those questions clearly, you are already ahead of the “connect everything and hope” approach.

Good AI does not need unlimited access

There is a temptation to believe that giving AI more data will always make it smarter.

Sometimes additional context absolutely helps.

But useful context and unlimited access are not the same thing.

The best AI workflow is not necessarily the one that knows everything about your company.

It is the one that has the right information to do a clearly defined job.

Give sales AI the sales information it needs.

Give scheduling AI the scheduling information it needs.

Give customer-service AI the information it needs to serve customers.

Keep unrelated information outside the workflow.

Give people access based on their role.

Remove old permissions.

Keep important actions behind human approval until you have a reason to automate them.

And always be able to answer:

Who can see what?

That single question will prevent a lot of unnecessary risk as your AI systems become more capable.