Skip to main content

Role-Based Access Control: Who Can Do What in Your AI Platform

RBAC in Keeptrusts answers "who can do what" at two different layers: console roles and permissions decide which people can view, review, export, configure, or administer governance surfaces, while the runtime rbac policy in policy-config.yaml decides which request identities can access tools, data sensitivity levels, and model-backed workflows once traffic reaches the gateway.

Use this page when​

  • You need to separate platform administration from day-to-day review and investigation work.
  • You want least-privilege access in both the console and the governed request path.
  • You are designing team roles, SSO mapping, or the first runtime RBAC policy.

Primary audience​

  • Primary: Technical Engineers, Organization Admins, and Security teams
  • Secondary: Technical Leaders and Compliance reviewers

The problem​

Access control fails in AI platforms when teams collapse every permission into one category. The person who investigates blocked requests is not always the person who should deploy policy changes. The person who reviews evidence for an audit is not always the person who should manage SSO settings. The user who can ask an AI system to summarize internal documents is not always authorized to use tools against restricted data.

If those boundaries are not explicit, two bad outcomes follow.

The first is over-permissioned operators. Too many people can change production policy, rotate tokens, or alter organization settings because giving access is easier than modeling it properly.

The second is under-specified runtime identity. Requests hit the gateway with weak or missing identity headers, so the system can log what happened but cannot confidently decide whether the caller should have been allowed to do it.

Keeptrusts deliberately separates these concerns because control-plane access and data-plane authorization are different jobs. One governs people operating the platform. The other governs identities using AI through the platform.

The solution​

Start by treating console permissions and runtime policy as complementary layers.

At the console layer, use Members, Teams and Roles, Settings -> Roles, and Security Settings to decide who can read events, resolve escalations, deploy configurations, manage organization settings, export evidence, or configure SSO. The permission model in the console is explicit enough to distinguish capabilities such as events:read, escalations:resolve, configs:deploy, billing:view, tokens:admin, and org:sso.

At the runtime layer, use the rbac policy in your configuration. The current implementation is header-based and enforces required identity headers, optional Bearer-token presence checks, role-based allow and deny lists for tools, sensitivity ceilings through keeptrusts.data_sensitivity, and minimum-necessary restrictions for PHI-like content.

The important idea is that one layer does not replace the other.

Console permissions do not tell the gateway whether a request identity may use a tool.

Runtime RBAC does not tell the console whether a human reviewer may resolve an escalation or export evidence.

You need both if you want least privilege from end to end.

Implementation​

An effective RBAC rollout usually follows this sequence.

  1. Define teams in the console that map to real ownership boundaries.
  2. Assign base roles such as owner, admin, member, or viewer so users start with a clear minimum set of privileges.
  3. Create finer-grained role definitions where needed. A reviewer role may need event and escalation access without configuration deployment rights. A billing role may need spend visibility without token administration. An SSO administrator may need org:sso without broad operational access.
  4. Configure SSO if your identity provider is available so role and team assignment does not stay manual longer than necessary.
  5. Add runtime RBAC to the policy chain so request identities are evaluated at the gateway.
  6. Validate the configuration and test both missing-identity and allowed-use cases.

This is a working runtime example based on the current RBAC policy shape:

policies:
  chain:
    - rbac

policy:
  rbac:
    deny_if_missing:
      - X-User-ID
      - X-User-Role
    require_auth: true
    roles:
      analyst:
        allowed_tools:
          - search
          - summarize
          - report_*
        denied_tools:
          - dangerous_*
      admin:
        allowed_tools:
          - "*"
        denied_tools: []
    data_access:
      analyst:
        max_sensitivity: confidential
      admin:
        max_sensitivity: restricted
    minimum_necessary:
      enabled: true
      allowed_phi_roles:
        - clinician
        - admin

And validate it before rollout:

kt policy lint policy-config.yaml

A few implementation details are easy to miss.

First, runtime role resolution is currently header-based. The policy does not map roles from JWT claims for you. That means the caller or an upstream layer must send reliable X-User-ID and X-User-Role headers.

Second, require_auth checks for a Bearer-shaped header but is not a full identity-verification system by itself. Use a proper upstream identity layer when you need stronger token verification.

Third, undefined roles should be treated carefully in testing. If a requested tool is not allowed for a declared role, the gateway will block it. That is good for safety, but only if your team expects the behavior and has tested it.

At the console level, a practical pattern is to create role groupings around jobs rather than departments.

  • Reviewers: read events, claim escalations, resolve escalations, export evidence.
  • Policy engineers: read and write configurations, but not necessarily deploy them.
  • Deploy approvers: deploy configurations and manage gateways.
  • Billing owners: view billing and export billing data.
  • Identity administrators: manage SSO and security settings.

That pattern makes audits easier because separation of duties is visible. The person who changed a configuration is not automatically the same person who approved it or the same person who reviewed the resulting escalations.

It also helps at runtime. Suppose you operate an internal analytics assistant. Analysts may be allowed to search and summarize data up to confidential, while admins may access restricted workflows. A support reviewer may have console access to investigate events and exports, but no runtime permission to use high-sensitivity tools. These are different forms of access, and Keeptrusts supports modeling them explicitly.

Results and impact​

When teams implement RBAC at both layers, governance becomes more believable because permissions match actual responsibility. Reviewers can review. Engineers can engineer. Admins can administer. Callers can use only the tools and sensitivity levels appropriate to their role.

Operationally, this reduces accidental changes and ambiguous ownership. If a deployment goes wrong, you know who could deploy. If an escalation sat in a queue, you know who could resolve it. If a runtime request was blocked for sensitivity reasons, you know which declared role ceiling caused it.

Security posture also improves because you are no longer relying on one giant admin role or one flat runtime trust model. The gateway can enforce minimum-necessary access for sensitive traffic, while the console can separately limit who configures SSO, tokens, or policy rollout.

For regulated environments, that separation is not just a good habit. It is often the difference between a control that looks good in a diagram and a control that survives review. Auditors usually care less about the label "RBAC" than about whether access decisions are explainable. Keeptrusts gives you two explainable layers: human operator permissions in the console and runtime request authorization in the policy chain.

Key takeaways​

  • Keeptrusts RBAC has two layers: console permissions and runtime gateway policy.
  • Use console roles to separate operational duties such as review, deployment, billing, and SSO administration.
  • Use the rbac policy to enforce request identity, tool access, and sensitivity ceilings.
  • Test missing headers, undeclared roles, and out-of-scope tool calls before rollout.
  • SSO helps with identity lifecycle, but runtime authorization still needs explicit policy design.

Next steps​