OpenAI AgentKit Security: No-Code Agents Expand Attack Surface

What happened

OpenAI's AgentKit is drawing scrutiny from the security community. Researchers at Noma Security and Zenity Labs argue that AgentKit and the companion ChatGPT Apps SDK make agent building accessible to non-technical users, and that this accessibility creates a new class of ungoverned "shadow AI" risk inside organizations 2.

Their concerns fall into three main areas [2]:

• Prompt injection through workflow variables. Data moving through an agent's workflow can carry malicious instructions.
• MCP connectors as "exfiltration highways." Connectors that link agents to external tools and data can become channels for leaking information.
• Guardrails that classify rather than block. The built-in protections can flag threats, but the researchers say they don't necessarily stop them.

The most notable point is that OpenAI's own documentation appears to support part of the critique. It acknowledges that even when an MCP server comes from a trusted developer, safety can't be guaranteed, because untrusted data reached through those connectors remains an attack vector 2.

Why AgentKit changes the equation

The size of the shift becomes clearer when you look at what came before. OpenAI users could already customize agents with system prompts, knowledge bases, tools, and Model Context Protocol (MCP) servers 1. Building truly deterministic workflows, where an agent reliably follows a defined sequence of steps, was harder. It took either careful prompt engineering or an external orchestration platform such as LangGraph or n8n 1.

AgentKit brings that workflow capability into OpenAI's own environment. Noma frames this as both the product's main strength and its main weakness 1. Structured, multi-step agent logic no longer requires specialized skills or a separate toolchain. That is useful for productivity. It also means the people building these agents may be business users with little reason to think like attackers.

Where the two accounts agree, and where they differ in emphasis

Noma's write-up and the broader summary of the research tell the same basic story. AgentKit lowers the barrier to building agents, and lower barriers mean more agents built outside normal security review 12.

They differ mainly in focus. Noma's framing centers on the capability leap and what it means for the attack surface 1. The wider summary adds Zenity Labs' findings, brings in the Apps SDK, and places the issue in an organizational context. Its argument is that turning agent building into a platform feature is moving faster than application security teams can review what gets built 2. It describes the result as business-user workflows becoming "unaudited production risk" 2.

Reading the risk

None of these threat categories is new. Prompt injection has been a known weakness of LLM systems for years, and worries about agents with broad tool access have grown alongside MCP's adoption. What AgentKit changes is the scale and the identity of the builders.

This is a familiar enterprise IT pattern. Low-code and no-code tools tend to spread through organizations faster than governance can keep up. The same thing happened with spreadsheets full of business logic, unsanctioned SaaS apps, and citizen-developer automation platforms. The AI version carries higher stakes because these workflows don't just store or move data. They read untrusted inputs, interpret them as possible instructions, and act on them through connected systems.

The guardrails criticism matters most here. A classifier that labels a prompt as suspicious helps with visibility, but it isn't enforcement 2. If an organization assumes the platform's built-in protections will stop an injection attempt, and the protections only flag it, that gap is exactly where exfiltration happens. In practice, OpenAI's documentation saying untrusted connector data remains a vector 2 amounts to a statement that responsibility sits with whoever deploys the agent.

What security teams should take from this

AgentKit does not appear to introduce a single catastrophic flaw. The risk comes from making powerful, connector-rich agents easy to build for people who were never part of an AppSec review process 12. Organizations adopting it would be wise to treat agent workflows as production software. That means:

• keeping an inventory of what gets built,
• reviewing which MCP connectors each agent can reach,
• treating any data flowing through workflow variables as potentially hostile, and
• not mistaking threat classification for threat prevention.

Agent building has become easy for almost anyone. Securing those agents has not become any easier, and that is a gap security teams need to address.