Complete the data access matrix
You will be able to create a practical data and permission boundary for a client agent without treating security as a generic checkbox.
Good agent work is useful before it is impressive.
An agent can amplify ordinary access mistakes. If a user, workspace, integration, or tool has more access than the job needs, an error or malicious input has more room to cause harm.
Tie identity to permitted data, action, and review
The language that keeps the work clear.
How to complete the data access matrix
Map identities
List client users, internal operators, integrations, service accounts, and the agent workflow itself.
Reduce permissions
Remove broad, inherited, or unused access before the pilot begins.
Separate client environments
Avoid shared credentials, shared knowledge, or accidental cross-client lookup in white-label work.
Review and revoke
Schedule a review after launch and whenever a role, provider, or client engagement changes.
Worked case: protect data and permissions
A white-label agency operates lead workflows for three franchises. A shortcut would let one shared agent search all client notes and use one broad integration credential.
Instead, each client workspace has separate permissions, data sources, brand instructions, and review owners. The agent for one franchise cannot retrieve or act on another franchise’s records.
When an agency contractor leaves, their workspace access, integration credentials, and client support path are reviewed together. The team treats this as normal operations, not a rare security event.
Complete the working artifact
Design access around the acting identity.
The agent should not inherit a broad agency credential simply because that is convenient during development. Authenticate each user and service, authorize the exact client and resource, isolate tenants, and make sensitive access short-lived and reviewable.
- Test cross-client identifiers and indirect references.
- Separate permission to read data from permission to take action.
- Document what is retained by every model, logging, and integration provider.
Sources used for this check
Before you move on
- Create a permission list for the pilot.
- Remove one permission that is useful but not necessary.
- Write the access-removal steps for an exiting team member.
- Access follows a documented job.
- Client data and credentials are separated.
- Retention has been discussed with the client.
- A review and revocation owner exists.
Failure drill
A support agent can retrieve another client's records
The case
Search uses a shared index and filters by client name supplied in the prompt. A user asks about a similarly named company, and the agent cites a private document from another tenant.
Your call
- Where must tenant identity come from?
- Which layer enforces access before retrieval?
- What evidence would prove the fix works?
Reveal a defensible response
Response: Derive identity and tenant scope from authenticated system context, never model text. Enforce access in storage and retrieval before content reaches the model. Add cross-tenant denial tests, audit retrievals, rotate exposed credentials, and treat leaked data as an incident.
Lesson progress
Finished this lesson?
Save your place on this device so it is easy to pick up where you left off.
Not marked complete yet.