Chapter 7 — Identity and access foundations
Lesson map
Lesson 07 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes"]
N1["7.1 The three As"]
N2["7.2 Agent identities"]
N3["7.3 Least privilege for tools"]
N4["7.4 Auditing"]
N5["7.4b Human confirmation"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 The three As"]
N2["7.2 Agent identities"]
N3["7.3 Least privilege for tools"]
N4["7.4 Auditing"]
N5["7.4b Human confirmation"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX019"]
[Learning outcomes]
|
v
[7.1 The three As]
|
v
[7.2 Agent identities]
|
v
[7.3 Least privilege for tools]
|
v
[7.4 Auditing]
|
v
[7.4b Human confirmation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes
You will (1) explain authentication, authorisation and accounting; (2) design identities for AI agents and their tools; (3) apply least privilege and delegated access; and (4) audit agent actions.
7.1 The three As
Authentication proves who you are; authorisation decides what you may do; accounting records what you did. AI agents need all three, because they act on behalf of people. For Ask Brightwell, authentication comes from the customer's sign-in, authorisation is the delegated token's scopes plus the tool services' checks, and accounting is the log of every tool call with the user it acted for. If one is missing, a returns call cannot be traced to a person or checked against their rights. Each of the three has its own control in later chapters.
7.2 Agent identities
A common mistake is giving the agent one powerful service account. Then any user who can steer the agent — directly or through injected text — gains that account's power: the "confused deputy". Better: the agent acts with a token delegated from the signed-in user, limited to the scopes needed for the task, and expiring quickly. Ask Brightwell's order tool showed the cost of the first approach: it accepted any order number, so a customer could ask for someone else's order. Ask Brightwell's tools now use delegated tokens.
7.3 Least privilege for tools
Each tool should do one narrow thing: "look up my order" rather than "query database". Validate parameters against the user's identity in the tool service, not in the prompt: the returns tool checks that the order belongs to the caller. For Ask Brightwell, the order tool now reads the user ID from the delegated token, so no wording of the request can make it fetch someone else's order. The returns tool performs the same ownership check before starting any return. A prompt instruction such as "only look up the user's own orders" would be one injection away from failing.
7.4 Auditing
Log who asked, what the agent proposed, which tool ran, with which parameters, and the result. Store logs where the agent cannot alter them. Review unusual actions such as returns started for orders the user did not place. Ask Brightwell writes these records to a log store the orchestrator can append to but not change, so a compromised orchestrator cannot hide what it did. A weekly review looks for returns on orders that the signed-in user did not place, which is the pattern a successful injection would leave.
7.4b Human confirmation
For consequential actions, such as starting a return or changing an address, show the user what will happen and ask them to confirm it. Build the confirmation screen from the structured action, not from text the model wrote, because injected text can make a harmful action look harmless. Ask Brightwell's returns confirmation shows the order number, item and refund amount drawn from the order record, not the model's description of them. If planted text tries to describe a return for an expensive item as a small one, the confirmation still shows the real values from the database.
7.5 Worked example (synthetic Brightwell case)
Ask Brightwell's order tool took any order number. Jonas, on staging, asks "show order 100245" while signed in as a different test customer — and gets another customer's address. The fix: the tool service reads the user ID from the delegated token and returns only that user's orders. He writes a test that fails if any cross-user lookup succeeds. The test turns a one-off finding into a lasting control: any future change that weakens the ownership check fails the build. Because the check sits in the tool service, it holds whatever the model is persuaded to ask for.
7.6 Errors and limits
- One service account for all agent actions.
- Ownership checks done by the model.
- Logs the agent can modify.
The order-tool finding showed the second error in practice: the model was trusted to pass only the user's own order numbers. Ask Brightwell now uses delegated tokens rather than one service account, checks ownership in the tool service and writes logs the agent cannot modify. These three fixes together mean a persuaded model cannot act beyond the signed-in user's rights. Each fix has a unit test that fails if it is undone.
Exercises
- EX019 — Three As. Apply authentication, authorisation and accounting to the returns tool. Rubric: 3 = all three concrete; 2 = two; 1 = one; 0 = none.
- EX020 — Confused deputy. Explain the confused-deputy risk in two sentences. Rubric: 3 = agent's authority used by less-privileged requester, via steering; 2 = partial; 1 = vague; 0 = wrong.
- EX021 — Test. Write a test case for cross-user order lookup. Rubric: 3 = setup, action, expected denial, log check; 2 = three; 1 = vague; 0 = none.
Synthesis
Agents must act with the user's delegated, narrow, short-lived rights, with checks in tool services and tamper-resistant logs.
Continue studying — chapter 07 of 30
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →