OpenAI Agents SDK Security: Enterprise Hardening Guide

The OpenAI Agents SDK, released in April 2026, is the most significant expansion of the OpenAI enterprise attack surface since ChatGPT Enterprise launched. When your agents can authenticate to downstream APIs, execute code in a computer environment, and communicate with external tools via MCP, the security model is fundamentally different from a single-turn LLM API call. This guide covers the specific risks your team needs to address before or after Agents SDK deployment: OAuth token inheritance, Secure MCP Tunnel configuration, computer use tool (CUA) prompt injection, and sandboxing gaps.

---

What Changed in the April 2026 Agents SDK

The Agents SDK is not simply a wrapper around the Completions API. It introduces four new primitives that each carry distinct security implications.

Responses API manages stateful multi-turn execution. Unlike a single-turn API call, the Responses API maintains conversation context, tool call history, and agent state across multiple inference steps. This means a single malicious injection early in an agent session can propagate through every subsequent step, affecting tool selections, API calls, and outputs.

Secure MCP Tunnel provides a dedicated channel for agent-to-tool communication using the Model Context Protocol. The "Secure" label refers to transport encryption, not authorization scope. The tunnel itself does not enforce which functions an agent is allowed to call or which data it is allowed to return. That authorization layer is the enterprise's responsibility.

Computer Environment Tool (CUA) gives agents the ability to interact with operating system interfaces: file systems, terminals, browsers, and desktop applications. This is qualitatively different from a code interpreter in a sandboxed notebook. CUA operates at OS level, and the permissions granted to the agent process are the permissions available to an attacker who successfully injects into that agent.

OAuth 2.0 Token Exchange (RFC 8693) enables agents to obtain downstream tokens for enterprise APIs. The mechanism is sound; the implementation risk is in scope and lifetime. Most enterprises configure service accounts with broad scopes for operational convenience, and those scopes are inherited by every agent that authenticates with that account.

---

OAuth Token Inheritance: The Privilege Risk Nobody Audits

Token inheritance is the most underestimated risk in Agents SDK deployments. In practice, the pattern looks like this: an enterprise creates a service account for its AI operations team, grants it broad API access for operational flexibility, and then initializes agents with that service account. Every agent inherits every scope.

The NIST NCCoE published a concept paper in February 2026 (Booth, Fisher, Galluzzo, Roberts) formalizing this as a distinct control problem: 97% of non-human identities in production carry excessive privileges, and 82 non-human identities exist per human user. In most organizations, nobody is auditing what scopes agents actually need versus what scopes they have been granted.

Specific risks from token inheritance:

Token scope creep occurs when an agent initialized for a narrow task (say, reading support tickets) holds credentials that include write access to customer records, billing APIs, and user account management. The agent does not need those scopes. If compromised via prompt injection, it can use them.

Cross-agent credential pivoting is particularly dangerous in multi-agent Responses API workflows. One compromised agent can extract tokens from its memory context and use them to reconfigure downstream agents or call APIs outside the original task scope. If agents A, B, and C share a credential pool, compromising agent A effectively grants access to everything agents B and C can reach.

Credential exfiltration via prompt injection is the practical exploitation of these scope issues. An attacker who can inject into agent memory or tool output can instruct the agent to return its authentication context as part of a "debugging" or "error reporting" output. Tokens stored in agent logs or returned in verbose error messages are common findings in our assessments.

Controls to apply:

Issue per-task tokens using RFC 8693 token exchange rather than passing service account credentials directly to agents. Enforce a maximum lifetime of 300 seconds per session. Scope tokens to the exact API calls required for the current task, not the full set of APIs the organization uses. Require a secrets manager (AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault) rather than environment variables or agent memory. Audit token issuances against a policy document that maps each agent role to its permitted scopes.

---

Securing the Secure MCP Tunnel

The Secure MCP Tunnel protects the confidentiality and integrity of agent-to-tool communication in transit. It does not protect against an agent calling tools it should not call, calling tools with parameters outside intended ranges, or using legitimate tool access for malicious purposes.

The most common misconfiguration in production: allowlisting an entire MCP server rather than specific functions. If you have an MCP server that includes read_record, update_record, delete_record, and admin_reset, and you allowlist the server, agents can call all four. The authorization boundary should be at the function level, not the server level.

Three hardening requirements for the Secure MCP Tunnel:

First, maintain a per-agent-role function allowlist. Each agent role (customer service agent, data analysis agent, reporting agent) should have a documented list of MCP functions it is authorized to call. This list should be version-controlled, reviewed as part of agent deployment, and enforced at the tunnel layer, not just the application layer.

Second, ship all MCP tunnel traffic to a centralized audit log separate from application logs. Log the agent identity, the function called, the parameters passed, and the response received. This is the minimum required to detect tool abuse, whether from prompt injection or misconfigured agent logic. Detect anomalies by comparing actual invocations against the authorized function list.

