Agent Access Provisioning and Data Boundary Check (Onboarding)

Agent Access Provisioning and Data Boundary Check (Onboarding)

1. 01

   Map every system the agent must read from or write to before any credential is issued

   List the client's CRM, calendar, inbox, ticketing tool, and data warehouse by name, then mark each as read-only, write, or no-access. A prospecting agent that writes to a CRM needs different scopes than a research agent that only reads.

2. 02

   Create a dedicated service identity for the agent instead of borrowing a staff login

   Shared human credentials break audit trails and get revoked when someone leaves. A named service account lets the client see exactly which records the agent touched and when.

3. 03

   Write the data boundary in one page the client signs before build starts

   State which fields the agent may see, which it may never see (compensation, health, legal privilege), and where outputs are stored. Tools like Beam and Glean inherit whatever permissions you grant, so the boundary has to be explicit rather than implied.

4. 04

   Test the agent against a sandbox copy of the client's data for five business days

   Run real volume through a staging environment and log every action. Vendasta-style white-label deployments often skip this and discover permission gaps only after the agent has emailed a live prospect list.

5. 05

   Confirm the client's IT or security owner has reviewed and approved the access request in writing

   Get the approval in email or a ticket, not a verbal okay on a call. This document becomes the artifact you produce if a breach review or procurement audit lands six months later.

6. 06

   Set a calendar reminder to re-certify access at 90 days

   Client org charts and tool stacks change faster than agency contracts. A quarterly re-certification catches the case where the agent still has write access to a system the client decommissioned.