Skip to main content

Consulting Firm AI: Multi-Client Data Isolation with RBAC

Consulting firms rarely have a single AI risk profile. One engagement may involve internal strategy workshops, another may include regulated healthcare data, and a third may center on sensitive diligence material for a private transaction. If consultants use the same assistant route for all of those contexts, multi-client work turns into a data-isolation problem immediately.

Keeptrusts helps by making client boundaries explicit at the gateway. A consulting route can use RBAC to require engagement-scoped identity, DLP Filter to detect client and project markers, Data Routing Policy to enforce provider restrictions, and Audit Logger to preserve a reviewable record of how the route was used. Teams can then scale this model using Set Up Team-Based AI Governance at Scale and Unified Access.

Use this page when​

  • You deploy AI across multiple consulting or professional-services engagements with different confidentiality requirements.
  • You need a clear pattern for preventing cross-client contamination in prompts, outputs, and access rights.
  • You want guidance aligned to Consulting, Team-Based AI Governance, and Prevent Data Leaks.

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Technical Engineers, practice-operations teams

The problem​

Client isolation failures in consulting are usually operational, not theoretical. An analyst working on one engagement reuses a prompt from another. A partner asks a general assistant to compare two similar projects without realizing the request crosses confidentiality lines. A practice team builds a shared retrieval corpus because it is convenient, and the boundaries between clients become social conventions instead of enforceable controls.

That is dangerous for several reasons. It can breach NDAs, expose client strategy, blur conflict-of-interest controls, and create exactly the kind of cross-engagement contamination that clients expect professional-services firms to prevent. It also creates billing and governance confusion, because if the route is not engagement-scoped, the organization cannot easily attribute AI activity, spend, and review decisions to the correct client context.

The common mistake is to think of client isolation as a content-filtering problem only. Redaction matters, but the real control surface is identity and scope. If the route cannot tell which engagement a request belongs to and which roles may use it, then later controls are working too late.

The solution​

The strongest consulting pattern is engagement-scoped access first, content controls second.

Use rbac to require user, role, and engagement headers on every request. This lets the route deny unattributed traffic before any prompt reaches a provider.

Use dlp-filter to catch explicit client names, engagement codes, and internal methodology markers that should be blocked or redacted. That provides a content backstop when consultants include more detail than intended.

Use data-routing-policy so each engagement can stay on an approved provider path. Highly sensitive clients may require zero-retention or local-only routes, while lower-risk engagements may allow a broader but still governed provider set.

Then use audit-logger and team-based governance patterns so the firm can review activity by client context, practice area, and role. Combined with Unified Access, that gives firms a cleaner model for access, billing, and policy targeting at scale.

Implementation​

This example creates a consulting route that enforces engagement-scoped identity and blocks obvious cross-client leakage markers.

pack:
  name: consulting-client-isolation
  version: 1.0.0
  enabled: true

policies:
  chain:
    - rbac
    - pii-detector
    - dlp-filter
    - data-routing-policy
    - audit-logger

policy:
  rbac:
    deny_if_missing:
      - X-User-ID
      - X-User-Role
      - X-Engagement-ID
      - X-Client-ID
    roles:
      analyst:
        allowed_tools:
          - summarize
          - search
          - draft_slide_note
      engagement-manager:
        allowed_tools:
          - summarize
          - search
          - draft_slide_note
          - compare_sources

  pii-detector:
    action: redact
    detect_patterns:
      - name
      - email
      - phone
      - financial_account

  dlp-filter:
    blocked_terms:
      - cross engagement comparison
      - internal methodology
      - client confidential
    action: block
    fuzzy_matching: true
    max_distance: 1

  data-routing-policy:
    require_zero_data_retention: true
    sanitize_before_provider: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

If the firm needs more than one policy profile, the next step is not to loosen the route. It is to create multiple engagement classes and target them explicitly through team-based governance.

The short validation loop confirms that the boundary is real:

kt policy lint --file ./consulting-client-isolation.yaml
kt gateway run --policy-config ./consulting-client-isolation.yaml --port 41002
kt events tail --policy rbac
kt events tail --policy dlp-filter

Those checks show whether the route is refusing unattributed traffic and catching obvious cross-client leakage attempts.

Results and impact​

Consulting firms usually see an immediate improvement in client-boundary discipline. Teams can still use AI for drafting, synthesis, and analysis, but those requests now carry explicit engagement context and move through a route designed to respect client separation.

That has practical downstream value. Compliance and operations teams can review AI usage by engagement, spending can be attributed more cleanly, and sensitive clients can be placed on narrower provider paths without redesigning the entire platform.

Most importantly, the firm gains a defensible answer to a client question it should always be prepared for: how do you stop our data from mixing with another client's work? Engagement-scoped RBAC, routed provider controls, and reviewable evidence provide a better answer than policy training alone.

Key takeaways​

  • Multi-client isolation in consulting starts with engagement-scoped rbac, not with content filtering alone.
  • Use dlp-filter as a backstop for client and methodology markers.
  • Use data-routing-policy to tailor provider handling by engagement sensitivity.
  • Use audit-logger so the firm can review AI behavior by client context.
  • Scale the pattern with team-based governance and unified access rather than broad shared routes.

Next steps​