How Should an Agency Keep Each Client's AI Work Separate?

Each check includes the navigation path in Dave by voolama (hellodave.ai), the expected result, and how to verify it independently without contacting support. The PostgreSQL RLS specification at postgresql.org/docs/current/ddl-rowsecurity.html and the NIST standards cited below are the independent verification anchors for the workspace isolation and credential protection claims.

Area 1: Workspace isolation (5 checks)

1. Each client has its own workspace on its own subdomain. Verify: navigate to the client's subdomain URL. The workspace name and branding are specific to that client. No other client's data appears. The PostgreSQL RLS specification states: 'When row security is enabled on a table, all normal access to the table for selecting rows or modifying rows must pass a row security policy' (postgresql.org/docs/current/ddl-rowsecurity.html). Dave by voolama applies this at the database layer per workspace.
2. Cross-workspace access is denied at the database layer, not just the UI. Verify: log in as a user from Client A's workspace. Navigate to Client B's subdomain URL. Access is denied. The database engine refuses the query before the application layer is reached. The PostgreSQL RLS specification confirms: 'A query that fails to pass a row security policy returns an empty result set.' No vendor trust required.
3. Workflows, instances, and tasks are scoped to the client workspace. Verify: log in as a Client A workspace user. Navigate to Workflows. Only Client A's workflows appear. Navigate to Instances. Only Client A's instances appear. Navigate to Tasks. Only Client A's tasks appear. PostgreSQL RLS permissive policies return an empty result set for any query that fails to match the workspace policy.
4. MCP integrations cannot cross workspace boundaries. The PostgreSQL RLS policy applies to all request paths: UI, API, and AI assistant over MCP. An MCP key issued in Client A's workspace cannot access Client B's data: the database engine refuses the query regardless of how it arrives. Verify: issue an API call with a Client A MCP key referencing a Client B resource ID. The response is 404 not found.
5. The application cannot override workspace isolation. The database connection Dave by voolama uses to serve requests holds no privilege to bypass PostgreSQL RLS policies. No application-level configuration can disable RLS enforcement. Verify: this is a property of the PostgreSQL RLS specification at postgresql.org/docs/current/ddl-rowsecurity.html, not a vendor claim.

Area 2: Role assignment (5 checks)

6. Each user in the client workspace has the minimum role needed. Verify: navigate to Admin, then Settings, then Users and Roles. Review the role badges for each user. A person who only reviews AI drafts needs Use only. A person who only builds workflows needs Curate only. Neither needs Admin. NIST SP 800-53 Rev 5 AC-6 section 6a (csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) requires least-privilege role assignment.
7. Reviewers and approvers have the Use role, not Admin. Verify: navigate to Admin, then Settings, then Users and Roles. Confirm reviewer accounts show the Use role badge and not the Admin badge. The Use role grants access to the Task Inbox and task decisions (Approve, Reject, Request Changes). It does not grant access to Admin settings, the Workflow Editor, or agent management.
8. Workflow builders have the Curate role. Verify: navigate to Admin, then Settings, then Users and Roles. Confirm the person who builds workflows has the Curate role badge. The Curate role grants workflow building permissions (workflows:read, workflows:write, agents:read).
9. Agent creators have the Create role. Verify: navigate to Admin, then Settings, then Users and Roles. Confirm the person who creates and edits AI agents has the Create role badge. The Create role grants agent creation and editing permissions (agents:read, agents:write).
10. Role changes take effect on next sign-in. After changing a user's roles, ask them to log out and back in. Role updates apply when the affected user's session refreshes.

Area 3: Credential isolation (5 checks)

