OpenAI AgentKit Security Risks: No-Code Agents Expand Threats

What happened

OpenAI's AgentKit was built to make AI agent development accessible to people who don't write code. Security researchers are now warning that the same accessibility opens new routes for attackers. Noma Security argues that AgentKit has democratized agent building while sharply enlarging the attack surface organizations need to defend 1. Zenity Labs reaches a similar conclusion. Researchers at both firms say AgentKit and the ChatGPT Apps SDK let non-technical users build agents outside normal governance, creating what they call "shadow AI" 2.

The researchers' concerns fall into three main areas [2]:

• Prompt injection through workflow variables. Data passed between steps in an agent workflow can carry malicious instructions.
• MCP connectors as "exfiltration highways." The Model Context Protocol links agents to outside tools and data. The researchers say those same links can carry sensitive data out.
• Guardrails that classify rather than block. The built-in protections flag suspicious inputs, but the researchers say they don't reliably stop them.

OpenAI's own caveats

The most telling detail may come from OpenAI itself. Its documentation concedes that even trusted MCP developers cannot guarantee safety, because untrusted data reached through a connector remains an attack vector 2.

This is not a vendor hiding a flaw. It is a structural limit that OpenAI openly acknowledges. When an agent reads email, documents, web pages, or ticket queues, every piece of content becomes possible input to the model's reasoning. Vetting the connector does not vet the data flowing through it.

This matters for how organizations judge risk. Teams often treat a trusted vendor or an approved integration as a security boundary. For agent systems, OpenAI's own wording suggests the boundary sits at the data, not the tool. Approving a connector from a reputable developer does not neutralize what that connector might pull in.

Why the no-code angle changes the picture

Prompt injection and data leakage through tool integrations are not new to AgentKit. Security teams have discussed them since large language models first gained tool access. The change is in who builds these systems and how fast.

The researchers frame the core problem as agent-building tools spreading faster than application security review processes can keep up 2. A business user can now assemble a working agent connected to company data without involving engineering or security. Such workflows can effectively reach production without the code review, threat modeling, or audit trail that traditional software would receive 2.

Noma's framing pairs "democratized" with "multiplied" for this reason 1. Each new builder is a possible new deployment. Each deployment wires together data sources and actions, and each of those connections could be abused. The risk grows with the number of agents, not the number of engineers.

Detection is not prevention

The guardrail critique deserves attention because it addresses a common assumption. Many users will reasonably expect that a platform shipping "guardrails" is stopping attacks. According to the researchers, AgentKit's guardrails mainly label threats rather than enforce outcomes 2.

That difference shapes how teams should use them. A classifier that spots a likely injection is useful, but only if something acts on the result. That could mean halting the workflow, removing a tool's permissions, or requiring human sign-off. If builders assume detection equals protection, they may ship agents with less defense than they believe.

Where the sources align, and what's missing

The two accounts point the same way. Noma's argument centers on the expanded attack surface 1. The wider coverage adds Zenity Labs' parallel findings and OpenAI's own caveat about MCP 2. Neither describes a specific exploited incident, so these warnings concern structural exposure rather than confirmed breaches.

The researchers' commercial interests are also worth noting. Both Noma and Zenity sell security tooling for AI agents. That doesn't make their analysis wrong, especially since OpenAI's documentation supports the central point. It does mean the framing is likely to stress urgency.

The takeaway

The reasonable reading is that AgentKit is not uniquely unsafe. It makes a known class of risk far easier to deploy at scale. The weaknesses the researchers describe are inherent to agents that read untrusted content and act on it. OpenAI has effectively said so itself 2.

The practical response is governance rather than avoidance. Organizations should know which agents exist and what each connector can reach. They should treat guardrail alerts as signals that require enforcement. And agent workflows should go through security review before they touch production data. Without that, agents built by business users will be a growing blind spot.