When an agency manages AI agents for several businesses, a shared workspace can quickly become confusing—and risky. Client users need a clear place to view their own agents, knowledge, and conversations without seeing another customer’s information. That makes portal design more than a branding decision: it is a matter of access control, data isolation, and operational clarity.
This guide explains how to give each client an isolated portal, whether you are building your own software or configuring a white-label AI agent platform. The goal is to let agency teams manage multiple accounts efficiently while giving every client a private, familiar experience.
What an Isolated Client Portal Should Include
A client portal is a secure interface where a customer can access the parts of an AI service that they are allowed to manage or review. It may show an agent’s status, approved knowledge sources, conversation history, handoff activity, and basic settings. The exact features depend on the service agreement and the client’s role.
Isolation means more than hiding other clients from a menu. Each client’s data and actions must be scoped so that one account cannot access another account’s records, files, settings, or conversations. A branded login page can improve trust, but branding alone does not provide security.
For an agency operating WhatsApp AI agents, this distinction matters. A client may need to review leads and update a product FAQ, while the agency retains control over model configuration, integrations, and account-wide security. A well-designed portal supports both without mixing responsibilities.
Choose an Isolation Model Before Building
Start by deciding how client accounts will be separated in your application. The right design depends on your risk profile, scale, infrastructure, and contractual requirements.
| Model | How it works | Best suited to |
|---|---|---|
| Shared database, tenant-scoped records | Client records share database infrastructure, but each record is associated with a tenant ID. | Many clients with consistent workloads and carefully enforced access rules. |
| Separate schema or database | Each tenant’s data is stored in a distinct schema or database. | Agencies that need stronger separation or easier client-specific data operations. |
| Separate deployment | Each client receives an independently deployed application or environment. | High-security, regulated, or highly customized projects. |
There is no universal best option. A shared database can be efficient, but a missed tenant filter can expose records. Separate deployments can increase isolation, but they also add maintenance work. Match the model to the sensitivity of client data and the level of separation promised in your agreement.
How to Give Each Client an Isolated Portal
1. Create a tenant for every client
Represent each business as a tenant, organization, or workspace in your system. Give it a stable internal identifier that is not based on a changeable company name. Associate users, agents, knowledge files, conversations, integrations, and settings with that tenant.
Plan for agencies to have their own staff accounts as well. A user may belong to the agency team and access multiple client tenants, while a client user should normally be limited to one. This relationship should be explicit in your data model rather than inferred from a URL or email address.
2. Authenticate users and authorize every request
Authentication establishes who is signing in; authorization decides what that person may do. Use a reliable identity system, require strong authentication for privileged accounts, and assign each user a role. Typical roles include agency administrator, agency operator, client administrator, and client viewer.
Then enforce permissions on the server for every page, API request, file download, and action. Do not rely on hiding buttons in the browser. A user who cannot see a conversation link should also be unable to retrieve the conversation by changing an ID in a request.
Whenever a request is made, determine the user’s permitted tenant from their authenticated session and membership. Do not trust a tenant ID supplied only by the browser. If the user can access several clients, verify that the requested tenant is among their authorized memberships.
3. Scope data, search, and file access
Apply tenant boundaries consistently across every data source. That includes relational records, uploaded PDFs, object storage, vector indexes, cached results, analytics, and exported reports. A knowledge search should retrieve only material belonging to the active client, even when several clients use the same model or search service.
For example, a conversation query should filter by both the conversation identifier and the user’s authorized tenant. File links should be short-lived and generated only after a permission check. If you use shared vector infrastructure, include tenant metadata in the retrieval filter and test that the filter cannot be omitted by an application error.
Keep backups, logs, and support tools in scope too. They may contain the same private information as the main portal. Restrict access, define retention periods, and avoid exposing message content in routine diagnostic logs unless there is a clear operational need.
4. Separate roles from client branding
Give each portal a recognizable identity with a client name, logo, color palette, and appropriate domain or subdomain. These elements help clients feel oriented, but they should be stored as tenant settings and displayed only after the tenant has been verified.
Pair the visual experience with role-based capabilities. A client administrator might invite coworkers, review conversations, and edit approved knowledge. A viewer might only inspect reports. Agency operators may configure WhatsApp connections, adjust agent behavior, and manage human handoff. Keep sensitive controls out of client roles unless the service contract requires them.
5. Define human handoff and conversation permissions
AI automation often needs a human at the right moment. Decide who can view a handoff queue, claim a conversation, pause an agent, or return a chat to automation. These controls should follow the same tenant rules as the rest of the portal.
Make ownership and status visible. For instance, show whether a WhatsApp conversation is handled by the AI, waiting for a person, or assigned to a teammate. Record important actions—such as pausing an agent or changing an assignment—in an audit trail. This helps agency teams explain what happened and lets clients understand how their service is being managed.
6. Provision clients with a repeatable process
A portal is easier to operate when onboarding is consistent. Create a checklist or provisioning workflow that creates the tenant, assigns users and roles, applies branding, configures the agent, and connects approved knowledge sources. Confirm that the correct WhatsApp number and integrations belong to the intended client before activation.
Use a review step before launch. Verify that the client can sign in, see only their own information, and perform only permitted actions. Also check that agency staff can support the account without accidentally using another client’s configuration. Templates can make this process faster, but they should not copy secrets, credentials, or private knowledge between tenants.
Test Isolation Before Inviting Clients
Do not treat a successful login as proof that the portal is isolated. Test with at least two sample tenants and users with different roles. Try to access another client’s pages, records, files, search results, and conversation details by changing URLs or request identifiers. Confirm that unauthorized attempts are denied and do not reveal whether a record exists.
- Check list views, search, filters, exports, and pagination for missing tenant restrictions.
- Test file previews and downloads, including links copied from another account.
- Verify that background jobs and webhook handlers preserve the correct tenant context.
- Confirm that cached pages or API responses cannot be served to the wrong user.
- Review audit logs and support tools for accidental cross-client visibility.
Repeat these checks after major changes to authentication, database queries, integrations, or search. Automated authorization tests are especially useful because a single shared component can affect every client portal.
Common Mistakes to Avoid
- Using separate URLs as the security boundary. A different subdomain does not isolate data unless the server enforces tenant permissions.
- Applying access checks only in the interface. Every backend operation needs its own authorization decision.
- Forgetting secondary data stores. Files, embeddings, analytics, and backups need tenant-aware controls too.
- Giving every client administrator access. Least-privilege roles reduce the impact of mistakes and compromised accounts.
- Sharing a default knowledge base unintentionally. Reuse generic instructions only when appropriate; keep client-specific documents separate.
- Skipping offboarding. When a contract ends, revoke user access, disconnect integrations, and follow agreed data-retention and deletion policies.
A Practical Portal Launch Checklist
Before launch, confirm that every client has a distinct tenant, named users, and clearly defined roles. Check that API routes and data queries enforce tenant scope, and that uploaded knowledge and AI retrieval are isolated. Review the client’s branding, WhatsApp configuration, conversation visibility, and human handoff permissions. Finally, test with accounts from multiple tenants, document support procedures, and explain to the client what they can manage themselves.
Clear boundaries also make agency operations easier. Teams can review client work without confusing accounts, onboard new customers with less manual setup, and offer recurring services with well-defined access. A platform such as OpenLivery can support agencies building branded, multi-client AI agent workflows, but the same principles apply whether you use managed software or build a self-hosted system.
The essential rule is simple: treat every client portal as a tenant-scoped application, not merely a customized page. When identity, permissions, data, and operational processes all respect that boundary, clients get a useful private workspace—and your agency gets a foundation that can scale with confidence.
