Commit 3828825

For suspected vulnerabilities, follow [SECURITY.md](SECURITY.md). Keep undisclosed security reports and fixes out of public issues, discussions, and pull requests until disclosure is coordinated.

Read [AGENTS.md](AGENTS.md) for the repository's scope, compatibility, review, and verification requirements. Use Python 3.10 or newer, `uv`, and `make`. Install the development dependencies with `make sync`, and run Python commands through `uv run`.

Keep changes focused on the agreed outcome. Add regression coverage for changed behavior and follow [tests/README.md](tests/README.md) for test execution. Run focused checks while developing, then the applicable final checks described in [AGENTS.md](AGENTS.md#testing--automated-checks). Use the [pull request template](.github/PULL_REQUEST_TEMPLATE/pull_request_template.md) to explain the problem, change, and validation. Documentation changes follow the repository's verification tiers and release-timing rules.

- Use synthetic fixtures and obvious placeholder credentials in tests, examples, snapshots, and documentation. Never commit real API keys, tokens, cookies, signing keys, customer data, private prompts or responses, tool payloads, or recordings.

- Provide credentials for explicitly authorized live tests through the approved environment or secret store. Use the minimum necessary access and keep live credentials out of untrusted contributor runs. Do not embed credentials in browser code, commands, URLs, or generated artifacts.

- Inspect diffs and attachments for sensitive data before sharing them. Include logs, exceptions and their chained context, tracebacks, telemetry, session exports, files, and audio in that check. Do not assume a tracing redaction setting sanitizes every channel.

- If a credential is exposed, stop sharing it, report it privately through [SECURITY.md](SECURITY.md), and have its owner revoke or rotate it. Deleting the visible value alone does not invalidate the credential.

- Justify new dependencies and review the package source, maintenance history, install or build hooks, transitive dependencies, and lockfile changes. Keep dependency changes scoped and reproducible.

- Assess dependency alerts for the affected runtime, optional integration, development, example, CI, or publishing path. Record reachability and impact instead of dismissing an alert solely because the dependency is not shipped to users.

- For dependency-update automation, apply a documented release-age cooldown to ordinary version updates while allowing security updates immediately. Review security updates promptly; they still require appropriate review and checks. Do not claim a cooldown or update ecosystem is configured without checking the actual configuration.

- Escalate critical or actively exploited findings immediately through the private security process. Record any proposed exception with an owner, mitigation, approving authority, and expiry; an unapproved exception is not an accepted risk.

- Treat pull request content, branch names, artifacts, and external downloads as untrusted input. Do not execute contributor-controlled code in a privileged workflow or expose secrets to it, including through `pull_request_target` or a later workflow that consumes contributor artifacts.

- Use explicit, least-privilege workflow and job permissions, review third-party actions, and pin actions to full commit SHAs. Grant write or `id-token` permissions only to jobs that require them. Do not bypass required reviews, secret protections, or security checks to make CI pass.

- Changes to credentials, redaction, requests and redirects, parsing, uploads, tool approvals, MCP, persisted state, sandbox access, dependencies, CI, or releases need focused security review and regression coverage appropriate to the affected boundary.

- Release approval under the shared SDK policy requires CODEOWNERS coverage of release workflows and publishing configuration, required code-owner review of release pull requests, and passing required checks. A separate environment reviewer gate is not required by that policy. Follow any protections currently configured for this repository; this guidance does not authorize removing or bypassing them.

- Preserve the existing PyPI OIDC publishing flow, release-source validation, and artifact handoff in [the publishing workflow](.github/workflows/publish.yml). Do not replace short-lived trusted publishing with long-lived registry tokens or weaken provenance checks for convenience. Follow the [maintainer release procedure](.github/RELEASING.md).

- When assessing publishing readiness, verify the repository-specific registry binding, artifact provenance, publisher access, and recovery arrangements. Workflow configuration alone does not prove those controls are in place.

These requirements describe how to contribute safely. Their presence does not certify repository settings, establish a scan baseline, or close existing security findings. Maintainers must track verified gaps and approved exceptions separately from proposed work.

Report suspected vulnerabilities privately through the channels in OpenAI's [Coordinated Vulnerability Disclosure Policy](https://openai.com/policies/coordinated-vulnerability-disclosure-policy/). Follow that policy for disclosure coordination and bug bounty eligibility. Our [security contact and PGP key information](https://cdn.openai.com/security.txt) are available for encrypted reports.

Do not open a public GitHub issue, discussion, or pull request containing an undisclosed vulnerability or sensitive reproduction details. Use the disclosure policy's reporting channels even if GitHub's private vulnerability reporting feature is unavailable for this repository.

Include the following information in a private report:

- The affected `openai-agents` version or commit, Python version, operating system, and relevant optional dependencies or provider configuration.

- The affected component, expected and observed behavior, and the security impact, including who can control the input and which trust boundary is crossed.

- A minimal reproduction using synthetic data and placeholder credentials, plus sanitized logs or tracebacks when useful.

Remove API keys, authorization headers, cookies, tokens, signing material, customer data, personal information, and private prompts, responses, tool arguments, files, or audio from reports and attachments. Check URLs, logs, tracebacks, trace exports, session records, and screenshots for sensitive values. If an exposed credential is involved, report the exposure privately and have its owner revoke or rotate it; do not include the credential itself or test it against a live service.

This policy covers the OpenAI Agents Python SDK in this repository and the `openai-agents` package, including agent execution, tools and MCP integration, sessions and resumed state, tracing, Realtime and Voice integrations, sandbox adapters, examples, dependencies, and the build, CI, and publishing path that produces distributed artifacts.

Security issues in dependencies or external providers can affect this SDK. Explain the affected SDK path and environment so maintainers can coordinate with the responsible project. A dependency used only for development, examples, or releases still needs impact assessment; it is not automatically harmless or a production vulnerability.

Applications choose credentials, providers, tools, storage, and execution permissions. Tool implementations and local subprocesses can exercise the host application's privileges. Applications must authorize those capabilities and isolate untrusted execution using appropriate controls. Model output, tool and MCP responses, remote content, and serialized state do not by themselves authorize access to host resources or credentials.

Security review should verify that changes preserve these properties:

- Credentials and sensitive payloads stay within their intended request, storage, and telemetry destinations. Redaction controls must be checked at the actual logging, exception, tracing, and serialization paths; a tracing option does not sanitize every output channel.

- SDK-managed tool approvals, sandbox host-path boundaries, and application-controlled grants cannot be bypassed by untrusted input or resumed state.

- Requests, parsing, file materialization, and cleanup preserve the applicable authorization, resource-ownership, and filesystem boundaries.

- Untrusted contributions cannot obtain CI secrets or publishing authority. Published artifacts must come from the reviewed release source through the authorized publishing workflow.

Reports should identify a reachable security consequence on an affected SDK, development, or release path. A prompt injection or unsafe application-defined tool does not by itself establish an SDK defect; a bypass of an SDK-enforced boundary remains reportable. Maintainers assess severity using impact, reachability, required privileges, and exposure rather than scanner severity alone. A completed scan does not establish that all controls are healthy or that its findings are resolved.

Coordinate undisclosed fixes through the private reporting process before publishing a patch or regression test. See [CONTRIBUTING.md](CONTRIBUTING.md#security-checklist) for safe development practices and [AGENTS.md](AGENTS.md#security-checklist) for agent review requirements.