What Access to Give an AI Implementation Partner on Day One

Give an AI implementation partner only the access that lets them understand the work: a named contact, reviewed documents, test accounts and redacted samples. Delay anything that touches live customer data, production systems or outbound messages until the role, the approval boundary and a test are agreed. Never hand over administrator accounts, personal logins, payment authority or the power to change their own permissions.

Key takeaways

• Day one access should help the provider understand the work, not perform it: contacts, reviewed documents, sandbox accounts and redacted samples.
• Live data, write permissions and customer-facing channels wait until the role, the approval boundary and a test exist.
• Administrator accounts, personal logins, payment authority and self-granted permissions are never handed to a provider.
• Treat the provider's staff access and the agent's own access as two separate questions, and scope each one on its own.
• Keep ownership of every account, tenant and credential in your company, so that you alone can revoke access quickly.

What rule decides whether an access is granted, delayed or withheld?

Access should follow the task, not the relationship. A provider can be thoroughly trustworthy and still not need a given credential this week. The useful question is not whether you trust them but how much damage a mistake, a leaked credential or a manipulated agent could do with that access.

Three questions sort almost any request:

• What does the provider need to do in the next stretch of work, and can they do it with something narrower?
• If this credential were misused, by a person or by the agent itself, what would be affected and could it be undone?
• Can your company revoke it alone, immediately, without asking the provider for anything?

If the first answer is nothing yet, delay. If the second is customer data, money or messages that cannot be recalled, delay or withhold. If the third is no, withhold until it is yes. This is the principle of least privilege, described in detail in the OWASP Authorization Cheat Sheet, and it applies to people and software alike.

There is a second distinction that many first conversations miss. An AI engagement involves two sets of access. The first belongs to the provider's staff: the people who design, configure and maintain the system. The second belongs to the agent: the identity it uses to read documents, call tools and send messages once it is running. They have different risks and should be approved separately. A provider engineer who can read a sample folder is a different decision from an agent that can write to your CRM.

Which accesses can you grant on day one?

Day one is for understanding. The provider needs to learn how the work is done today, who owns each decision and which tools are involved. None of that requires touching live systems.

Safe to grant at the start:

• A named contact on your side, plus an escalation path, in a shared channel you control.
• Read access to process documents you have reviewed: policies, templates, price lists you are comfortable sharing, answer libraries, internal guides.
• A seat in your project tracker or ticketing tool, limited to the engagement's own board.
• A sandbox, test workspace or trial tenant for each tool the role will eventually use.
• Redacted or synthetic samples of the records the role handles, such as past requests with names and identifiers removed.
• Scheduled time with the person who does the work today.

The common thread is that every item is either reviewed by you before it is shared or isolated from production. If something is wrong with a document, you find out before it matters. If a sandbox account is compromised, nothing real is exposed.

A short review of the documents before sharing is worth the effort. Contracts with confidentiality clauses, files with personal data and old spreadsheets with forgotten columns are the usual surprises. Whoever owns the process should confirm what is in the folder, not the person who found it fastest.

Which accesses should wait, and what should trigger each one?

Most of the hard requests belong here. They are not refusals. They are accesses that become reasonable once a specific condition is met, and the condition should be written down so nobody has to negotiate it under time pressure.

• Read access to live records: after the data owner has classified the fields involved, and after you have the provider's written position on how your data is stored and whether it is used for training. The article on whether your AI provider trains on your company data covers what to get in writing.
• Write access to a low-risk system: after the agent has behaved correctly in the sandbox on realistic cases, and after the approval boundary says which actions need a human to confirm.
• Access to customer-facing channels: after the pilot users are trained, the escalation path works and you have seen how the agent handles cases it should refuse.
• Deployment rights to the production environment: after a change process exists. Who requests a change, who approves it and how it is rolled back should be agreed first. The guide to requesting and approving changes to a managed AI agent describes that process.
• Access to finance, payroll or HR systems: only if the role truly requires it, with its own approval, and usually in read-only form first.
• Broader integration scopes: after the first narrow scope has run without problems and you have reviewed what it actually did.

When a tool asks for permissions through OAuth, read the scopes on the consent screen as carefully as you would read a contract clause. The Google OAuth 2.0 documentation explains how scopes work. The practical lesson is to request the narrowest scope that lets the next step happen, then widen it deliberately. A provider that asks for full account access when a read-only scope would do is telling you something about its habits.

Triggers also tell you whether the engagement is on track. If the condition for an access never gets met, the work probably is not ready for it. That is a useful signal, and it fits the logic of proof of concept, pilot and production stages, where each stage has to prove something before the next one opens.

Which accesses should you never grant to an AI provider?

Some requests are not a matter of timing. They are structural risks, and a good provider will not push for them.

