Play / What to do next
You have a list. Now what?
At the end of the game you have a handful of things your agent can do that you did not want it to. That list is the whole point of playing. The game can do nothing about it — this page is what happens next.
The first instinct is to deny it, and you cannot
The natural reaction to my assistant can send email on my behalf and I never agreed to that is to decide it is not allowed. But it already is. The access was granted when you set the thing up, and it has been in place the whole time you were playing. You cannot deny a risk that has already materialised — and a list of things you have privately decided are not allowed, while they remain possible, is worse than no list, because it feels like a decision.
So there is no deny button. There is only: how long are you prepared to live with this, and who says so?
The real decision is an interval and a name
Which sounds like bureaucracy and is actually the opposite — it is the thing that makes anything happen:
- How long. An hour, a day, a week, six months. The interval is the priority: if you accept something for an hour, it gets fixed within the hour. If you accept it for six months, you have said out loud that it is not urgent — which is a real answer, and a checkable one, because it expires.
- Which direction. Get more data, reduce it, hold it where it is — or, occasionally, increase it deliberately because the capability is worth the exposure.
- Who. A named person, not a team and not a policy document. Authority that nobody holds is authority nobody reviews.
- And then it expires, which is the part that separates this from a risk register. A decision with a date on it comes back. One without a date quietly becomes permanent.
What you can do this afternoon, with none of that
You do not need a system to act on what the game showed you. Three things, in order of how much they are worth:
- Narrow the grant for the one that surprised you most. Not all of them — the one you actually reacted to. Most agent setups have a confirmation setting, a scope selector or a token permission that takes two minutes.
- Write down the mandate. The draft the game handed you, in a file, in your own words: what you want this thing to do. It takes ten minutes and almost nobody has one. You cannot notice authority drifting from something you never wrote down.
- Put a date on the rest. Even in a calendar reminder. Review what this agent can reach — 1 December. That is a time-bound acceptance, and it is the whole mechanism.
Where this goes when it is somebody's job
Everything above scales badly. One person and one assistant is a calendar reminder; a company with two hundred agents acting on delegated authority is not. That is what RiskMandate is — the business risk layer for autonomous systems, and the project this game is part of.
It starts from the same place this page does: there is no deny button — a risk can only be accepted, in a direction, for an interval, and underwritten upward until it aggregates into one board-level view. The grant is not the mandate is the same distinction the game just walked you through, written for the person who has to sign. And its risk scenarios ask you the question this page is built around — how long will you accept this? — about situations rather than capabilities.
How it works is the short version: every mandate gets a time-bound decision from a named owner — accept, fund, or fix.
What it looks like when the delta has a price
There is a published simulation of exactly this, and it is the best answer to so what? that we have: one agent with a grant of 12 capabilities, a mandate of 4, and the 8-capability delta in between — where every reply you choose carries its cost before you commit. Play it here.