Capstone: architect a control plane
The closing exercise. Design the whole system for a hostile brief, and defend the trade-offs you make.
This is the last lesson in the course, and it asks for the thing every previous track was building toward: a complete design, with the compromises stated out loud.
The brief. A healthcare scheduling company runs a fleet of agents that read patient referral emails, look up clinician availability, book appointments, and settle small payments to partner clinics. Referrals arrive from outside the organisation. Regulators require that every access to patient data be attributable to a named principal and retained for seven years. The company has been breached once already, through a contractor's leaked API key.
Design it before reading on. Then compare, and pay attention to the places you and the walkthrough disagree, because several of these have more than one defensible answer.
Start from the threat model, not the product. Referral emails are untrusted content by definition, patient records are the private data, and booking confirmations go back out to the referrer. All three circles are present and none can be removed without destroying the product. That settles the shape of everything else: injection will eventually succeed, so the design has to make success cheap.
- Identity. One agent per function, never one fleet identity. Referral parsing, scheduling, and settlement are three principals with three audit trails, because the seven-year retention requirement is worthless if every action is attributed to "the agent".
- Credentials. No agent holds one. Clinical systems and the payment rail are reached through bindings with vault_ref credentials, so the contractor breach that started all this cannot repeat in the same shape.
- Storage. Patient identifiers live in a vault with MPC custody, because a single provider holding complete key material is exactly the concentration a regulator will ask about.
- Inference. Referral text goes through Shroud, so PII is scrubbed before it reaches a model provider and never enters a third party's logs.
- Authorization. Deny-by-default, scoped per path, with environment tags locked on the production agents so a preview identity can never resolve production data.
- Human factor. Settlement above a threshold routes to a person with step-up authentication, and the threshold is set where a human will still read the prompt.
Decide
The clinical team asks for one agent that can do all three jobs, arguing that three agents means three integrations to maintain and the same human owns all of them anyway.
How do you answer?
Now the part that separates a design from a diagram: say what you gave up. Every choice above has a cost, and a design that claims otherwise has not been thought through.
- MPC custody adds operational failure modes. Shares can be lost, and a team without key-handling maturity can lock itself out of patient data permanently.
- Routing inference through a TEE proxy adds latency to every referral, and attestation proves which code runs, not that the code is correct.
- Three identities mean three sets of policies that can drift apart, and drift is how a preview agent ends up with a production grant.
- Deny-by-default guarantees a support burden. Someone is blocked on a Friday afternoon by a rule nobody remembers writing.
- Approval thresholds decay. Set too low they get clicked through; set too high they never fire. Either way they need revisiting, and nobody schedules that.
If you cannot name what a control costs, you do not yet understand it well enough to defend it when someone asks to remove it. That conversation always comes.
One last thing the brief tried to hide. Nothing above prevents the breach that already happened: a contractor leaked a key. What the design changes is the consequence. The leaked credential is now short-lived, scoped to one path, attributable to one principal, and useless for reaching the payment rail. That is the whole thesis of this course, stated as an outcome rather than a principle.
Check your understanding
3 questionsWhy does the brief's threat model settle the shape of the design before any product decision?
What is the strongest argument against merging the three agents into one?
What does the design actually change about the original contractor breach?