Third, pin MCP server versions and verify integrity. Treat MCP server definitions as infrastructure-as-code. Use SHA-pinned versions rather than floating latest. Verify server integrity against a known-good hash before initialization. The MCP ecosystem includes third-party servers; a malicious or compromised MCP server can instruct agents to perform actions that appear authorized but serve attacker objectives. This is OWASP Agentic Security Initiative (ASI04) territory: agentic supply chain vulnerabilities.

---

Computer Environment Tool: OS-Level Prompt Injection

The computer environment tool (CUA) introduces a category of risk that does not exist in standard LLM deployments. When an agent can execute shell commands, the consequence of a successful prompt injection is not a harmful text output. It is code execution.

The attack surface is the intersection of what the agent can read (its context, including injected content) and what the CUA can execute (OS commands, file operations, network calls). The attack pattern is straightforward: craft input that reaches the agent's context and contains a shell command sequence that the agent will pass to the CUA.

In practice, shell metacharacter injection looks like this. A user submits input that contains content the agent processes: a file name, a document, a form field. That content includes shell operators (semicolons, pipes, backticks, $() command substitution). If the agent constructs a CUA command that includes user-controlled input without sanitization, the injected operators execute alongside the intended command.

Environment variable expansion is a related vector. Agents operating in environments with credentials or API keys in environment variables are vulnerable to inputs that reference those variables explicitly. The agent, attempting to be helpful, includes the variable value in its output or passes it to a tool.

Controls to apply:

Apply strict input validation before any user-controlled content reaches a CUA command string. Treat all external data as untrusted; this includes not just direct user input but also content retrieved from APIs, files, URLs, and other agents. Use parameterized command construction rather than string concatenation. The agent should pass structured parameters to CUA functions, not build shell command strings.

Configure the CUA sandbox with egress filtering. An agent that cannot make outbound network connections to arbitrary endpoints cannot exfiltrate data even if shell injection succeeds. Limit file system access to read-only paths where the task does not require writes. Apply Linux namespace isolation for host network, PID, and IPC namespaces. Log all CUA invocations, including the full command and parameters, to a tamper-proof audit store.

For high-privilege CUA deployments (infrastructure automation, code deployment), require a human-in-the-loop gate for commands that meet defined risk criteria: commands that modify files outside the intended scope, network calls to unexpected destinations, or commands that escalate privileges.

---

Sandboxing Configuration for Production

The Agents SDK sandbox provides OS-level process isolation for agent execution. The default configuration prioritizes operational flexibility over security restriction. Production deployments require explicit hardening.

Linux namespace configuration is the first control layer. By default, containers and sandbox processes may share host namespaces for network, PID, and IPC. These shared namespaces allow a compromised agent to observe host network traffic, enumerate running processes, and communicate via shared memory with processes outside its intended scope. Each agent process should run in isolated network, PID, and IPC namespaces.

Resource limits prevent one class of attack that sandboxes often overlook: resource exhaustion. An agent that consumes all available CPU, memory, or disk space disrupts the broader system, including other agents and services running on the same infrastructure. Apply cgroup limits to agent processes: CPU share, memory limit, disk I/O, and file descriptor count. Enforce these limits at the infrastructure level, not the application level.

Container escape via kernel exploits is a residual risk in any containerized sandbox. The practical mitigation is defense in depth: apply seccomp profiles to restrict system calls, use AppArmor or SELinux MAC policies to limit file and network access, run container workloads on up-to-date kernels, and monitor for behaviors that indicate escape attempts (unexpected system calls, access to /proc/sysrq-trigger, writes to host-mounted paths).

The sandbox is a defense-in-depth layer, not a complete security boundary. Apply the controls above alongside authorization scoping, egress filtering, and behavioral monitoring. A sandbox that stops the escape attempt is a good outcome; a monitoring system that detects the attempt before escape is better.

---

Authorization Scoping for Tool Calls

OWASP LLM06 (Excessive Agency) describes the pattern where agents are granted tools beyond what their task requires, or are granted excessive permissions on those tools. The Agents SDK makes this concrete: if an agent's tool list includes functions that the agent should never call for its intended task, those functions represent an attack surface.

Authorization scoping for tool calls has three components:

Minimum tool set: Each agent should have access only to the tools its task explicitly requires. A customer support agent does not need access to database deletion functions. A reporting agent does not need access to user account management. Review agent tool configurations at deployment time against the intended task scope, and remove any tools that do not appear in a documented use case.

Per-operation permission validation: Tool execution should validate not just that the agent has the tool in its list, but that the specific invocation (function, parameters, target resource) is within authorized scope for the current task context. This is analogous to attribute-based access control (ABAC) applied to agent tool calls. The Responses API does not enforce this by default; it requires implementation at the application layer.