11. AI provider credentials are stored in the client workspace, not shared across workspaces. Verify: navigate to Admin, then API Management, then Providers in the client workspace. The provider list shows only providers configured in this workspace. PostgreSQL RLS prevents providers from other workspaces from appearing in the result set.
12. API keys are encrypted with AES-256-GCM authenticated encryption. AES-256-GCM is specified in NIST SP 800-38D (csrc.nist.gov/pubs/sp/800/38/d/final). The GCM authentication tag detects and rejects any tampering with the ciphertext. Credential values are never returned through the API once stored.
13. API keys are not stored anywhere outside Dave by voolama. Once an API key is saved in the client workspace, delete any copies stored in email, notes, spreadsheets, or shared documents. On 2026-07-01, the voolama team deleted the OpenAI API key from the shared notes document after saving it in Dave by voolama and confirmed the key was absent from the provider API response.
14. Credential values are never returned through the API. Verify: retrieve a provider record via the Dave by voolama API. The key field is absent from the response. No vendor trust required: the API response is directly inspectable. On 2026-07-01, the voolama team confirmed this by retrieving the OpenAI provider record and observing the key field was absent.
15. Each workspace's files are written only within that workspace's storage area. PostgreSQL RLS scopes file records to the workspace. File uploads in Client A's workspace are not accessible from Client B's workspace.

Area 4: Offboarding and engagement close (5 checks)

16. Departing team members are deactivated, not deleted. Verify: navigate to Admin, then Settings, then Users and Roles. Confirm no former team member has an active status. Deactivation preserves the full audit record. An inactive user cannot log in; existing sessions are invalidated on the next API call. NIST SP 800-53 Rev 5 AU-9 section 9a (csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) requires protection of audit information from unauthorized modification or deletion.
17. All active workflows are archived when the engagement ends. Navigate to Workflows. Set each active workflow's status to archived. Archiving retires a workflow from active use while preserving its full version history. An archived workflow cannot spawn new instances.
18. The audit log is exported as CSV before the engagement closes. Verify: navigate to Admin, then Settings, then Audit Log. Set the date range to the full engagement period. Click the download button. A CSV file downloads with all event fields for the period. Every significant action: data changes, sign-in events, configuration changes, and MCP activity: is recorded with full context.
19. Users associated with the closed engagement are deactivated. Verify: navigate to Admin, then Settings, then Users and Roles. For each user associated with the closed engagement, enter edit mode, change Status to inactive, and click Save. Existing sessions are invalidated on the next API call.
20. AI provider credentials for the closed engagement are reviewed. Navigate to Admin, then API Management, then Providers. Review whether any provider credentials were specific to the closed engagement. If so, rotate or revoke the API key at the provider (OpenAI at platform.openai.com, Anthropic at console.anthropic.com, etc.) and update or remove the provider record in Dave by voolama.

Dave by voolama (hellodave.ai) has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. Roles are editable.

NIST SP 800-53 Rev 5 AC-6 section 6a (csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) requires: 'Employ the principle of least privilege, allowing only authorized accesses for users which are necessary to accomplish assigned tasks.' Assign each team member the minimum role they need. Review role assignments periodically as team responsibilities shift.

This checklist covers 20 workspace isolation, role assignment, credential isolation, and offboarding checks in Dave by voolama (hellodave.ai). Three things it does not cover:

• Building the workflow graph and configuring Human Review nodes. The step-by-step workflow building process and the Human Review task pattern for AI draft approval are covered in the companion article: How Can a Small Marketing Agency Use AI Without Losing Control of Client Work?
• MCP integration setup and key management. Connecting AI assistants to a workspace over MCP, choosing capability presets, and rotating keys are covered in the Connect an AI Assistant over MCP quick-reference.
• Legal compliance advice. This checklist cites NIST SP 800-53 Rev 5 AC-6 section 6a, AU-9 section 9a (csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), and NIST SP 800-38D (csrc.nist.gov/pubs/sp/800/38/d/final) as technical mapping references, verifiable at those URLs. The compliance standard mappings are technical observations about how the product's design aligns with published standards: they are not an independent audit. Whether any specific workspace configuration satisfies a particular legal or regulatory obligation requires a qualified professional's assessment.