Frameworks

Security testing for OpenAI Agents SDK apps

Apps built on the OpenAI Agents SDK act through function tools, hosted tools, MCP servers and handoffs between agents. The SDK ships guardrails, but each type runs at a specific point. We pentest the paths where untrusted input reaches a tool call without passing the guardrail you assumed it passed.

OpenAI is named here as a surface we test. Names and logos belong to their owners; no customer relationship, partnership or endorsement is implied.

What can an OpenAI Agents SDK agent do?

According to the SDK tools documentation, agents can use hosted tools that run on OpenAI's side, function tools that wrap your own Python functions, and other agents exposed as tools. The MCP documentation covers hosted MCP server tools plus Streamable HTTP, HTTP with SSE and stdio servers.

Handoffs let one agent delegate to another, and the docs note they are represented to the model as tools, so a handoff to a Refund Agent appears as a tool named transfer_to_refund_agent. In other words, routing is a model decision like any other tool call.

Where do guardrails run?

The guardrails documentation is specific. Input guardrails run only for the first agent in the chain. Output guardrails run only for the agent that produces the final output. Tool guardrails run on every guarded function-tool invocation, before and after execution, and the docs recommend them for workflows with managers, handoffs or delegated specialists instead of relying only on agent-level guardrails.

That gives us a test plan. A payload that arrives through a tool result, after the first agent, never meets the input guardrail. A specialist agent that calls a refund tool mid-chain is not covered by the output guardrail. Unless that tool has its own guardrail, nothing in the SDK inspects the call.

Which risks apply and why?

• Prompt injection: user text that picks a handoff or a function argument.
• Indirect prompt injection: payloads in hosted search results, files or MCP tool responses, which skip input guardrails.
• Excessive agency: specialists that hold more tools than their role needs, reachable by handoff.
• MCP tool poisoning: server tool descriptions the model reads as instructions.
• Sensitive information disclosure: tool output reused in a later outbound call.

How do you pentest an OpenAI Agents SDK app?

Our checklist for an AI agent pentest on this SDK:

1. List every agent, its tools, its handoffs and which guardrails are attached at agent and tool level.
2. Route a payload through each non-first agent and confirm whether any guardrail sees it.
3. Force each handoff from user input and from tool output, and check that the receiving agent re-checks authorization.
4. Call every function tool with arguments the task would never produce, such as other users' IDs or out-of-range amounts.
5. Read the tool definitions exposed by each MCP server and test injected descriptions and responses.
6. Try to move data out through any tool that writes, sends or renders.

Every item ends in a recorded tool call or a recorded refusal, so the report shows what the SDK configuration did, not what it was meant to do.

What access do we need?

A staging deployment or test account where the agents run with realistic tools, a short description of each tool and handoff, and test credentials for any downstream services. Repository access helps us read guardrail placement faster, but is not required. We confirm scope in writing before the clock starts.

Last reviewed: 2026-10-14