Audit trail for tool invocations: Maintain a separate, tamper-proof log of all tool invocations by agent session, including the agent identity, tool name, parameters, timestamp, and response. This is the minimum required for incident investigation. In a compromise scenario where an agent is used to exfiltrate data or modify systems, the tool invocation log is the primary evidence source. Do not rely on application logs that the agent process has write access to.

A note on indirect prompt injection and tool abuse: an agent may have a legitimate tool and use it for a task it was not intended for, because an attacker injected instructions that manipulated the agent's reasoning. The ForcedLeak incident in Salesforce AgentForce (July 2025) demonstrated this pattern. The agent's tool (CRM data access) was authorized; the usage context (exfiltrating records to an external endpoint) was injected. Tool authorization is necessary but not sufficient. Behavioral monitoring that detects anomalous tool usage patterns is required.

For more on agent blast radius containment, see our guide on agentic AI blast radius containment and the detailed controls in our AI agent authorization and least privilege guide.

---

CISO Deployment Checklist

Before moving an Agents SDK deployment to production, security teams should verify each of the following:

Identity and Credentials

• [ ] Each agent role has a dedicated service identity, not a shared service account
• [ ] OAuth tokens are issued with per-task scopes via RFC 8693 token exchange
• [ ] Token maximum lifetime is 300 seconds or less
• [ ] Credentials are stored in a secrets manager, not environment variables or agent memory
• [ ] Token issuance is logged against a policy document that defines expected scopes per role

MCP Tunnel Configuration

• [ ] Allowlist is defined at the function level, not the server level
• [ ] MCP server versions are pinned with SHA verification
• [ ] All tunnel traffic is logged to a tamper-proof audit store
• [ ] Audit logs include: agent identity, function called, parameters, timestamp, response
• [ ] Anomaly detection is configured to alert on invocations outside the authorized function list

Computer Environment Tool

• [ ] CUA is disabled for agent roles that do not require OS-level interaction
• [ ] All user-controlled input is sanitized before reaching CUA command construction
• [ ] Egress filtering blocks outbound connections to non-allowlisted destinations
• [ ] File system access is restricted to the minimum required paths
• [ ] CUA invocations are logged with full command and parameter detail

Sandboxing

• [ ] Linux namespaces are isolated: network, PID, IPC
• [ ] cgroup resource limits are applied: CPU, memory, disk I/O, file descriptors
• [ ] seccomp profiles restrict system calls to the expected set
• [ ] Container image is based on a current kernel version with known CVEs patched
• [ ] Escape attempt detection is configured in the behavioral monitoring layer

Governance

• [ ] Agent inventory documents each agent role, its tools, its credential scopes, and its intended tasks
• [ ] Agent tool configurations are reviewed at deployment time and on a scheduled cadence
• [ ] Incident response playbook covers agent compromise, including credential revocation steps
• [ ] Human-in-the-loop gates are defined for high-impact actions (data deletion, external API writes, system modifications)

---

Applying These Controls in Practice

The practical gap between documented controls and deployed reality is wide. In most Agents SDK deployments we assess, agents have been configured for operational speed rather than security precision. Service account credentials with broad scopes are passed directly to agents. MCP server allowlists cover entire servers. Sandboxes run with default namespace configurations. Audit logs capture application-level events but not tool invocation detail.

The controls above are achievable with the standard infrastructure tooling most enterprises already use: secrets managers, centralized logging, cgroup configuration, and namespace isolation. The challenge is prioritization and awareness, not tooling cost.

If you have an existing Agents SDK deployment and want to understand the current exposure, our Securetom scan identifies credential scope issues, tool authorization gaps, and sandbox configuration problems in AI agent deployments. For teams designing new deployments, our AI security assessment covers the full Agents SDK threat model with recommendations specific to your infrastructure.

For related technical depth, see our guides on MCP server security configuration, non-human identity security for AI agents, and AI agent sandboxing.

The OWASP Top 10 for Large Language Model Applications (2025) and the NIST AI Risk Management Framework provide the authoritative baseline for classifying these risks within a governance structure. The OWASP Agentic Security Initiative has published an updated top 10 specifically for agentic applications that maps directly to the Agents SDK threat model.

---

Conclusion

The OpenAI Agents SDK expands enterprise AI capability significantly. It also expands the attack surface significantly. OAuth token inheritance, MCP tunnel configuration, CUA prompt injection, and sandboxing gaps are not theoretical risks. They are the practical consequences of deploying a system that authenticates to downstream APIs, executes OS-level commands, and communicates with external tools, all autonomously, at machine speed.

The hardening measures described here, per-task credential scoping, function-level MCP allowlists, CUA input sanitization and egress filtering, and proper sandbox namespace isolation, are not complex to implement. They are often missed because they require deliberate security design rather than default configurations.

If your organization has deployed or is planning to deploy the OpenAI Agents SDK and has not conducted a security review of the deployment, contact us or run a Securetom scan to identify the specific gaps in your configuration before they become incidents.