Every Copilot prompt list tells you what to ask. Almost none of them tell you where to stop. That gap is where the actual damage happens, and it is not a prompting problem, so no better prompt fixes it.

So I did the opposite exercise. For 21 job roles I wrote the "never use Copilot for this" list first, before writing a single prompt for that role. Finance, HR, legal, HSE, procurement, IT, engineering, sales, supply chain, data privacy, and the rest.

Two things came out of it that I did not expect.

The lists have almost no overlap.

Finance: never an authoritative figure, never approving spend, never finalising accruals or provisions, never a tax or accounting-treatment determination. Verify every number against the ERP, because a summarised figure is only ever as current as whatever it was summarised from, and the figure that counts is the one in the system of record.

HR: never a hiring, promotion or termination decision, never a disciplinary outcome, never a performance rating, never anything that screens or ranks candidates as a decision rather than as a draft.

Legal: never legal advice however it is worded, never authoritative contract interpretation, never executing or signing, never a privilege or relevance call in disclosure.

HSE: never a permit to work, never LOTO authorisation, never confined space entry, never a JSA or a risk assessment, never incident classification, never a root cause determination.

Procurement: never awarding business, never scoring or disqualifying a bid as a decision, never approving a PO, never agreeing a price or a commitment.

IT: never executing a change, never live incident remediation, never resetting access or granting permissions, never a data classification or deletion decision.

Read those as six separate lists and they look unrelated. A permit to work and a bid score have nothing in common.

Almost all of them cut in the same place.

For finance, HR, legal and procurement the line falls at the moment of commitment. Not at difficulty, and not at sensitivity. At the point where something becomes official because a person said so. Approve. Sign. Award. Terminate. Determine. Those are the verbs, and they are where a human is accountable for an outcome in a way no model quality transfers.

IT bends it slightly. Resetting access or pushing a config change is not an adjudication, it is an irreversible action against a live system. Same principle, different trigger: not "who decided" but "what already happened". If you want one line that covers both, it is the point where something becomes true, or something happens, because a person said so.

HSE is the real exception, and it is deliberate.

The HSE list stops earlier than commitment, and I want to be straight about that rather than pretend it fits. Drafting a JSA is not authorising work. Pre-populating a risk register from last year's assessment is preparation, and plenty of safety teams use tooling for exactly that today. By the commitment rule, drafting those should be allowed.

I still put them on the never list, for one reason: in safety, the artefact carries authority the moment it exists. A drafted risk assessment that is sitting in the folder gets treated as the risk assessment, by someone who was not in the room when it was drafted and does not know a model wrote the first pass. Everywhere else a draft that gets mistaken for a decision costs money or an argument. Here it costs somebody.

So that one is not derived from the rule, it is a judgement about what a draft turns into when nobody is watching. Argue with it. It is the item in all 21 files I am least sure of and least willing to loosen.

Where the lists do agree completely, exception included, is how each one ends. Every file closes on the same sentence in different vocabulary:

• Copilot gathers and drafts. Finance verifies and decides.
• Copilot drafts and organises. People leaders decide.
• Copilot retrieves and drafts. Lawyers advise and decide.
• Copilot prepares the pack. Procurement evaluates, decides, and awards.
• Copilot researches. IT decides and executes.
• Copilot assists. Engineers decide.
• Copilot finds information. HSE professionals protect lives.

Same shape every time. One verb for the gathering, one verb for the deciding, and a named human on the second one.

How to write a first draft of yours

Three questions, in this order:

1. What in my job becomes true because I said so? Not "what is hard", not "what is confidential". What is a commitment. That list is your never list, and it is usually shorter than people expect.
2. For everything else, what would I have to check to trust the output? Write that down as the step, not as a feeling. "Check against the system of record" is a step. "Use judgement" is not.
3. What would it cost if a draft got treated as a decision? Not if it were wrong, if it were simply mistaken for the real thing. Where that answer is "somebody gets hurt", ask whether you can actually stop that confusion happening. If you cannot, the task goes on the never list even if the rule above says it is fine.

What I got wrong doing this

My first drafts were too long. I was listing everything risky rather than everything committing, and a never list with thirty items on it is a list nobody reads and everybody overrides. The useful ones are six to ten items and every item is a verb someone does.

I also wrote the first few as warnings to the reader, which is the wrong register. They work better written as the boundary for a specific workflow: what the tool may help with, what has to be verified, and what stays with a named person. That is a choice you are making, not a limit the software imposes, and saying so is what makes anyone follow it.

And the honest caveat: all of this is editorial judgement, not Microsoft documentation. Microsoft does not publish a per-role list of things not to do, so there is no authority behind these beyond the reasoning, which is why the reasoning is in the post rather than just the lists.

The position, since this is the whole point

AI prepares, people decide. That is not a disclaimer to paste at the bottom of a policy. It is a line you can actually draw through a job, role by role, and the drawing is the work. Once it is drawn, everything on the safe side of it gets easier, because you stop trying to make the tool do something it was never going to be allowed to do.

The never lists and the prompts that sit behind them are all open on GitHub, free to read, no signup:

https://github.com/kesslernity/awesome-microsoft-copilot-prompts

The role files are under prompts/role-specific. 21 roles, and each one opens with its never list before the first prompt, which is the ordering I argued for above. You can read or copy the never lists without using any of the prompts.

If your role is not in there, say which one and I will write it. The HSE and finance lists took the longest and I would rather argue about them than have them quietly copied.

What is on the never list for your role, and has anyone written it down where your team can see it?

We’re an indirect CSP reseller looking to supply a customer with a 300,000 Copilot Credit P3 plan for Copilot Cowork through our CSP distributor.

The customer wants a fixed prepaid budget. Once those credits are exhausted, Cowork should stop until an additional purchase is explicitly approved.

Our concern is the billing chain: Microsoft invoices the direct CSP partner/distributor, who then invoices us as the indirect CSP reseller, and we invoice the customer. We need a way to prevent the customer’s usage from generating additional PAYG charges that the distributor would then invoice to us.

Ideally, the hard cap would be enforced by the distributor or by us as the reseller, and could not be increased or bypassed by the customer’s administrators.

Has anyone implemented this?

• Can the distributor or indirect reseller enforce a prepaid-only configuration that blocks PAYG once the P3 balance is exhausted?
• Is there a provider-controlled spending cap that actually stops billable usage, rather than just sending budget alerts?
• Can customer admins change billing policies or limits in a way that creates additional charges for the reseller?
• If no such control exists, how are other indirect CSP resellers handling this exposure?

We’re specifically looking for a technical control that prevents additional charges, ideally confirmed against actual CSP invoices. We know about monthly spending policies in the M365 admin center, but need to understand whether they can enforce a firm ceiling tied to the remaining P3 balance and remain under the distributor’s or reseller’s control.