Grok Acceptable Use Policy: What Enterprise Teams Must Enforce

The Grok acceptable use policy is a provider rule that binds people and businesses using Grok and related services. The current page, effective August 14, 2026, is published under the SpaceXSI name at the existing x.ai address. It bars illegal or harmful use and attacks on the service. It also bars safeguard circumvention, unauthorized actions, and high-stakes automated decisions. An enterprise still needs its own controls because accepting a provider policy does not decide whether a specific employee or agent should reach the API, or whether a particular prompt or workflow should do so.

TL;DR

• The Grok acceptable use policy applies to consumers and developers as well as businesses. Violations can lead to account suspension or termination.
• Current prohibitions include service attacks and prompt injection. They also cover safeguard circumvention, harmful activity, unauthorized actions, and high-stakes automated decisions.
• Enterprise terms make the customer responsible for permitted users and end users. A shared API key is insufficient accountability.
• Enforce route and identity rules before approved API calls. Apply purpose and data rules too, then retain a versioned decision record.
• Direct Grok sessions and local actions require controls outside an HTTP model gateway. So do downstream business decisions.

The Grok acceptable use policy sets a provider floor

The current SpaceXSI Acceptable Use Policy says it applies to anyone using the service, including consumers and developers as well as businesses. It also says the policy will change over time. The review file should therefore record the effective date and canonical URL, along with the version that governed an approved deployment.

The policy groups many specific examples under a few operating themes. Users may not attack or interfere with the service. They may not bypass protective measures, strip provenance metadata, scrape or resell inputs and outputs, or use unauthorized automated access. It prohibits harmful and abusive activity as well as privacy violations. Impersonation, fraud, phishing, and falsification are also prohibited. It further prohibits unauthorized actions on another person's behalf and high-stakes automated decisions affecting safety or well-being, including decisions about legal or material rights.

Those rules are broader than a content filter. Some concern the request text. Others concern account behavior, product access, generated media, or what an application does after receiving an output. A control description should say which category it can test instead of claiming that one classifier enforces the entire policy.

Enterprise terms place responsibility on the customer

The SpaceXSI Enterprise Terms incorporate the AUP by reference. They require customers to maintain terms and an acceptable use policy for permitted users and end users that are no less protective. The terms also leave the customer responsible for end-user acts and omissions.

That allocation matters for an application built on the Grok API. SpaceXSI sees the customer account and API credential. The enterprise may know the employee and service behind a request, plus the relevant tenant and business process. That context must survive before several people or agents collapse into one provider credential.

The broader Grok Enterprise security review explains why API authentication does not supply end-user authorization. The AUP adds another reason to preserve identity: an abuse investigation needs to isolate the responsible workflow without treating every user of the shared account as one actor.

Turn policy categories into request decisions

A useful enterprise control begins with categories that can be observed on an approved HTTP API route. The policy decision can check the authenticated user or agent and the application. It can also examine the destination, requested model, prompt classification, declared purpose, and action class. The result may allow or block the call. Another result can send it to a defined review path.

The xAI API security FAQ documents a safety_identifier field for associating a request with the end user behind it. That identifier supports provider-side attribution, but it should not become the enterprise's only record. Keep the internal identity mapping under customer control and avoid putting direct personal information into an opaque provider field.

For each decision, retain the timestamp and policy version. Add both caller and application identities. Record the route and model, then capture the category match and outcome with the correlation identifier. Keep a controlled reference to sensitive content when retaining the full prompt would create another exposed data store. This record shows which enterprise rule ran before the API request and can be reconciled with the Grok Enterprise audit-log view.

High-stakes decisions need a hard boundary

The current AUP prohibits making high-stakes automated decisions affecting a person's safety or well-being, including decisions about legal or material rights. Its examples include financial credit and education. Employment, housing, insurance, legal, and medical decisions are also included. An organization should not translate that rule into a vague warning displayed after a model answer.

Start with the approved-use inventory. Mark workflows that make or materially determine a covered decision as prohibited on Grok unless the provider supplies written terms that change the applicable boundary. Block the model route for those declared purposes and application identities. Review undeclared routes when prompt context or downstream action suggests a high-stakes use.

A gateway decision covers the model request. It cannot determine every downstream consequence from prompt text alone. The application owner must prevent an output from being converted into a denial or ranking through a separate channel, including a diagnosis or other covered action. Human reviewers need authority and relevant evidence. They also need a documented ability to reject the result. The AI policy enforcement architecture should sit beside application controls rather than being presented as their substitute.

Prompt injection rules require scoped testing

The AUP names jailbreaking and adversarial prompting among activities that can detrimentally affect the service. It names prompt injection too. Enterprise teams should distinguish malicious testing from ordinary exposure to untrusted content. An employee may paste a document containing hidden instructions without intending to attack Grok. A research team may also have written authorization for a bounded red-team exercise.

Policy should identify the authorized testers and accounts. It should also state the time window, targets, and evidence owner. Production routes can deny known adversarial test traffic from ordinary users. Approved tests can go through a separate account. Retrieved documents and tool output should be treated as untrusted context even when the authenticated user has benign intent.

This design avoids two poor outcomes. It does not label every indirect injection as employee misconduct, and it does not let a generic security-testing label become permanent permission to bypass safeguards. Keep the written authorization with the request records for the exercise.

Policy changes need operational review

The AUP states that it can evolve. A deployment approval tied to one snapshot should trigger review when the effective date or substantive rules change. Assign an owner to compare versions and identify affected use cases. The owner should update enforcement categories, then test one allowed request and one blocked request.

Review the enterprise terms at the same time because the contract incorporates the AUP by reference. A policy-page change may alter what the customer must flow down to users before an application release changes. Preserve the reviewed version with the approval record. Keep the test results there too. The Grok Enterprise compliance guide covers the adjacent route and retention controls, along with regional controls that remain separate from acceptable use.

DeepInspect

DeepInspect can enforce enterprise policy on authenticated HTTP requests to Grok API endpoints that are deliberately routed through its stateless proxy. It can evaluate application-supplied identity and prompt classification before forwarding the request. The decision can also use the route and policy version, then produce a per-decision record.

Provider account enforcement and direct Grok sessions remain outside that boundary. So do browser and device behavior, local tool execution, and downstream business actions. DeepInspect supplies a customer-controlled decision on routed model traffic. It does not replace the provider AUP or expand the uses that the provider permits.

Book a technical deep dive at deepinspect.ai.