Acceptable Use Policy (AUP)
The rulebook listing what users may not do with a product, from spam and harassment to malware, fraud, rights violations, and resource abuse.
What it is
An acceptable use policy names the behavior and content a service prohibits: illegal activity, harassment, malware, credential theft, spam, rights violations, attempts to bypass limits, and other abuse relevant to the product. It usually sits beside the terms of service, which make the policy binding and state the service's power to investigate, restrict, suspend, or terminate accounts.
Reach for an AUP when customers can upload content, send messages, call an API, consume shared infrastructure, or affect other users. Write rules that map to things reviewers and detection systems can actually observe, then connect each rule to evidence, severity, notice, appeal, and an enforcement range.
Gotcha: 'anything we dislike, at our sole discretion' is not an operating policy. It gives users no warning and moderators no consistency. Another trap is banning all security testing while inviting vulnerability reports; publish a narrow authorized-research path so good-faith testing does not look identical to an attack.
Ask AI for it
Draft an Acceptable Use Policy for the product described below and turn it into an enforcement matrix. Cover illegal activity, child exploitation, harassment and threats, privacy and intellectual-property violations, malware, phishing, credential abuse, spam, deceptive automation, attempts to bypass access or rate limits, dangerous content relevant to the product, and excessive resource use. For each rule, give concrete examples, required evidence, severity, warning or suspension range, appeal route, and emergency escalation. Add an authorized security-research carveout linked from an RFC 9116 security.txt file. Make the Terms of Service incorporate the policy by URL and version, and mark product-specific legal judgments as bracketed TODOs for counsel.