• Your administrator or owner account, in any system. Create a separate, scoped account for the provider instead.
• Personal logins or shared passwords. Every credential should belong to a named identity that can be disabled on its own.
• The ability to change their own permissions, edit audit logs or disable monitoring. Whoever does the work should not be the only one able to see or alter the record of it.
• Direct payment authority, stored payment cards or the power to approve spending. Spending limits belong in controls you own.
• Sole custody of your data or backups. If the only copy sits in an account the provider owns, you do not have a backup.
• Ownership of your domain, billing account, cloud tenant or messaging accounts. Provider staff can be guests or delegates, but the accounts stay yours. This is one of the most practical defenses against lock-in, as discussed in how to avoid AI vendor lock-in.
• Unrestricted bulk export of customer or employee data.

The same logic applies to the agent. The OWASP Top 10 for LLM Applications lists excessive agency among the main risks: an agent given more tools, more permissions or more autonomy than its task needs can be steered into harmful actions by the content it reads, such as an email or a web page carrying hidden instructions. An agent with narrow access limits what such a manipulation can achieve. An agent with broad access turns every untrusted document into a potential route to your systems.

How do you run the access conversation, step by step?

The conversation goes better when it follows a sequence instead of a long list of requests arriving by email. Use this plan before the first credential is issued.

• Ask the provider for a written access request listing each system, the level (read, write, administer), the reason and the duration. Vague requests get returned for rewriting.
• Name one person on your side who approves requests, and one who can revoke them. Often these are the same person, but both roles should be explicit.
• Sort each request into grant now, grant later or never grant, using the three questions from the first section. Write the trigger next to every item in the second group.
• Issue accounts you own: named, scoped, with expiry dates where the tool allows them, and with multi-factor authentication switched on.
• Record what was granted, to whom, when and why, in one place that both sides can read.
• Review at agreed points, and remove what is no longer used. The method in how to run a permission review for your AI agents works for provider access too.

Two habits keep the process honest. First, treat expiry as the default: temporary access that quietly becomes permanent is the most common way a tidy setup becomes an untidy one. Second, ask the provider to describe what they will do with each access, not only what they need. If the description is clear and narrow, the grant is easy. If it is hard to explain, that is the real finding.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a description of a real engagement.

A small distribution company wants an agent to draft replies to routine order enquiries. The provider sends a first request asking for administrator rights on the company email system, a full export of the customer database, login details for the accounting software and permission to send email directly to customers.

The owner sorts the list rather than accepting or rejecting it as a whole:

• Administrator rights on email: never. Instead, a scoped mailbox for the agent and a shared test inbox.
• Customer database export: later. The provider starts with a redacted sample of past enquiries. Live read access follows once the data owner has marked which fields the agent may see and the data terms are signed.
• Accounting software login: not needed for this role. Withheld, with a note to revisit only if invoice status lookups become part of the job, and then as read-only.
• Sending email directly to customers: later. The agent first drafts replies into a review queue, and an employee approves each one. Sending without review is considered only after the drafts have proven reliable against agreed criteria.

Nothing was refused out of suspicion. Each request met a trigger or a reason, and the provider could start work the same week with the documents, the sample and the sandbox. The owner also kept every account in the company's name, so revoking access later would take one action on their side.

How does Be Human handle access in a managed engagement?

Be Human starts an engagement by defining one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Access is derived from that definition: each tool gets the narrowest permission the role requires, accounts stay under the client's control, and anything that writes, sends or spends sits behind an approval boundary the client sets. Provider staff access and the agent's own access are recorded separately and reviewed as part of managed operations, alongside monitoring, integration maintenance and incident response. Changes to what the agent can do go through a controlled request and approval step rather than a quiet edit.

Frequently asked questions

Should we give a provider access to production data to speed things up? Usually not at the start. Redacted samples and a sandbox let the provider design and test the role while the data owner finishes classifying fields and the data terms are agreed. Moving to live data after those steps costs a little time early and removes a large risk.

Can the provider use their own accounts for the tools instead of ours? It is better when the accounts are yours, because ownership decides who can revoke access, retrieve data and continue the work if the relationship ends. Provider accounts may be fine for their internal tooling, but anything that holds your data, your configuration or your customers' messages should live in your tenant.

What happens to access when the engagement ends or pauses? Every credential issued to the provider should be disabled by you, and the access log should show that it was. This is far simpler when accounts are named, scoped and owned by your company from the start. Agree the offboarding steps in the contract, not at the moment of the exit.

Who inside the company should approve access requests? One accountable person, ideally the owner of the process the agent will serve, working with whoever manages your systems or security. Approval should not sit with the person who is most eager to launch. Whoever approves should also be able to revoke, so that granting and removing access are never separated.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.