What your security reviewers will ask (and how Apps SDK answers)

1) How are risky operations gated?
Mark tools that change state or send data off-platform as write actions. ChatGPT will surface human confirmation prompts before execution; destructive actions must carry clear labels and friction.

2) Does the UI run in a sandbox?
Yes. App components render in a sandboxed iframe and talk to ChatGPT via window.openai. The iframe runs under a strict Content Security Policy (CSP) that blocks privileged browser APIs.

3) How do you authenticate users (SSO)?
Use OAuth 2.1 + PKCE; register ChatGPT as a client via Dynamic Client Registration, then enforce scopes server-side on every tool call. (OIDC is the common identity layer many IdPs support.)

4) What data do you collect and for how long?
Publish a privacy policy, practice data minimization, redact PII in logs, and document retention & deletion. These are explicit listing requirements.

5) Can admins govern internal connectors?
Yes. Only admins can publish workspace MCP connectors; RBAC can restrict access; at launch, updates require re-publish.

6) Where can apps run today?
Public apps are visible to non-EU ChatGPT users on Free/Go/Plus/Pro; Business/Enterprise/Edu app support and broader geos are on the roadmap. Build now; submissions open later this year.

SSO & identity patterns (source-aligned)

• OAuth 2.1 + PKCE + DCR. Use the Apps SDK’s guidance: PKCE for public-client flows and Dynamic Client Registration so ChatGPT can register with your IdP. Enforce scopes on each tool call; reject expired/invalid tokens with 401.
• When to require sign-in. Many apps can operate read-only/anonymous, but authenticate for customer data or any writes.
• What SSO to implement. Use your IdP’s OIDC/OAuth 2.1 endpoints; keep secrets server-side and avoid long-lived tokens in UI props.

Data handling & privacy controls (what to implement day one)

• Minimize inputs. Treat the tool schema as a contract—collect only fields needed for the task.
• Ban sensitive data. Do not collect PCI, PHI, government IDs, API keys, or passwords in your app.
• Retention & deletion. Publish retention windows; respect deletion requests; redact PII in logs; keep correlation IDs for debugging.
• Egress controls. Any action that sends data outside the current boundary must be a write action so the client can require confirmation or run in preview mode.

Architecture & platform boundaries (for security reviews)

• Client surface: ChatGPT renders your component inline in chat via a sandboxed iframe and a window.openai bridge.
• Network/CSP: Widgets are constrained by CSP; standard fetch works only within CSP allow-lists; avoid privileged browser APIs. (CSP backgrounder linked for reviewers.)
• Server side: Your MCP server hosts tool contracts (JSON Schema), enforces authz, and validates inputs (defense-in-depth).

Submission & distribution checkpoints (preview → listing)

• Status & timing. Preview today; submissions open later this year; directory + monetization follow.
• Listing requirements. Provide a privacy policy, accurate metadata/tool labels, and a support contact; apps must be stable (no beta/trial submissions). Changing tool names/signatures requires re-submission.

Procurement checklist (copy/paste into your RFI/RFP)

Security controls

• Least-privilege scopes per tool; server-side input validation; audit logs enabled.
• All egress or state-changing tools marked write actions with confirmation prompts.
• CSP-compatible component bundle; no privileged browser APIs.

Identity & access

• OAuth 2.1 + PKCE with DCR; OIDC provider details; scope map per tool; token lifecycle docs.
• RBAC for internal MCP connectors; admin-publish workflow documented.

Privacy & data

• Published privacy policy; data minimization; sensitive-data bans; retention & deletion policy.

Operational readiness

• Environments, dependency patch policy, anomaly monitoring/alerts, incident response contacts.

Platform constraints

• Current plan/geo availability acknowledged (non-EU Free/Go/Plus/Pro) and roadmap for Business/Enterprise/Edu.

Red flags (reject or re-scope)

• Tools that write or egress data without being labeled as write actions.
• Missing privacy policy or attempts to collect PCI/PHI/IDs/API keys/passwords.
• UI bundles that attempt to bypass the iframe/CSP sandbox.
• Vendors claiming immediate Enterprise/Edu app availability (it’s on the roadmap, not GA).

Implementation plan (security-first build)

1. Contracts first. Define narrow tools (read vs write) and schemas; add server-side validation and logging.
2. SSO setup. Configure OAuth 2.1 + PKCE + DCR with your IdP; enforce scopes per tool call.
3. Component build. Ship a minimal UI in the iframe; verify CSP-safe resource loading; avoid privileged APIs.
4. Developer Mode tests. Connect your /mcp endpoint in ChatGPT; validate discovery and confirmation prompts.
5. Compliance pack. Prepare privacy policy, support contact, scope map, retention policy, and evidence of confirmations for all write actions (screenshots/traces).
6. Submission (when open). Align to guidelines; remember tool changes require re-submission.