RBAC

• Key points are in the visual diagram above.

An agent with broad API keys becomes a privilege escalation vector. RBAC ensures the AI can only do what the authenticated user (or service account) is allowed to do — no more.

Hotel key cards: your card opens your floor and the gym, not the executive suite or the server room — regardless of how politely you ask the concierge.

Scenario

A junior support agent's chatbot can search public KB articles and create tickets, but cannot query revenue data or trigger refunds — the refund tool returns 403 unless the user has the 'billing-approver' role.

Solution

In Enterprise AI, apply RBAC to this scenario: A junior support agent's chatbot can search public KB articles and create tickets, but cannot query revenue data or trigger refunds — the refund tool returns 403 unless the user has the 'billing-approver' role. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.

Do this before moving to the next module — reading alone is not enough.

Open the Code Walkthrough below and run it locally. Change one parameter related to RBAC (e.g. model, temperature, top_k, or tool name), observe the difference in output, and write 2–3 sentences explaining what changed.

Highlighted lines show where RBAC happens in the code.

1function enforceToolAccess(user, toolName, payload) {2  const policy = rbac.getPolicy(user.roles);  # key line for RBAC3  const decision = policy.evaluate("tool:" + toolName, { user, payload });4  if (!decision.allow) {5    audit.log({ event: "rbac.denied", user: user.id, tool: toolName });  # key line for RBAC6    throw new ForbiddenError(decision.reason);7  }8  return decision;  # return the result9}

• Treating RBAC as a black box without evaluation
• Ignoring cost and latency in production
• Skipping error handling for rbac

Quick recap — the most important points from this module.