A 21-person AI agency in Columbus had a client access management problem that they did not know about until it exploded. Over three years of client engagements, they had given client stakeholders access to various internal systems — GitHub repositories, AWS accounts, Slack channels, Jira boards, and shared Google Drive folders. When they audited their access controls, they discovered that 47 external people from 12 different clients still had active access to their systems. Eight of those people worked for companies that were no longer active clients. Three had access to repositories containing other clients' code. One former client employee had admin-level access to an AWS account that hosted a production system for a different client.
The security implications were staggering. A disgruntled former client employee could have accessed another client's proprietary data, modified production systems, or extracted sensitive information. The compliance implications were equally severe — several of their clients required SOC 2 compliance, which mandates strict access controls. If any of those clients had audited the agency's access management, the results would have been damning.
Client access management sits at the intersection of security, compliance, client service, and operational efficiency. You need to give clients enough access to collaborate effectively and maintain visibility into their projects. You also need to control access tightly enough to protect your systems, your other clients' data, and your own intellectual property.
The Client Access Challenge
AI agency projects require extensive collaboration between your team and the client's team. This collaboration creates legitimate needs for shared access.
Common client access needs:
- Project management tools: Clients want visibility into project status, tasks, and timelines
- Code repositories: Client technical teams may need to review code, provide input, or prepare for handoff
- Cloud infrastructure: Client DevOps teams may need access to deployment environments
- Communication channels: Shared Slack channels or Teams groups for day-to-day communication
- Documentation: Shared access to project documentation, technical specs, and meeting notes
- Data platforms: Shared access to data warehouses, ML experiment tracking, or model monitoring dashboards
- Staging/demo environments: Client stakeholders need access to preview and test deliverables
Each of these access points creates a potential security exposure that must be managed.
The Access Management Framework
Principle 1 — Least Privilege
Every client user should have the minimum access necessary to perform their role in the project. A project sponsor who needs to review status reports does not need access to the code repository. A client data scientist who needs to review model performance does not need write access to the production deployment.
Principle 2 — Separation of Client Environments
Client A should never be able to access Client B's data, code, or infrastructure. This is non-negotiable. Implement hard boundaries between client environments.
Principle 3 — Time-Bounded Access
Client access should be automatically reviewed and revoked when it is no longer needed — at project completion, at phase transitions, and when client team members change roles.
Principle 4 — Auditability
Every client access grant, modification, and revocation should be logged. You should be able to answer the question "who from outside our organization has access to what" at any time.
Setting Up Client Access by System Type
Project Management Tools (Jira, Asana, Monday, ClickUp)
Access model: Create a dedicated project board or workspace for each client engagement. Invite client users to that specific board only.
Role mapping:
- Client project sponsor: Viewer access. Can see status, timelines, and high-level progress but cannot modify tasks or assignments.
- Client project contact: Commenter access. Can view tasks, add comments, and attach files but cannot create or reassign tasks.
- Client technical contributor: Editor access (limited). Can create tasks, update status, and add details within the project scope.
Do not do: Give client users access to your agency-wide workspace. Keep internal planning, resource allocation, and non-client-specific work invisible to external users.
Code Repositories (GitHub, GitLab, Bitbucket)
Access model: Create a separate repository or project group for each client engagement. Never put multiple clients' code in the same repository.
Role mapping:
- Client code reviewer: Read-only access to the repository. Can view code, create issues, and comment on pull requests.
- Client technical contributor: Write access to specific branches. Cannot push to main or production branches. Cannot modify repository settings or access controls.
- Client DevOps/handoff team: Full access granted during the handoff phase only. Tightly time-bounded.
Security controls:
- Enable branch protection on main and production branches
- Require pull request reviews for all merges
- Disable direct push access for client users
- Enable audit logging for all repository actions
- Remove client access promptly upon project completion or transfer the repository to the client's own organization
Cloud Infrastructure (AWS, GCP, Azure)
Access model: Use the multi-account strategy described in the cloud infrastructure management post. Each client project runs in its own cloud account or project. Client access is scoped to their specific account.
Role mapping:
- Client monitoring: Read-only access to CloudWatch/monitoring dashboards, billing for their project account, and deployment status. No ability to modify resources.
- Client technical review: Read-only access to infrastructure configurations, logs, and resource inventory. Used during technical reviews and handoff preparation.
- Client operations (post-handoff): Full administrative access to the project account, granted when the project is transitioning to client management.
Security controls:
- All client cloud access requires MFA
- Use IAM roles with specific policies rather than broad permissions
- Enable CloudTrail/audit logging for all client accounts
- Implement session time limits for client access
- Use temporary credentials (STS assume role) rather than permanent access keys where possible
Communication Channels (Slack, Teams)
Access model: Create dedicated shared channels for each client engagement. Do not invite clients to your internal workspace.
Options:
- Slack Connect: Create shared channels that exist in both your workspace and the client's workspace. Each party manages their own side. This is the cleanest approach for Slack.
- Dedicated guest channels: Create channels in your workspace and invite client users as guests. Guests can only see the channels they are explicitly invited to.
- Client's platform: Join the client's Slack or Teams workspace as guests. This is common for larger enterprise clients who prefer to keep communication within their own systems.
What NOT to share: Internal channels, direct messages between your team members, project management discussions, financial discussions, or discussions about other clients.
Shared Documentation (Google Drive, SharePoint, Notion, Confluence)
Access model: Create a dedicated folder or workspace for each client engagement. Share that folder with the client and nothing else.
Structure:
- Shared client folder: Contains deliverables, meeting notes, project documentation, and status reports. Visible to the client.
- Internal project folder: Contains estimates, margin analysis, internal discussions, draft deliverables, and work-in-progress documentation. NOT visible to the client.
- Agency knowledge base: Contains your frameworks, templates, and institutional knowledge. NOT visible to clients.
Access controls:
- Share at the folder level, not the file level (easier to manage)
- Use view-only access as default; grant edit access only when the client needs to contribute content
- Review sharing settings monthly to catch accidental sharing of internal documents
Data Platforms and ML Tools
Access model: Depends on the tool and use case.
Experiment tracking (MLflow, Weights & Biases, Neptune): Create a dedicated project or workspace for each client. Grant client data scientists view access to experiment results, model metrics, and training runs. Do not grant access to your agency's broader experiment library.
Data warehouses (Snowflake, BigQuery, Redshift): If you manage a data warehouse for the client, grant access through role-based access control. Client analysts get read access to curated datasets. Client data engineers may get write access to staging areas. Nobody gets admin access except your team.
Model monitoring dashboards: Provide client stakeholders with view access to dashboards showing model performance, data drift, and prediction quality. This is important for post-deployment transparency.
The Client Access Lifecycle
Onboarding — Granting Access
When: At project kickoff, after the SOW is signed.
Process:
- Client completes an access request form identifying each person who needs access, their role, and the specific systems they need
- Your team reviews the request against the project scope and least-privilege principle
- Access is provisioned using your standard role mappings
- Access confirmation is sent to the client, documenting what was granted
- Access is logged in your client access register
Access request form should capture:
- Person's name and email
- Organization and role
- Systems requested
- Access level needed (view, edit, admin)
- Justification for access
- Expected duration of access
- Client project sponsor approval
During the Project — Managing Changes
Adding new client users: Same access request form and review process. New users join the project and need system access.
Client role changes: When a client stakeholder changes roles, review and adjust their access. A project sponsor who becomes uninvolved should have access reduced or revoked.
Scope changes: When project scope changes, evaluate whether access needs change. A new workstream may require access to additional systems.
Monthly access review: Every month, review active client access for each project. Confirm that all client users with access are still involved in the project and still need the level of access they have.
Offboarding — Revoking Access
When: At project completion, within 5 business days of final deliverable acceptance.
Process:
- Generate a list of all client users with access to any system related to the project
- Revoke access from every system — code repositories, cloud accounts, project management tools, communication channels, shared documents, data platforms
- Transfer ownership of any assets the client should retain — repository transfer, cloud account handoff, document ownership change
- Confirm revocation through a checklist verification
- Log the offboarding in the client access register
Post-offboarding verification: One week after revocation, verify that all access has been successfully removed by attempting to access each system using a client user's credentials (or by checking access logs).
Data retention and deletion: After access is revoked, follow your data retention policy for the client's data. Delete client data per the agreed schedule and provide the client with confirmation of deletion.
The Client Access Register
Maintain a central register of all client access across all systems.
For each access grant, record:
- Client name
- Person's name and email
- System/tool name
- Access level
- Date granted
- Granted by (your team member)
- Project association
- Expected end date
- Date revoked (when applicable)
- Revoked by (your team member)
Review the register monthly during your security review. Flag any access that has exceeded its expected end date or is associated with a completed project.
Use the register during security audits to demonstrate access control compliance.
Handling Sensitive Situations
Client Requests Broader Access
Clients sometimes request access beyond what is appropriate — access to your internal tools, access to other project repositories, or admin access to production systems.
How to handle: Acknowledge the request, explain why the specific access level is not appropriate, and offer an alternative that meets their underlying need.
"I understand you want to see how the model training pipeline works. Rather than giving direct access to our internal ML infrastructure, I can provide a detailed walkthrough document and schedule a screen-sharing session where our engineer walks you through the pipeline. Would that work?"
Client Employee Departure
When a client informs you that a team member has left their organization, revoke that person's access to your systems immediately — within the same business day.
If the client does not inform you (which is common), your monthly access review should catch it. Ask your client contact during monthly reviews: "Are all the people on our access list still involved in the project?"
Regulatory or Compliance Audit
If a client's auditor or regulator requests information about your access controls, you need to be able to respond promptly and completely.
Prepare for audits by maintaining:
- Current access register (who has access to what)
- Access control policies (how access is granted, reviewed, and revoked)
- Access audit logs (when was access granted, by whom, with what justification)
- Security incident records (any access-related incidents and their resolution)
Data Breach or Security Incident Involving Client Access
If you detect unauthorized access through a client credential or a client account compromise, activate your incident response plan immediately.
- Revoke the compromised access immediately
- Investigate the scope of the breach — what data was accessed, when, by whom
- Notify the client promptly per your contractual obligations (typically within 24-72 hours)
- Remediate the vulnerability that allowed the breach
- Document the incident for your records and regulatory compliance
Your Next Step
Conduct a client access audit this week. Go through every system your team uses — code repositories, cloud accounts, project management tools, communication channels, shared documents — and list every external person who has access. For each person, verify that they are associated with an active project and that their access level is appropriate. Revoke access for anyone who should not have it — former client employees, people associated with completed projects, and anyone with excessive permissions. Then implement the access request form and monthly review process. These two simple practices — controlled onboarding and regular review — prevent the access sprawl that creates the security vulnerabilities described in our opening story. Client access management is not about being restrictive — it is about being deliberate. The agencies that manage access well maintain security and compliance without slowing down collaboration.