◇ OpenCyber Academy
Bachelor's · Chapter 13 · English

Chapter 13 — Identity and access

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 13 — Identity and access

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Authentication, authorization, accounting"]
  N2["13.2 Role- and attribute-based access"]
  N3["13.3 Delegation for AI agents"]
  N4["13.4 Accounting for AI actions"]
  N5["13.6b Reviewing agent permissions"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Authentication, authorization, accounting"]
  N2["13.2 Role- and attribute-based access"]
  N3["13.3 Delegation for AI agents"]
  N4["13.4 Accounting for AI actions"]
  N5["13.6b Reviewing agent permissions"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Authentication, authorization, accounting]
    |
    v
[13.2 Role- and attribute-based access]
    |
    v
[13.3 Delegation for AI agents]
    |
    v
[13.4 Accounting for AI actions]
    |
    v
[13.6b Reviewing agent permissions]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) explain authentication, authorization and accounting; (2) design role-based and attribute-based access for AI applications; (3) apply delegation so AI agents act with the user's limited rights; and (4) avoid confused-deputy problems.

13.1 Authentication, authorization, accounting

Authentication proves who someone is; authorization decides what they may do; accounting records what they did. Strong authentication (multi-factor) protects accounts; precise authorization limits damage; accounting enables investigation.

For Ask Lumen, authentication is the patient's sign-in to the clinic portal; authorization is the rule that a booking may only be for that patient or someone they are a registered carer for; accounting is the log linking each booking to the conversation and session that produced it. A weakness in any one undermines the others: perfect logs do not help if the booking tool never checked who was asking.

13.2 Role- and attribute-based access

Roles (patient, receptionist, clinician) group permissions. Attributes (clinic, relationship to patient, time) refine them. Ask Lumen's booking tool should check "is the requester the patient or their registered carer, for this clinic?" rather than "is the chatbot service allowed to book?".

The second question is the wrong one because the chatbot service is always allowed; asking it turns the service's broad rights into everyone's rights. Attributes such as clinic and carer relationship let the rule follow real situations without creating a new role for each.

13.3 Delegation for AI agents

When an AI agent acts, it should use a token delegated by the user with limited scope and lifetime, so it can never do more than that user. A powerful service account turns any manipulation of the model into a privilege escalation — the confused deputy problem, where a trusted component is tricked into misusing its authority.

A delegated token carries the patient's identity, so the scheduling system can apply the patient's rights directly. Its short lifetime limits the damage if it is leaked through a log or a manipulated tool call.

13.4 Accounting for AI actions

Log which user, which conversation, which model proposal and which approval led to each action. Without this chain, incidents cannot be explained.

The chain for one booking might read: patient session 7f2, conversation c-118, model proposal at 10:14:03 to book clinic C3 on a given date, policy check passed, patient confirmed at 10:14:20, booking ID written. If a patient later disputes a booking, every step can be shown. If the model proposed something the policy blocked, that is logged too, which helps detect manipulation attempts.

13.5 Worked example (synthetic LCH case)

Ask Lumen booked appointments through a service account allowed to book for any patient. Rina showed in the test environment that a crafted message naming another synthetic patient's ID led the model to propose a booking for that patient, which the service account executed. The fix used a per-session delegated token bound to the logged-in patient (and registered carers) and a policy check comparing the booking's patient with the token's subject.

The test shows the confused deputy directly: the model did nothing wrong by its own logic, and the service account did what it was allowed to do.

13.6 Errors and limits

Broad service accounts make every prompt injection a potential privilege escalation, as the worked example showed. Letting the model decide authorization puts the rule where text can argue with it. Missing links between conversations and actions leave investigators unable to say which message caused which booking. Delegated tokens, an external policy check and request IDs address the three in turn.

13.6b Reviewing agent permissions

Every quarter, LCH lists what the Ask Lumen booking tool can actually do and compares it with what the chatbot needs. A review found the tool's account could also edit clinician schedules; that right was removed, and the review record notes who approved the remaining permissions.

Permissions tend to grow as features are added, and nobody removes them unless a review asks. The schedule-editing right had been added for a pilot that ended, and no one had noticed it was still granted.

Exercises

Synthesis

Identity controls decide what an AI agent can do on whose behalf. Delegated, scoped tokens and external policy checks prevent the model from becoming a confused deputy.

Continue studying — chapter 13 of 40

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →