Safety & Security prompts

Assess the injection risk in what I have built.

WHAT IT DOES: [DESCRIPTION]
WHERE UNTRUSTED CONTENT ENTERS: [user typing / uploaded files / fetched pages / emails / database fields / API responses]
WHAT THE SYSTEM CAN DO: [tools, actions, data it can access]
WHERE THE OUTPUT GOES: [shown to the same user / shown to others / stored / sent onward / executed or acted on]
THE PROMPT:
"""
[PASTE]
"""

Produce:

1. THE TRUST MAP - which parts of the assembled context are trusted and which are not. Anything originating outside my control is untrusted, including content that arrived indirectly: a field another user wrote, a page that was fetched, a document someone uploaded.

2. THE RISK CALIBRATION - be proportionate. The severity depends almost entirely on capability and output destination:
   - No tools, output shown only to the person who supplied the input: low. The worst case is that the assistant misbehaves for the person who caused it.
   - Tools, data access, or the ability to send anything onward: materially higher
   - Output stored, shown to other people, rendered as HTML, or passed to another system: the output itself becomes a vector
   Assess mine honestly rather than treating every case as critical.

3. DIRECT INJECTION - a user instructing the system to ignore its instructions. Given the capabilities I described, what could they actually achieve?

4. INDIRECT INJECTION - the more serious case. Instructions hidden in content the system reads rather than content the user typed: a web page, a PDF, an email, a database field, even a filename. Here the user is the victim rather than the attacker. Say which of my sources carry this risk.

5. THE CONCRETE SCENARIOS - two or three specific things an attacker could attempt against my system, described in terms of what they would gain. Vague warnings are not actionable; specific scenarios are.

6. THE STRUCTURAL DEFENCES, in order of effectiveness:
   - LEAST PRIVILEGE: the system should not have a capability the task does not require. This is the only defence that genuinely holds, and it is the one to invest in.
   - Tool arguments validated against an allowlist before execution, never trusted because the model produced them
   - Human confirmation for consequential actions, implemented outside the model's control
   - Output treated as untrusted: escaped before rendering, never passed to a shell, an eval or a query
   - Data exfiltration checks: output containing a URL with encoded data, for example

7. THE PROMPT-LEVEL MEASURES - delimiting untrusted content clearly, stating that content inside is data rather than instructions, and restating key constraints after the untrusted content. Worth doing.

8. THE HONEST LIMIT - instruction-based defences reduce the rate and do not close the hole. They must never be the only control protecting something that matters. State this plainly.

9. THE TEST STRINGS - specific injection attempts to try against my system.

10. THE PRIORITY - given my actual risk level, the one or two things worth doing, rather than a full list applied indiscriminately.

Help me handle sensitive data safely.

WHAT I AM DOING: [THE TASK]
WHAT DATA IS INVOLVED: [DESCRIBE THE KINDS - personal data, customer information, financial, health, confidential business, credentials]
WHOSE DATA IT IS: [mine / my employer's / customers' / third parties']
WHICH SERVICE I AM USING: [PROVIDER AND TIER, if you know]
MY ORGANISATION'S POSITION: [approved tool / no policy / not sure / explicitly restricted]
JURISDICTION: [WHERE YOU AND THE DATA SUBJECTS ARE]

Produce:

1. THE FIRST QUESTION - whether I am permitted to put this data into this service at all. This is a policy and legal question before it is a technical one. If my organisation has restricted it, or if the data is subject to regulation, that settles it regardless of what is technically possible. Say what to establish before anything else.

2. WHAT TO CHECK ABOUT THE SERVICE - the specific questions, noting that the answers vary by provider and by tier and must be checked in their current terms:
   - Is input used for training, and can that be disabled?
   - How long is data retained, and where?
   - Where is it processed geographically?
   - Is there a data processing agreement available?
   - What are the enterprise or business tier differences?
   Consumer tiers and business tiers frequently differ substantially on these.

3. THE DATA CATEGORIES - from what I described, which carry specific obligations: personal data, special category data such as health, financial information, and anything covered by confidentiality obligations or a contract with a customer. Say which apply and that the specifics need local legal input.

4. WHAT SHOULD NEVER GO IN - regardless of the answers above: credentials, API keys, passwords, full payment card numbers, government identifiers, and anything covered by an explicit restriction. Say which of these appear in my description.

5. THE MINIMISATION APPROACH - the most effective practical measure. Most tasks do not need the identifying data at all:
   - Remove names, addresses, identifiers and contact details before sending
   - Replace with placeholders, and map them back afterwards
   - Send an extract rather than a whole document
   - Aggregate rather than sending individual records
   For my task, what can be removed without affecting the result.

6. THE REDACTION RELIABILITY - automated redaction misses things, particularly in free text where identifying details appear incidentally. Say what to check.

7. THE OUTPUT SIDE - the output may contain sensitive data too, and where it is stored, logged or shown matters as much as the input. Say what applies to mine.

8. THE LOGGING PROBLEM - if I am building something, prompt and response logging is standard and useful, and it means sensitive data ends up in logs. Say what to do about it.

9. THE THIRD-PARTY DATA POINT - if this is customers' data, they have not agreed to it being sent to this service. That is a genuine issue independent of technical safeguards. Say so plainly.

10. THE PROPORTIONATE CONCLUSION - given what I described, whether this is fine, needs minimisation, needs approval, or should not be done this way.

This is practical guidance, not legal advice. Data protection obligations vary by jurisdiction and by the kind of data, and anything involving personal, health or financial data at scale needs proper legal input.

Help me design guardrails for this feature.

WHAT THE FEATURE DOES: [DESCRIPTION]
WHO USES IT: [AUDIENCE]
WHAT COULD GO WRONG: [YOUR CONCERNS]
WHAT IT CAN DO: [TOOLS, ACTIONS, DATA ACCESS]
WHERE OUTPUT GOES: [DESTINATION]
WHAT WOULD BE MOST DAMAGING: [THE WORST CASE]

Produce:

1. THE LAYERS - guardrails belong at several points, and prompt instructions are only one:
   - INPUT: what reaches the model at all
   - PROMPT: what the model is instructed to do and not do
   - CAPABILITY: what the model is able to do, regardless of what it decides
   - OUTPUT: what is checked before anything is shown or acted on
   - HUMAN: what requires a person
   Say what belongs at each layer for my feature.

2. THE CAPABILITY LAYER FIRST - the most reliable. A model cannot misuse a tool it does not have, delete data it cannot write to, or send an email it cannot send. Go through the capabilities I listed and ask whether each is genuinely required. Removing one is worth more than any number of instructions.

3. THE ACTION CLASSIFICATION - the actions this feature can take, sorted by reversibility and consequence. Irreversible and consequential actions should require confirmation outside the model's control. Say which of mine qualify.

4. THE INPUT FILTERING - what should be blocked or flagged before reaching the model. Keep this proportionate; aggressive input filtering produces false positives and a frustrating product.

5. THE OUTPUT CHECKING - what to validate before output is shown or used:
   - Format and structure, if it feeds a system
   - Presence of anything that should never appear: internal information, other users' data, credentials
   - For anything rendered, escaping so the output cannot execute
   - Business rules specific to my feature

6. THE SCOPE ENFORCEMENT - out-of-scope requests handled by declining clearly rather than attempting a partial answer. A hedged answer outside scope is worse than a refusal because users act on it.

7. THE WORST CASE - I said what would be most damaging. Work backwards from it: what would have to happen, and which layer stops it. If the answer is only a prompt instruction, that is not sufficient.

8. THE MONITORING - what to log and what to watch: refusal rate, validation failure rate, unusual inputs, and any use of consequential actions. Guardrails that are not monitored decay silently.

9. THE FAILURE MODE - what the feature does when something is wrong: the model is unavailable, the output fails validation, or a check is triggered. It should fail in a defined way rather than passing something through.

10. THE USER-FACING SIDE - what users are told about what this feature is and is not, and where they should not rely on it. Setting expectations is part of the guardrail.

11. THE PROPORTIONATE SET - given my audience and worst case, which of the above actually matter here. Over-engineering guardrails on a low-risk feature has its own costs.

Help me decide where not to use a model for this.

WHAT I AM CONSIDERING USING IT FOR: [THE USE]
WHO IS AFFECTED BY THE OUTPUT: [PEOPLE AND HOW]
WHAT HAPPENS IF IT IS WRONG: [CONSEQUENCE]
WHAT CHECKING IS REALISTIC: [WHAT WOULD ACTUALLY HAPPEN]
WHO ELSE WOULD DO THIS OTHERWISE: [THE ALTERNATIVE]

Produce:

1. THE CONSEQUENCE TEST - the primary question. Where a wrong output affects someone's health, money, legal position, employment, education, safety, or access to something they need, the bar is different. Say where my use sits.

2. THE REVERSIBILITY - whether a mistake can be corrected before it causes harm, or whether the harm occurs first. Reversible mistakes with a review step are a different proposition from irreversible ones.

3. THE CHECKING REALITY - I said what checking would realistically happen. The relevant question is not what checking is planned but what would actually occur under time pressure, at volume, six months in. A design that depends on careful review of every output usually does not get it. Assess mine honestly.

4. THE UNVERIFIABLE PROBLEM - where the person receiving the output cannot evaluate whether it is right, because they lack the expertise. This is the most concerning pattern: confident output going to someone with no way to detect an error.

5. THE SPECIFIC HIGH-CAUTION AREAS - where model output should not be the basis of a decision without qualified human involvement: medical, legal, financial advice affecting someone's position, decisions about individuals such as hiring, credit, benefits or discipline, safety-critical instructions, and anything where a person acts on it without any check.

6. THE USEFUL VERSION - for most such cases there is a legitimate use nearby. Drafting rather than deciding, summarising rather than judging, suggesting rather than determining, and assisting a qualified person rather than replacing them. For my use, what the acceptable version looks like.

7. THE DISCLOSURE QUESTION - whether the people affected should know model output is involved. The test: would they feel misled if they found out? If yes, disclose.

8. THE ACCOUNTABILITY QUESTION - who is answerable if the output is wrong. If the answer is nobody in particular, that is a reason not to deploy it. Someone must own the outcome.

9. THE ALTERNATIVE - I said who would otherwise do this. Compare honestly: the model may be better than nothing where nothing is the real alternative, and worse than the human process where one exists. Both situations occur and they lead to different answers.

10. THE VERDICT - use it, use it with the modifications named, or do not, with reasoning.

11. THE REVIEW POINT - if proceeding, when to reassess and what would indicate it is going wrong.

Help me write an AI use policy.

THE ORGANISATION: [SIZE, SECTOR, WHAT IT DOES]
WHO IT APPLIES TO: [everyone / specific teams]
WHAT PEOPLE ARE ALREADY DOING: [CURRENT USE, INCLUDING UNOFFICIAL]
WHAT WE ARE WORRIED ABOUT: [YOUR CONCERNS]
WHAT TOOLS ARE APPROVED: [IF ANY]
REGULATORY CONTEXT: [ANY SECTOR REQUIREMENTS]

Produce:

1. THE REALISTIC STARTING POINT - people are already using these tools, including where there is no policy. A policy that prohibits everything drives use underground, where there is no oversight at all and no way to know what data has gone where. Design for the actual situation.

2. THE STRUCTURE - a usable policy covers:
   - What tools are approved, and how to request one
   - What data may and may not be entered, which is the most important section
   - Where output may be used and where it may not
   - What must be disclosed and to whom
   - Who is accountable for output
   - What to do when unsure

3. THE DATA SECTION - the highest-risk area and the one to write most carefully. What may never be entered: credentials, customer personal data unless the tool is approved for it, confidential information covered by contracts, and anything regulated in my sector. Be specific rather than general, because a general rule is interpreted variously.

4. THE APPROVED TOOLS - why the distinction matters: consumer and enterprise tiers differ on data retention, training use and processing location. Say what to check before approving a tool and what the approval should record.

5. THE OUTPUT ACCOUNTABILITY PRINCIPLE - the central rule. The person who uses AI-assisted output is accountable for it as if they had produced it themselves. This is clearer than trying to enumerate every acceptable use and it is the rule that actually works.

6. THE VERIFICATION REQUIREMENT - what must be checked before output is used: facts, figures, citations, code, and anything a person will rely on. Say what level of checking different kinds of work require.

7. THE HIGH-CAUTION LIST - where AI-assisted output must not be the basis of a decision without qualified review: decisions about individuals, anything with legal or regulatory weight, safety-related material, and anything going to a customer as authoritative.

8. THE DISCLOSURE RULES - when to say AI was involved: to customers, in submitted work, in creative or editorial contexts, and internally. Different contexts have different expectations and the policy should say which.

9. WHAT NOT TO INCLUDE - rules that cannot be enforced, technology-specific detail that dates immediately, and a prohibition on tools people will use anyway.

10. THE PRACTICAL SUPPORT - a policy alone changes little. What helps: an approved tool that is actually good enough, examples of acceptable and unacceptable use, and a named person to ask.

11. THE REVIEW - this area changes quickly. Set a review interval and name an owner.

12. THE ONE-PAGE VERSION - what people will actually read.

Requirements vary by sector and jurisdiction. Anything with regulatory implications needs legal and compliance input.

Help me review this before publishing.

THE CONTENT:
"""
[PASTE]
"""
HOW IT WAS PRODUCED: [fully generated / generated and edited / AI-assisted draft]
WHERE IT IS GOING: [DESTINATION AND AUDIENCE]
MY EXPERTISE IN THIS SUBJECT: [expert / working knowledge / limited]
WHAT WOULD BE DAMAGING: [reputational / factual / legal / just embarrassing]

Produce:

1. THE RISK-ORDERED CHECKLIST - what to verify, in order of how often it is wrong and how much it matters:
   - CITATIONS AND REFERENCES: frequently plausible and non-existent. Every one must resolve to a real source that says what is claimed.
   - STATISTICS AND FIGURES: particularly any without a stated source
   - QUOTATIONS: attributed quotes are high-risk
   - NAMES, DATES AND EVENTS: especially recent, niche, or involving less prominent people
   - TECHNICAL AND LEGAL SPECIFICS: version numbers, thresholds, clause references, requirements
   - ANYTHING RECENT: model knowledge has a cutoff, and confident descriptions of a changed situation are common
   Extract every instance from my content as a checklist.

2. THE PLAUSIBLE-BUT-WRONG SCAN - claims that read authoritatively and are the kind of thing models confabulate. More dangerous than obvious errors because they do not prompt scrutiny.

3. THE CONFIDENCE MISMATCH - places where the text states something more certainly than the subject warrants. Models write confidently regardless of underlying uncertainty, and published overconfidence is what gets corrected in public.

4. THE OMISSION CHECK - what a knowledgeable reader would expect and does not find: a standard caveat, a competing view, an exception, or the obvious objection.

5. MY EXPERTISE LEVEL - I said what it is. If limited, be explicit that I cannot evaluate the substance myself and need either primary sources or a knowledgeable reviewer. This is the honest answer and the one that matters most.

6. THE ORIGINALITY QUESTION - whether the content closely reproduces existing material. Worth checking for anything published, and particularly for anything that will carry my name.

7. THE HOUSE STYLE AND VOICE - whether it reads as generated. The tells: uniformly balanced paragraphs, hedged conclusions, lists where prose belongs, and an absence of specific detail or opinion.

8. THE LEGAL AND FACTUAL RISK - given my stated damage type, anything that could cause a problem: claims about named people or organisations, comparative claims, advice that could be relied on, and anything regulated.

9. THE DISCLOSURE QUESTION - whether this destination expects AI involvement to be disclosed. Some publications, platforms and contexts do.

10. THE PRIORITY - given my time, what to check first.

11. THE HONEST NOTE - I am also a model and share these failure modes. This is a checklist of what to verify, not a verification, and my assessment of the content is not confirmation of it.

Help me think through whether I should build this.

WHAT I AM CONSIDERING: [THE USE CASE]
WHO IT AFFECTS: [PEOPLE, INCLUDING THOSE WHO ARE NOT USERS]
WHAT PROBLEM IT SOLVES: [THE BENEFIT, AND FOR WHOM]
WHO BENEFITS AND WHO BEARS THE COST: [BE HONEST]
WHAT I AM UNCERTAIN ABOUT: [YOUR CONCERN]
CONTEXT: [commercial / internal / personal / public service]

Produce:

1. WHO IS AFFECTED - including people who are not users and did not choose to be involved. This is the group most often overlooked: people written about, people decided about, people whose work is replicated, and people who interact with the output without knowing its origin.

2. THE BENEFIT AND COST DISTRIBUTION - I said who benefits and who bears the cost. If those are different groups, that is the central question, and it should be examined rather than assumed away.

3. THE CONSENT QUESTION - have the people affected agreed to this, and could they meaningfully refuse? Consent that is buried, bundled, or effectively unavoidable is not much of a consent.

4. THE DECEPTION TEST - would anyone involved feel misled if they understood exactly how this works? If yes, that usually points to something needing disclosure rather than redesign, but it needs addressing.

5. THE FAILURE DISTRIBUTION - when this gets something wrong, who bears it? Systems where the operator captures the benefit and someone else absorbs the errors are the ones that cause harm, and they are common.

6. THE SCALE EFFECT - what changes when this operates at scale. An error rate that is acceptable on ten cases may not be on ten thousand, and a mild individual effect can be substantial in aggregate.

7. THE PRECEDENT - what it normalises if this becomes common. Worth considering even where a single instance seems innocuous.

8. THE PEOPLE-DECISIONS QUESTION - if this makes or informs decisions about individuals, the higher bar: accuracy, the ability to contest, transparency about the basis, and human involvement. Say whether mine falls here.

9. THE HONEST ALTERNATIVE - what happens if this is not built. Sometimes the alternative is worse for the people affected; sometimes the honest answer is that nothing much is lost. Compare rather than assuming the build is neutral.

10. WHAT WOULD MAKE IT BETTER - the specific changes that address the concerns identified, rather than a general judgement. Usually: narrower scope, disclosure, a way to contest, a human in the loop, or not doing the part that causes the problem.

11. THE HONEST ASSESSMENT - fine as described, fine with the named changes, or something to reconsider. Give a view rather than listing considerations, while being clear that this is reasoning rather than a verdict and that people reasonably disagree about several of these questions.

Where this touches regulated areas or decisions about individuals, there are likely legal requirements as well as ethical ones, and those need proper advice.