Skip to main content

Enterprise Data Compartmentalization: Need-to-Know AI Access Controls

Most enterprise AI incidents do not start with a hostile outsider. They start when an internal assistant quietly collapses boundaries that the rest of the organization worked hard to maintain. A user with legitimate access to one domain asks an AI system to summarize material from another. A contractor uses the same prompt lane as a full-time employee. A shared route that was supposed to help with documentation becomes an ungoverned path between finance, legal, R&D, and operations. That is why need-to-know still matters in AI systems even when identity and network controls already exist elsewhere.

Keeptrusts helps because it lets teams enforce data compartmentalization where the model call actually happens. Instead of assuming an upstream application will always send the right information to the right route, you can apply RBAC, DLP Filter, Data Routing Policy, and route-level evidence collection with Audit Logger. That makes AI access controls much closer to a zero-trust posture than a shared assistant model ever will be.

Use this page when​

  • You need internal AI access controls that enforce need-to-know boundaries across teams, business units, or programs.
  • You want route isolation for different data compartments instead of one broad enterprise assistant.
  • You are trying to connect AI governance to Unified Access and Zero Trust AI.

Primary audience​

  • Primary: Technical Leaders
  • Secondary: Technical Engineers, security architects

The problem​

Enterprises already know how to define compartments on paper. The difficulty is preserving them once AI enters the workflow. Internal users expect a single assistant to help with everything. Product teams want fast adoption, and generalized AI interfaces make that easy. But the very traits that make AI convenient also make it dangerous for need-to-know environments.

An employee who can legitimately access commercial operations data should not automatically be able to query legal matter summaries. A contractor helping with logistics should not inherit access to acquisition planning notes. A corporate assistant that can search broadly across internal documentation often becomes a bypass around the organization’s carefully maintained application boundaries.

The problem is not only who asked the question. It is also where the request goes and what supporting context travels with it. If a route uses a broad provider pool, includes copied text from multiple compartments, and records little evidence about who sent what, the enterprise loses the ability to prove separation after the fact.

Need-to-know systems fail when they rely on implied behavior. AI needs explicit route design, explicit role checks, and explicit provider restrictions. Otherwise the first shared convenience route becomes the default route for everything.

The solution​

The strongest pattern is to treat compartments as separate AI lanes, not as optional labels inside one lane.

Use RBAC to require identity headers and role metadata on every request. Then define routes so users only reach the lane appropriate to their team, program, or data class. A mergers-and-acquisitions route, an engineering route, and a public-sector delivery route should not all share the same access path just because they call a model behind the scenes.

Add DLP Filter to prevent sensitive data from jumping compartments in copied prompt text. This is especially useful when teams work across overlapping datasets and the easiest mistake is pasting context from one system into another route. DLP is not the whole answer, but it is an important backstop.

Then narrow the provider boundary with Data Routing Policy. Some compartments can use a broader provider set. Others need local-only processing, tokenized inputs, or stricter retention settings. If those differences are not encoded in routing policy, the organization is effectively assuming every compartment has the same handling standard.

Finally, record who used which lane and why. Audit Logger plus the isolation guidance in Consumer Group Isolation make it easier to review whether route separation is actually holding up in production.

Implementation​

This route example shows a simple compartment-first design. It is not trying to make one assistant safe for every business unit. It is creating a specific lane for restricted internal operations work.

pack:
  name: restricted-ops-compartment
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: internal-only-target
      provider: ollama
      model: llama3.1:70b
      base_url: http://localhost:11434
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        allow_internet_egress: false
        local_only_processing: true

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

policy:
  rbac:
    deny_if_missing:
      - X-Business-Unit
      - X-User-ID
      - X-User-Role
    roles:
      restricted-ops-analyst:
        allowed_tools:
          - search
          - summarize
      restricted-ops-manager:
        allowed_tools:
          - search
          - summarize
          - compare

  dlp-filter:
    action: block

  data-routing-policy:
    require_zero_data_retention: true
    require_in_memory_only: true
    sanitize_before_provider: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block

  audit-logger: {}

The right validation loop is equally compartment-specific.

kt policy lint --file ./restricted-ops-compartment.yaml
kt gateway run --policy-config ./restricted-ops-compartment.yaml --port 41002
kt events tail --policy rbac
kt events tail --policy audit-logger

If a user cannot prove the role and compartment metadata needed for the route, the request should fail early. That is the behavior you want. Need-to-know is not supposed to be frictionless. It is supposed to be explicit.

Results and impact​

This design stops AI from flattening internal boundaries. Teams work through purpose-built lanes instead of one broad assistant, and each lane can carry its own provider and retention requirements.

It also makes reviews much easier. Security teams can ask which routes exist, who can use them, and what provider rules apply without reverse-engineering application behavior. If a compartment needs stronger handling later, the organization can update the route directly instead of redesigning the entire AI program.

Most importantly, need-to-know becomes enforceable at the point of model invocation. That is where the boundary matters most.

Key takeaways​

  • Need-to-know breaks down quickly when AI is deployed as one broad internal assistant.
  • Use RBAC to force explicit compartment metadata and role-aware route access.
  • Use DLP Filter to stop copied prompt text from bridging compartments.
  • Use Data Routing Policy to give each compartment its own provider-handling standard.
  • Combine route isolation with Unified Access and Zero Trust AI instead of treating AI as a special exception.

Next steps​