Somebody on your team already did this.
Two people in sales, eight days ago, without asking, against the CRM. They had a subscription on a corporate card and a tool that solved their Tuesday. Nobody did anything wrong on purpose, and your name is on the register for the systems it touched.
Who's On the Hook is for the person who signs. Not the person who builds the agent, not the person who writes its instructions. The founder, the ops lead, the IT director, the security engineer who found out eight days late and now has to decide what happens next.
It answers four questions, in writing, on one page. What can it reach? What can it do without asking? What could I prove afterwards? What is my exposure? Every chapter contributes one line. The last appendix is the page.
You cannot fire this into a different security context, and you cannot ask it what it did last Tuesday. Everything in the book follows from those two sentences.
You will learn what an agent on your account can actually reach, which is every session anybody signed into on one shared machine, inherited with no authentication event and no record anywhere. How to check the confident wrong things your own team will tell you, using a four-minute test that produces a quotable sentence instead of an argument. How to name the adversary the vendor never named, and trace one poisoned support ticket through the product's real loop to the single step where a control could stop it.
Then the controls. Isolation you have to build outside the product, because it offers none, and which does double duty as the audit trail it does not have. Approval boundaries, and the verification step that proves yours are actually in force on a second machine. An inventory of the actions you cannot take back, each with a person's name against it.
And the three chapters nobody else has written. A five-phase incident playbook, timed, with no branches, because in the first hour you will not know what happened yet. How to reconstruct what an agent did when the product keeps twenty run records, offers no audit view, and leaves no trail on an edited message. How to govern spend against a meter that reports a percentage of a total the vendor has never published.
Written from the official documentation, read in full, and from using the product daily. Every claim about what the product is comes from a vendor page. Every claim about what other people ran into is dated and marked as such. The sharpest security argument in the book belongs to a stranger on a support forum and is credited to him in the text, not buried in a note.
No plan tables. No prices. No usage figures. No screenshots. Each of those changed while the book was being written. What you get instead is a dated errata page and a method for reading your own account.
It is also honest about the parts where the answer is not yet. Three of six candidate workloads come out excluded, each with the condition that would clear it. A book whose conclusion for half the work is wait is a hard thing to sell to the person asking. The alternative is to make the answer up.
