Security checklist for production OpenAI SDK applications

Unit 14, Lesson 4 covered a general deployment checklist, where secrets management appeared as a single line item ("secrets come from the hosting platform's secrets management") among broader operational concerns like health checks, scaling, and rollout strategy. This checklist is narrower and deeper: it consolidates every security- and privacy-specific practice from this unit into one reference you can walk through before shipping an OpenAI SDK application to production, organized by the same categories this unit covered.

Secrets management

1. Every API key is scoped to a specific project and environment (Lesson 1) — no single key is shared across development, staging, and production.
2. No API key, or any other secret, appears anywhere in source code or commit history (Lesson 2). A secret scanner runs as a pre-commit hook and in CI.
3. Production and staging secrets come from a dedicated secret manager, not from a .env file on the server (Lesson 3). .env files are used only for local development and are listed in .gitignore.
4. No secret is baked into a container image via ARG or ENV in a Dockerfile; all secrets are injected at container runtime (Lesson 3).
5. A key-rotation process exists and has been exercised at least once — rotating a key should require a configuration change, not a code change or redeploy of application logic (Lesson 1).

Prompt and content safety

1. Every prompt that incorporates externally sourced content (web pages, documents, tool outputs, other users' data) wraps that content in explicit, labeled delimiters and states clearly, in the trusted developer/system message, that the content is data and not instructions (Lessons 4 and 5).
2. No untrusted content is ever concatenated directly into the system/developer message. It is confined to clearly delimited sections of user-role or tool-role content.
3. Any model call that processes untrusted content has no access to consequential tools unless a specific, reviewed exception has been made, in which case additional validation and authorization checks (items 11-15 below) apply (Lesson 4).
4. Workflows that both process untrusted content and need to take action are split into separate steps, so the step with tool access does not also hold the raw untrusted content in its context (Lesson 4).
5. Delimiter tags used for untrusted content are not trivially guessable static strings that an attacker could replicate to attempt to escape the intended boundary (Lesson 5).

Tool execution

1. Every tool has an explicit argument-validation function that runs before execution, checking types, allow-listed values, and numeric ranges — schema conformance alone is not treated as sufficient (Lesson 6).
2. Any argument that constructs a file path, URL, or query is checked structurally (for example, resolving a path and confirming it remains inside an allowed directory) rather than relying on blocklisting suspicious substrings alone (Lesson 6).
3. Business-rule limits (maximum discount, maximum transfer amount, rate limits) are enforced in code as hard ceilings, independent of anything the model is told in a prompt (Lesson 6).
4. Every tool has an explicit, fail-closed authorization check confirming the authenticated user's role permits that specific tool, before the tool executes (Lesson 9).
5. Tools acting on a specific resource (an order, an account, a record) enforce resource-level authorization, not just role-level authorization (Lesson 9).
6. High-risk, hard-to-reverse actions require explicit human confirmation before execution, independent of automated validation and authorization (Lesson 9).

Data privacy

1. Only the fields a given task actually requires are included in a prompt — full customer or user records are not sent when a subset of fields would serve the same purpose (Lesson 7).
2. Known PII patterns (emails, phone numbers, government IDs, payment details) are redacted before constructing a prompt, wherever the task does not specifically require the model to see the raw value (Lesson 7).
3. Structured output schemas are used where applicable to prevent the model from echoing sensitive values back into free-form output (Lesson 7).
4. A documented decision exists for how long conversation and request data is retained, consistent with applicable data-protection requirements for your users' jurisdictions.

Logging and monitoring

1. Production log statements never include full raw prompts or completions by default — only metadata (request IDs, token counts, latency, status codes) is logged (Lesson 8).
2. A redacting log filter is attached to production loggers as a safety net against secrets or PII patterns appearing in log messages incidentally (Lesson 8).
3. Verbose, full-content debug logging is explicitly gated to non-production environments and never shipped to a shared or remote log aggregator (Lesson 8).
4. Moderation flags and safety-relevant events are logged as categorized metadata, not as the full flagged content itself (Lesson 8, building on Unit 12, Lesson 7).
5. Access to logs and log-aggregation tooling is restricted to those who need it, with the same level of scrutiny applied to a database containing equivalent data.

A pre-deployment self-check

The checklist above is a review process, but a few of its items can be partially automated. The following script sketches a self-check that a CI pipeline could run before allowing a deployment, combining ideas from Lessons 2 and 6 of this unit into one gate.

import re


def scan_for_hardcoded_secrets(source_files: dict[str, str]) -> list[str]:
    """Returns filenames containing strings that look like API keys."""
    pattern = re.compile(r"sk-[A-Za-z0-9-]{16,}")
    return [name for name, content in source_files.items() if pattern.search(content)]


def check_tools_have_permissions(
    tool_names: list[str], permission_map: dict[str, set]
) -> list[str]:
    """Returns tool names that have no entry in the permission map."""
    return [name for name in tool_names if name not in permission_map]


def run_predeploy_security_checks(
    source_files: dict[str, str],
    tool_names: list[str],
    permission_map: dict[str, set],
) -> list[str]:
    """
    Runs a small set of automatable security checks and returns a list
    of human-readable failure messages. An empty list means these
    specific automated checks passed (the rest of the checklist still
    requires manual review).
    """
    failures = []

    leaked = scan_for_hardcoded_secrets(source_files)
    if leaked:
        failures.append(f"Hardcoded secret pattern found in: {', '.join(leaked)}")

    unprotected = check_tools_have_permissions(tool_names, permission_map)
    if unprotected:
        failures.append(f"Tools with no permission entry: {', '.join(unprotected)}")

    return failures

def test_predeploy_check_catches_hardcoded_key():
    source_files = {"config.py": 'API_KEY = "sk-proj-abcdefghijklmnopqrstuvwxyz"'}
    failures = run_predeploy_security_checks(
        source_files, tool_names=[], permission_map={}
    )
    assert any("Hardcoded secret" in f for f in failures)
    print("PASS: pre-deploy check flags a hardcoded API key")


def test_predeploy_check_catches_unprotected_tool():
    failures = run_predeploy_security_checks(
        source_files={},
        tool_names=["issue_refund", "lookup_order_status"],
        permission_map={"lookup_order_status": {"customer"}},
    )
    assert any("issue_refund" in f for f in failures)
    print("PASS: pre-deploy check flags a tool with no permission entry")


def test_predeploy_check_passes_clean_project():
    failures = run_predeploy_security_checks(
        source_files={"app.py": "import os\nkey = os.environ['OPENAI_API_KEY']"},
        tool_names=["lookup_order_status"],
        permission_map={"lookup_order_status": {"customer"}},
    )
    assert failures == []
    print("PASS: pre-deploy check produces no failures for a properly configured project")


test_predeploy_check_catches_hardcoded_key()
test_predeploy_check_catches_unprotected_tool()
test_predeploy_check_passes_clean_project()

This kind of automated gate catches a narrow but real slice of the full checklist — an obviously hardcoded key, or a tool that was added without a corresponding permissions entry. It is a useful complement to, not a replacement for, the manual review implied by the rest of the checklist above: prompt structure, data minimization decisions, and human-confirmation requirements for high-risk actions are policy and architecture choices that a script cannot fully verify on its own.

Using this checklist

Treat the 25 items above as a review to walk through deliberately before a production launch and periodically afterward — not as a one-time gate that, once passed, never needs revisiting. New tools added to an existing application need new entries in the permission map (item 14) and their own validation logic (item 11); new integrations that pull in external content need the same trust-separation review (items 6-10) that the original ones received; and a key that has never been rotated (item 5) becomes a larger liability the longer it goes unrotated, even if nothing about the surrounding code has changed at all.