CaseAdvancedResponsible AI & Advanced Practice / Agent product management specifics / #3
Describe the permission model you would design for an agent acting in a user's account.
GUARD the product is a billing agent inside Northfield Software, a project-management SaaS
Northfield Software sells project-management tools to teams. Its billing agent watches usage and can adjust seats and plan tiers to cut waste. Farah Haddad leads customer support operations and reads every escalation herself before it gets routed.
The direct answer
A permission model for an account-acting agent needs two separate people in it, not one: the admin who authorizes the agent to act on the account, and anyone else whose own access the agent is about to change. Give the admin the authority. Give the second person a notice and a short, no-admin-needed window to undo anything that reduces their own access, before it becomes final.
Do this, in order
Treat "the account" as more than one person, not a single blast-radius unit the admin fully owns.Why: an admin's authorization covers their own choices, not another person's access.
Give anyone whose seat or access shrinks a direct notice and a self-serve grace window.Why: without it, they have no lever at all until the damage is already done.
Let admin-only settings, like billing address or plan name, run on admin authorization alone.Why: not every action touches a second person, and gating those too just adds friction with no one to protect.
Track how often seat actions happen with zero notice to the affected person.Why: that number tells you if the model is actually protecting anyone or just existing on a policy page.
Re-check which actions count as "affecting someone else" as the product adds new seat types.Why: a new feature can quietly create a new powerless subject nobody designed a lever for.
How to answer this, stage by stage
Seven stages. The hard part of this question is naming the second person, not describing admin controls.
Stage 1
Scope it to one real agent
Say it like this
"I'll answer this for a billing agent inside Northfield's project-management tool, one that can adjust seats and plan tiers on its own."
Why this works
A permission model answered in the abstract turns into a policy document. One real account doesn't.
Stage 2
Name both people in the account
Say it like this
"There are two people here, not one. The admin who turns the agent on, and every teammate whose seat that agent can touch without ever being asked."
Why this works
This is GUARD's core move, and most candidates never get past the admin.
Stage 3
Say where the harm lands unevenly
Say it like this
"If the agent downgrades a seat to save the company money, the admin never notices. The teammate who loses access mid-project notices immediately, and they're the one who did nothing wrong."
Why this works
Names the asymmetry plainly, without turning it into a lecture on fairness.
Stage 4
Ask who never gets to push back
Say it like this
"The teammate can't appeal to the agent, wasn't in the loop before the change, and usually finds out only once their access is already gone."
Why this works
This is the strongest single line in a GUARD answer, and it's the one that shows real judgment.
Stage 5
Give the actual permission model
Say it like this
"Admin authorization lets the agent act on the account at all. Anything that reduces someone else's own access also needs a direct notice to that person, plus a 48-hour, one-click window to restore it themselves, no admin required."
Why this works
This is the concrete design decision the whole answer turns on.
Stage 6
Say how you'd detect it going wrong
Say it like this
"I'd track the share of seat actions taken with zero advance notice to the person affected. If that number isn't near zero, the model on paper isn't the model running in production."
Why this works
Shows you'd catch the failure yourself, before a customer had to escalate it to Farah.
Stage 7
Close on what stays simple
Say it like this
"Anything that's only the admin's own setting, like a billing address, doesn't need any of this. There's no second person to protect there."
Why this works
Shows judgment instead of applying the same heavy process to every action regardless of who it touches.
Let's learn
Northfield's billing agent watches how each seat on an account is actually used and can adjust plans and seats to cut wasted spend, on the admin's say-so.
Before the agent, an admin reviewed seat usage manually, maybe once a quarter, and always talked to the person before removing their access. It took time, so it happened rarely, and plenty of waste sat unnoticed for months.
Knowledge spark: what's "blast radius" for an account?
Every account has more than one person in it: the admin who signs the contract, and teammates who actually use the seats day to day. An action's blast radius is who else, beyond the admin, feels the consequences of it.
With the agent watching continuously, low-use seats get flagged and downgraded automatically, saving the company real money every month. That's the number in the pitch deck. It's also not where the actual design problem sits.
The turn. The savings aren't the issue. The issue is that the admin authorized the agent to act on "the account," and the account isn't one person. A single-turn cost-report feature never had to answer "whose access am I about to change," because it never changes anyone's access. This agent does, every time it acts, and that's a permission decision with no single-turn equivalent at all.
Seat downgrades: contested vs. never contested, first 3 months
Almost every downgrade goes uncontested. Before a notice-and-grace-window existed, that wasn't because they were all correct, it was because the affected person never had a way to contest them.
The decision I would take back
We built the agent's permission model around a single authorization: the admin turns it on for the whole account. That felt sufficient, since admins are the ones who buy and manage the plan. It stopped making sense once we saw the agent's actions land on people who never signed anything and never sat in that admin's chair, and who had no way to know a change was coming.
What I would leave alone: admin-only settings, changing the billing address, renaming the workspace, updating the payment method, still just need the admin's own authorization. There's no second person whose access shifts when those change.
We didn't need the admin to trust the agent more. We needed everyone else in the account to have a way to notice it.
The lesson: a permission model that only asks "who turned this on" is really only half a permission model. The other half is "who else does this touch, and can they do anything about it."
Now here is the same thing as a story
The short version above is what you'd say defending this design to Northfield's product council. Read this one for how the gap actually got found.
Farah Haddad has led customer support at Northfield for six years. She reads every escalation herself before assigning it, because patterns show up in the ones nobody else notices.
The permission model only ever named the person on the left.
The billing agent shipped in the fall, and for months the savings were real and the escalations were rare. Then, in February, a teammate named Rina Okoye tried to log in on a Monday morning and found her seat downgraded to view-only. She'd been on unplanned leave for three weeks covering a family emergency, and the agent had read three weeks of zero logins as an unused seat.
The fourth box in this pipeline was empty. Nothing sat there at all.
Rina hadn't done anything wrong. She emailed her admin, who hadn't even noticed the downgrade happen, since the agent's changes didn't surface to him unless he went looking. It took two days and a support ticket to Farah's team to restore her access, and by then she'd missed a client review she needed edit rights for.
Every one of these signals looks at usage. None of them ask whether the person is simply away.
Farah's team traced it back to the actual design gap: the agent's authorization chain started and ended with the admin. Rina was never a party to the permission at all, just something the agent's actions happened to.
Two of these four parts didn't exist before Rina's case. They exist now.
The redesigned model adds a direct notice to anyone whose seat is about to change, and a 48-hour window where they can restore their own access with one click, no admin involvement needed.
Only one branch skips the notice. When it's unclear, the model defaults to notifying anyway.
Replayed under the new model: the same three weeks of inactivity get flagged, but Rina gets a message the moment the downgrade is proposed, with a link to restore it herself. She's back on her family emergency and doesn't see the message for four days, but the grace window holds it open for her, and she restores her own seat in ten seconds the moment she does check her email, well before any client review is missed.
I built the single-admin authorization because it matched how we'd always thought about accounts: one buyer, one set of settings. It took watching Rina lose real work over a decision she never even knew was being made to see that an account is never really one person, no matter how the contract is signed.
GUARD, with a second person in itFive letters. The A step, ability to contest, is the one most permission models skip entirely.
G
Groups. Who's affected, named.
The account admin, who authorizes the agent. The teammate on the account, whose seat the agent can change without ever asking them.
Puts a second, less obvious person in the room before the design starts.
U
Unequal. Where the harm actually lands.
The admin never notices a downgrade happen. The teammate loses access mid-task and has to escalate just to get it back.
States the asymmetry plainly instead of treating "the account" as one undifferentiated unit.
A
Ability to contest. Who never gets a lever.
Rina couldn't appeal to the agent, wasn't consulted first, and found out only once her access was already gone.
The strongest move in the whole framework, and the one this model was missing entirely.
R
Reduce. The specific design change.
Any action that shrinks someone else's own access gets a direct notice to them, plus a 48-hour self-serve window to reverse it.
A real product decision, not a policy statement.
D
Detect. How you'd know in production.
Track the share of seat actions with zero advance notice to the affected person. It should be near zero, and if it climbs, the model's broken somewhere.
Turns "we designed a fix" into something you can actually watch.
Seat actions taken with zero advance notice (percent, monthly)
This is the detect step made visible: the redesign didn't just add a feature, it moved a real number from 62 percent to 4 percent.
The recap, one line per letter: groups is the admin and the teammate, unequal is the admin never noticing while the teammate loses access, ability to contest is Rina having no lever before the redesign, reduce is the notify-and-grace-window addition, and detect is watching the zero-notice rate fall from 62 to 4 percent.
And if you want to be sure it really works, try it somewhere elseSame five letters, a family telehealth account instead of a workspace seat. A completely different field, and the second person is a patient, not a teammate.
Meridian Family Health runs a patient-portal agent that manages appointments and refill authorizations across a shared family account: a parent account holder and their dependents.
Mapped onto GUARD: groups are the parent, who manages the shared account, and a dependent, often a teenager old enough to want their own say over their care. Unequal is that the agent can cancel a dependent's own appointment or change a refill authorization on the parent's instruction, and the dependent finds out only when they show up to a canceled visit. Ability to contest is the dependent having no way to flag "I still want this appointment" back to the agent directly, since the agent only takes instructions from the parent's login. Reduce is a direct notice to the dependent's own device for any change to their specific care, plus a short window where they can flag it for a human nurse to review, separate from the parent's authorization. Detect is tracking how often a dependent's flagged objection actually gets a human review within the same day, not just logged and forgotten.
Sharing records with a new provider sits in the worst corner: hard to undo, and the dependent has almost no say in it at all.
Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "name both people in the account, the admin and whoever else the agent's actions land on, and give the second one a real lever," and stop.
Cost: there's no budget this quarter for a full notification system. Say so honestly, and start with a single email alert on any seat downgrade, since even a plain email beats total silence.
The model gets better, for real: if the agent's usage-detection accuracy improves to near-perfect, that's still not a reason to drop the notice, since even a correct downgrade can land on someone who was simply away, not someone who was actually done with the seat.
Where people run it wrong.
They design the permission model around the person who pays, and never ask who else the actions touch.
They treat a notice after the fact as equivalent to a real lever before the change is final.
They build the contest path once and never check whether anyone flagged actually gets a timely human look.
How to use it live. If you get stuck designing a permission model live, ask one question first: whose access does this action actually change, and were they anywhere in the room when it was authorized? If the answer is "no," you've found the person the model is currently failing.
Flashcards (tap any card to flip it)
1 · THE FRAMEWORK
What framework fits "describe the permission model for an agent acting in a user's account"?
Tap to flip
ANSWER
GUARD: groups, unequal, ability to contest, reduce, detect. It names the second person the agent's actions land on, not just the admin.
2 · THE PEOPLE
Who is this answer about?
Tap to flip
ANSWER
Farah Haddad, head of customer support at Northfield Software, and Rina Okoye, the teammate whose seat got downgraded while she was on leave.
3 · THE MODEL
What's the actual permission model, in one sentence?
Tap to flip
ANSWER
Admin authorization lets the agent act on the account. Any action shrinking someone else's own access also needs a direct notice to them and a self-serve 48-hour grace window.
4 · ABILITY TO CONTEST
Why couldn't Rina push back before the redesign?
Tap to flip
ANSWER
She was never part of the authorization chain at all. The agent only answered to the admin, so she found out only after her access was already gone.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Building the permission model around a single admin authorization, since it matched how accounts were always described: one buyer, one set of settings.
6 · THE NUMBER
Fill in the blank: before the redesign, ___ percent of seat actions happened with zero advance notice to the affected person.
Tap to flip
ANSWER
62 percent. That fell to 4 percent within six months of the notify-and-grace-window redesign.
7 · THE REPLAY
Same three weeks of inactivity, redesigned model. What changes for Rina?
Tap to flip
ANSWER
She gets notified when the downgrade is proposed, and restores her own seat in ten seconds once she checks her email, days before any client work is missed.
8 · CROSS PRODUCT TRANSFER
Section 4 answers this again for a different product. Which product, and who's the powerless subject there?
Tap to flip
ANSWER
Meridian Family Health's patient portal agent. The powerless subject is the dependent, whose own appointments and refills the parent's login can change without them.
Check yourself Score: 0 / 0
True or false
1. True or false: in this permission model, changing the account's billing address needs the same notice-and-grace-window treatment as downgrading a teammate's seat.
True
False
Show hint
Look at "what I would leave alone."
Show answer
False. Admin-only settings with no second person affected, like a billing address, only need the admin's own authorization.
Multiple choice
2. Why couldn't Rina contest her seat downgrade before it happened?
A. She didn't know how to use the support ticket system.
B. Her admin actively denied her request.
C. She was never part of the authorization chain, so the agent only answered to the admin, not to her.
D. The agent's diagnosis of her seat as unused was factually wrong.
Show hint
Look at the "ability to contest" step.
Show answer
C. The permission model only named the admin. Rina had no lever at all until support restored her access after the fact.
Fill in the blank
3. Fill in the blank: after the redesign, the zero-notice rate fell from 62 percent to ___ percent within six months.
Show hint
Look at the line chart tracking zero-notice seat actions over time.
Show answer
4 percent. That's the "detect" step made visible as a real, falling number.
Short answer, name the reversal
4. What old decision does this answer take back, and why did it make sense when it was made?
Show hint
Look at "the decision I would take back."
Show answer
Model answer: Building the permission model on a single admin authorization. It made sense because admins are the ones who buy and manage the account.
Short answer, where it wouldn't matter
5. Name an action inside this account where the notice-and-grace-window model genuinely wouldn't matter.
Show hint
Look at "what I would leave alone."
Show answer
Model answer: Updating the account's payment method or renaming the workspace. Both are admin-only settings with no second person whose access shifts.
Short answer, apply it yourself
6. Pick a shared account you're on, a family plan, a shared workspace, anything. Who's the admin, and who's the person whose access could change without them being asked?
Show hint
Think about who pays for it versus who else actually uses it day to day.
Show answer
Model answer: A common one: a family streaming plan, where the paying parent is the admin and a sibling's profile or device access could be changed without that sibling ever being consulted.
Before you close the answer
Why this works
Tests whether you'll design a permission model around every real person the agent's actions touch, not just the one person who clicked "enable," and whether you can name a concrete lever for the person who currently has none.
Follow-up traps
"Doesn't a 48-hour grace window just slow down the cost savings?" Response: slightly, but the savings are still real once the window closes, and the alternative is a customer escalation and a support ticket that costs more time than the window ever does.
"What if the admin doesn't want teammates able to override their decisions?" Response: the grace window only restores the affected person's own access, it doesn't undo the admin's broader plan choice, so it protects the individual without overriding the admin's actual authority.
If pressed
Northfield's actual grace-window design also checks for an active out-of-office status before flagging a seat as unused at all, so a known leave, not just Rina's after the fact, stops the downgrade from ever being proposed in the first place.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
