store: false and Sensitive Data Management

The store parameter: Your privacy lever

Among all the Grok API settings, the store parameter has the most direct impact on privacy: it determines what happens to your data after processing. With store: false, xAI keeps no trace of your request or the response once generation finishes. The data passes through, gets processed, and disappears. For a compliance officer, this guarantee changes the risk profile: data that isn’t stored by the subprocessor can’t leak from their systems, can’t be subpoenaed, and doesn’t complicate your processing records. This mechanism is essential for protecting sensitive data, and this lesson shows you when to use it, when you can skip it, and how to make it systematic.

When store: false is mandatory

The first case involves health data, governed by HIPAA. If your application submits clinical reports, diagnostics, prescriptions, or any patient data to the API, the rule is without exception: this information must never be stored by a third party not essential to processing.

{
  "model": "grok-4.3",
  "messages": [
    {"role": "system", "content": "You are a medical assistant."},
    {"role": "user", "content": "Summarize this clinical report..."}
  ],
  "store": false
}

The same logic applies to financial data—analysis of unpublished quarterly results, audit reports, confidential market data. The value of these documents lies precisely in their confidentiality, and third-party storage creates a potential breach. It also applies to legal data: contracts, legal opinions, attorney-client communications, where attorney-client privilege itself imposes store: false. A lawyer who lets a third party retain their exchanges with a client breaches their obligation, regardless of that third party’s quality.

A fourth case deserves particular vigilance: images and scanned documents. The store: false parameter is strongly recommended whenever your requests contain images, for a simple reason: an image can contain sensitive information that no text scan will detect. The ID photo left in a corner of a scanned document, the account number visible on a screenshot, the patient name on the letterhead of a photographed letter—your text filters won’t see them, but they’re there.

When store: true is acceptable

Should you ban store: true (the default value)? No—it has its place, provided you know where. During development, retaining requests is even valuable: it lets you debug via the xAI console, analyze usage patterns, and optimize your prompts by rereading what was actually sent. As long as your test sets contain only fictitious data, there’s no problem. Likewise, if your application processes only public data—news articles, technical documentation, open data—store: true poses no compliance issue: you don’t protect what’s already public.

Making store: false systematic

The real difficulty isn’t knowing the rule, it’s guaranteeing it applies to every call, including one a developer adds six months from now. Two mechanisms handle this. The first is a classification middleware, which automatically decides the store value based on data type:

def classify_and_set_store(request_data, data_classification):
    """
    Sets store based on data classification.
    """
    sensitive_classifications = [
        "confidential",
        "secret",
        "medical",
        "financial",
        "legal",
        "personal"
    ]

    if data_classification in sensitive_classifications:
        request_data["store"] = False
    else:
        request_data["store"] = True

    return request_data

The second is more drastic: force store: false by default in production via an environment variable. This way, oversights become harmless—it takes an explicit action to enable storage, not the other way around.

import os

DEFAULT_STORE = os.environ.get("XAI_DEFAULT_STORE", "false") == "true"

def make_api_call(messages, store=None):
    if store is None:
        store = DEFAULT_STORE

    return {
        "model": "grok-4.3",
        "messages": messages,
        "store": store
    }

Beyond store: Complementary practices

Don’t fall for a false sense of security: store: false doesn’t make your application compliant. It prevents retention by xAI, nothing more. The first complementary practice is anonymization before sending: replace proper names with generic identifiers, Social Security numbers with placeholders, addresses with generic locations, account numbers with masked IDs. Data that never leaves doesn’t need protection on arrival. Next comes encryption in transit: the xAI API uses TLS, but verify your client forces HTTPS and refuses insecure connections—protection only works if activated on both sides.

Finally, the most frequent blind spot: your own retention. Even if xAI keeps nothing, your application might keep copies—request logs, response caches, debug exports. Define clear policies: 30 days maximum for logs containing sensitive data, delete cached responses on session expiry, and align audit data retention with your regulatory obligations. It would be paradoxical to pay the price of store: false on the xAI side while accumulating the same data in an unpurged log file.

Implementing the rule in your organization

Implementation follows a logical order I recommend you respect, because each step makes the next possible. Start by inventorying your use cases, identifying the data type each application handles: without this mapping, any rule remains abstract. Next, set the default rule—store: false unless documented exception—then implement the classification middleware that applies it without human intervention.

Two requirements complete the setup, and these are the ones most often skipped. The first relates to code review rather than documentation: require every new endpoint to write store explicitly, instead of relying on the default. An explicit value gets reviewed and discussed; an implicit default goes unnoticed the day someone changes the environment variable. The second is proof: sample the requests your services actually emit and compare them to your classification. An auditor will keep this record, not your policy document, when they ask not what you decided, but how you know it’s applied.

Key takeaways

• store: false prevents any retention of data by xAI after processing
• Use it systematically for medical, financial, legal data—and for images, which escape text scans
• Force store: false by default in production via an environment variable: oversights become harmless
• Combine with anonymization before sending: the best protected data is data that never leaves
• store doesn’t replace the rest: encryption in transit, limited retention on the app side, access control