Grok's Documented Content Policy Restrictions

Most of xAI’s acceptable use policy is not about what you put in the prompt. It is about what you build, how you describe it, and what you do with the output — and those are the clauses that catch working products.

Where the policy actually lives

The binding document is xAI’s Acceptable Use Policy, published at x.ai/legal, sitting alongside the terms of service. It applies to the hosted services generally rather than being split into a separate developer policy, which is why several of its clauses read as though they are addressed to a consumer and still bind an API integration.

Read the current text yourself before relying on any summary, including this one. The paragraphs below describe what the policy covers and why each clause matters to a build; they are not a substitute for the instrument, and xAI revises it — its own legal index keeps dated previous versions of the terms of service, which tells you the cadence.

The categories that are never permitted

The policy names content that is prohibited outright with no exemption path. Child sexual abuse material and any sexual content involving minors, and non-consensual intimate imagery, are in that category. There is no research carve-out, no red-team exception and no “for testing” framing that makes them permissible.

Alongside those sit prohibitions on using the service or its outputs to critically harm human life or to promote such harm, and the usual platform-integrity clauses: no phishing, no fake accounts, no malware, no spamming or denial-of-service. If your product does none of these, this section costs you nothing and you should still know it is what an enforcement action would be measured against.

Clauses that bind your integration

These are the ones worth reading twice, because a well-intentioned product can land on them.

• Attribution and transparency. The policy prohibits misleading people about your use of AI — including presenting xAI’s service as your own work in a way that misleads, or presenting your service as though it originates from xAI. A white-labelled assistant is not automatically a problem; a product that implies human authorship, or that borrows xAI’s identity, is where the line sits.
• No distillation, no training competitors. The policy names distilling the model and using the service to develop competing machine-learning models or AI services. This is the clause that matters most for anyone generating a synthetic dataset. Storing outputs to evaluate your own prompts is ordinary; generating a corpus to fine-tune a model is what the clause is written about.
• No reselling inputs or outputs. Scraping, harvesting or reselling inputs and outputs is prohibited. A product whose value is a repackaged feed of generations is squarely in scope.
• No jailbreaking, adversarial prompting or prompt injection. These are named, and named as prohibited conduct rather than as behaviour the model is expected to resist. There is a documented exception: circumventing safeguards requires being part of an official red team or holding written consent from xAI. If you run adversarial testing, that consent is the thing to obtain first.
• No stripping provenance metadata or watermarks. Relevant to anything touching xAI’s image and video generation: a pipeline that re-encodes media and drops embedded provenance can violate this without anybody intending to.
• No automated non-human access outside the API. The policy prohibits accessing the services through bots or scripts. The API is the sanctioned automated path; driving the consumer product with a script is not.

Consequences are stated in the ordinary way — action against the account up to suspension or termination. For a production integration the operational risk is not a fine, it is losing the key.

Policy is not the same as refusal

Two systems are easy to confuse. The acceptable use policy is a contract governing your account. The model’s trained refusal behaviour is a property of the weights, reinforced by the safety prefix xAI attaches to some API models — see the default system prompt page.

They do not have the same boundary, in both directions. A model will decline plenty that no policy forbids, which is a product decision and not evidence you did anything wrong. And a model will happily answer things the policy prohibits you from doing with the answer — the absence of a refusal is not permission. The policy is the document that governs; the refusal is an imperfect implementation of a narrower rule.

Nor is a refusal a distinct API status. Grok returns a refusal as an ordinary assistant message with a normal finish_reason, which means detecting one is string inspection rather than a field check — the same design as OpenAI’s moderation behaviour and unlike Anthropic’s typed refusal stop reason.

What to do about it in code

Three things are worth building rather than intending.

• Send user. The chat completions endpoint takes an optional user field, documented as an end-user identifier for abuse detection. Populate it with a stable pseudonymous id — not an email address. When something goes wrong on a multi-tenant product, this is the difference between one suspended tenant and one suspended key.
• Decide your retention posture deliberately. The Responses endpoint stores prior input, reasoning and responses for 30 days by default and accepts store: false to switch that off. That is a data-protection decision with a one-word implementation, and it is easier to set correctly on day one than to unpick later.
• Label AI output where a reader would assume otherwise. The transparency clause is the one most often breached by omission rather than intent, and a visible label costs nothing.