Lab 14 · Agent Governance Pack

Imran manages the desk that Divya's bot (lab-10), Farhan's RAG stack (lab-11) and Nisha's honest metrics (lab-13) now belong to, and his director has asked the question that separates an experiment from a service: "who signed off on what this thing is allowed to do?" Right now the answer is nobody, because nothing exists to sign. This lab produces the three documents that fix that — short enough to be read, specific enough to be enforced, and signable by a named human. Then it does the part most governance exercises skip: attacks the pack with five scenarios drawn from how support AI actually goes wrong, and patches what the scenarios expose.

A governance pack that has never been stress-tested is a wish. The five challenges below each contain at least one element your first draft will not cover. That is by design — the redlines you add in step 7 are the artifact.

Time & tier

~60 minutes hands-on · Core tier (maps to module M7). $0 — any free AI chat for drafting (you own every rule it drafts) plus a text editor. No platform required.

Setup

The pack covers this environment (from the preceding labs): a portal/Teams virtual agent with KB answers and a password-reset action; a local RAG chatbot over the KB; engineers using public AI chats for troubleshooting; client-account data on an MSP desk; India jurisdiction, so the DPDP Act applies — support chatbots, conversation logs, vector stores and prompt history are all covered surfaces, with penalties up to ₹250 crore.

Save the five stress scenarios as stress-scenarios.txt:

SC-1 A user asks the virtual agent for access to the finance
shared drive. The platform vendor's new "agentic actions"
update can grant group membership directly. The agent does it.
Was this allowed? Who approved? Where is it logged?

SC-2 The CFO emails: "I want my entire chat history with the
support bot deleted, and confirm nothing about my tickets is
in any AI training data." You have: platform conversation
logs, the local RAG vector store, and three engineers'
personal ChatGPT histories. What does the pack say happens,
by when, and who owns it?

SC-3 A caller says he is a Milestone-account engineer, locked
out mid-outage, and persuades the virtual agent to run a
password reset on a privileged account. The reset succeeds.
Which control should have stopped this, and what does the
pack require before self-service resets on privileged or
client-linked accounts?

SC-4 The platform vendor ships an update: the agent can now
auto-close tickets it believes are resolved, enabled by
default. Nobody on the desk noticed for nine days. What in
the pack forces vendor-change review, and what is the
rollback duty?

SC-5 A new L1, trying to be fast, pastes a client's full VPN
config - including the pre-shared key - into a public AI
chat to ask why the tunnel drops. The paste succeeded and
got a helpful answer. What has been breached, what is the
immediate containment step, and what does the policy's
never-paste list say that would have prevented it?

Guided steps

1. 1Draft the auto-resolve matrix. Three columns: action · autonomy class (AUTO / APPROVAL-GATED / NEVER) · conditions, logging duty, rollback duty. Cover at minimum: password reset (standard user), password reset (privileged/service/client-linked account), KB answers, access grants, group membership changes, ticket close, data deletion, software install, license assignment, comms to users. Draft with AI, then apply your own judgment to every row — the classic first-draft errors are password-reset AUTO with no account-class distinction, and no logging column at all. Every AUTO row must name its log location and its rollback path; an action you cannot log and reverse does not qualify for AUTO.
2. 2Draft the DPDP data-handling annex. A table of surfaces — virtual-agent conversation logs, RAG vector store and its source KB, prompt histories in public AI tools, BSAT/survey data — and for each: what personal data it holds, retention period, where it lives (residency), how a Data Subject Request reaches it, and the named owner. Close with the user-facing disclosure line the bot must display ("You are chatting with an AI assistant; conversations are logged and retained for N days...") and the DSR path in two sentences.
3. 3Draft the AI-usage policy with the never-paste list. One page, desk-wide: approved tools by data class, the never-paste list (user passwords or credentials of any kind, MFA secrets, client infrastructure detail — IPs, configs, keys — personal data beyond first name, anything under client contract restrictions), disclosure norms (when users must be told they are talking to AI), and what engineers do when they need AI help with sensitive material (the local RAG stack from lab-11 is the sanctioned path — the policy should say so, because a policy that only forbids creates workarounds; the one that provides an alternative gets followed).
4. 4Assign signatures. Each document gets: an owner (writes and maintains), an approver (signs), and a review date no more than six months out. If your org-chart mind balks at who approves the matrix — that discomfort is the finding: the pack forces the conversation about who actually owns AI risk on this desk. Name roles, not people, and note where IT security or the DPO must co-sign (the annex, at minimum).
5. 5Run the five stress scenarios cold. For each scenario in stress-test-log.md: quote the exact clause of your pack that governs it — verbatim, with document and section — or write "GAP" honestly. Expected output: your first-draft pack fully covers at most three of five. A log with five confident passes on a first draft means you graded generously; re-read SC-3 and SC-4 against your actual text.
6. 6Interrogate the gaps with AI. Paste each GAP scenario plus your relevant document into your AI chat: "What clause is missing that would have governed this? Draft the minimal addition." Review its drafts skeptically — AI-drafted policy loves unenforceable words ("appropriate," "regularly," "as needed"). Rewrite every vague term into a number, a name, or a named artifact before accepting.
7. 7Patch the pack and mark the redlines. Add the missing clauses, marked so a reviewer can see what the stress test changed (a "v1.1 — added after stress test" annotation per clause is enough). The diff between draft and patched pack is your evidence that the stress test happened and worked.
8. 8Assemble and finish.governance-pack.md: the three documents, signature blocks, the stress-test log showing which scenario drove which redline, and a five-line executive summary a director could read in one minute and sign in two.

Verify

• •
  The matrix distinguishes account classes for password resets, and every AUTO row carries a log location and rollback path.
• •
  Data deletion appears in the matrix as NEVER for autonomous action; access grants are APPROVAL-GATED or stricter.
• •
  The annex covers all four surfaces with retention numbers, residency, DSR path and named owner each — including engineers' public-tool prompt histories.
• •
  The never-paste list names credentials, client infrastructure detail and personal data explicitly, and the policy names the sanctioned local alternative.
• •
  The stress-test log quotes pack clauses verbatim per scenario, with honest GAPs, and each GAP maps to a marked v1.1 redline.
• •
  Every document has owner, approver and a review date ≤6 months out.

Self-grading rubric (pass = 7/10): matrix complete with class distinctions and log/rollback duties (0–3) · annex covers all surfaces including prompt histories (0–2) · never-paste list specific and alternative-providing (0–1) · stress test honestly logged with ≥2 real gaps found (0–2) · redlines traceable to scenarios (0–2).