Before an AI agent can publish or message customers, what should its permission card contain?

The dangerous moment with an AI agent is not when it writes an awkward sentence. It is when it has permission to complete the wrong action before a person notices. I have been testing a short "authority card" for any agent that can publish, message, schedule, change records, or move files. Mine currently has seven lines: Objective: the exact result it is supposed to produce. Allowed data: the records, fields, folders, or sources it may read. Allowed tools and actions: reading, drafting, editing, uploading, and publishing are separate permissions. Prohibited actions: the things it must never do even if they look efficient. Stop condition: the mismatch, missing approval, or ambiguity that ends automation. Human owner: the person accountable for the workflow and the final irreversible decision. Audit record: which identity acted, what changed, and how the result was verified. The part I underestimated was the failure drill. A clean demonstration only proves the happy path. Before expanding access, I now want the system tested with a false claim, private information, conflicting instructions, and a request outside its authority. The correct result is often a refusal or human escalation, not a polished answer. I also think draft, upload, and publish need to remain three different actions. A workflow that can prepare a post does not automatically need the credential that can release it publicly. Where would you tighten this? Is there a missing line you have found necessary in production, or is seven already too much for people to use consistently? Affiliation disclosure: I host AI With Honor and developed this framework while turning one of my recorded episodes into a practical operating checklist. This post contains the complete framework rather than a promotional teaser.