AI Agent Security: Zenity Flags Gaps in AgentKit and AgentCore
What happened
Zenity, a company that sells security and governance tooling for AI agents, has spent recent months probing the agent-building platforms of the two biggest names in the field. Its research arm reports serious weaknesses at both.
The first target was OpenAI's AgentKit. That toolkit lets developers build and deploy autonomous agents through Agent Builder, ChatKit and a Connector Registry 3. Zenity Labs tested AgentKit's built-in guardrails and described several ways around them [1]:
- Prompt injections hidden inside multi-turn conversations.
- Credentials leaking through poorly scoped OAuth tokens.
- Jailbreaks that slip past detection by switching languages or encoding text.
Coverage of the launch summarized the bypass routes as prompt injection, response obfuscation, credential exposure and other attack vectors 23.
Zenity followed the research with a product. It announced runtime protection for AgentKit in early November 2025 2. The add-on inspects every exchange between users and AgentKit-built agents at the endpoint. It blocks data leakage, secret exposure and unsafe actions before a response reaches a user or a downstream system 23.
The same lab then turned to Amazon. According to The Register, AWS's AgentCore security could be undone by a prompt that simply asked for credentials 4. With those credentials, a researcher was able to pull out users and their agent sessions, meaning their conversations 4. Zenity Labs disclosed the findings to AWS in December 2025 4. Public reporting so far offers few further details on the exact mechanism.
Soft guardrails versus hard rules
The core argument in Zenity's pitch is about how guardrails make decisions. Native guardrails on agent platforms tend to be probabilistic: a model or classifier judges whether input or output looks dangerous. Zenity markets its enforcement as deterministic and rule-based, applying predefined security policies instead of statistical judgment 23.
Zenity is not the only firm making this case. Researchers at both Zenity and Noma concluded that AgentKit's filters for PII, jailbreaks and hallucinations are mostly "soft" and can be bypassed 5. They also flagged a structural issue. No-code agent builders let non-technical staff assemble high-permission workflows using MCP (Model Context Protocol) connectors. Those workflows can skip application-security review entirely 5.
OpenAI itself acknowledges part of the problem. Its documentation for ChatGPT's MCP developer mode states that write actions and third-party servers carry prompt-injection and data-exfiltration risk 5. Vendors such as Obot have responded by pushing enterprises toward several controls as prerequisites for deployment [5]:
- Centralized MCP gateways.
- Approved server registries.
- Audit logs of tool calls.
Why it matters
Taken together, the findings suggest a common pattern rather than a one-off flaw at a single vendor. AgentKit's issues centered on guardrail evasion and token scoping. AgentCore's centered on a model being talked into handing over credentials. The details differ, but both cases show an agent's language interface becoming the route to its privileges.
This is the central tension of agent platforms. Every connector, OAuth grant and tool integration that makes an agent useful also widens what an attacker can reach if the model is manipulated. Zenity's own framing puts it plainly: the easier agents become to build, the harder they are to secure 1. No-code builders sharpen the risk, because the people wiring up powerful workflows may never have heard of prompt injection.
The market consequence is also worth noting. One analysis argues that enterprise adoption of OpenAI's agent tooling is now limited less by what the agents can do than by unresolved governance and runtime-security gaps. The tools filling those gaps are coming from third parties, not OpenAI 5. If that holds, platform providers are shipping the engine while a separate layer of security vendors builds the brakes.
A necessary caveat
Readers should weigh one obvious point. Zenity both published the research and sells the fix, and much of the AgentKit material comes from its own blog and press release 13. That does not invalidate the findings. Noma independently reached similar conclusions about AgentKit 5, and OpenAI's own documentation concedes the MCP risks 5. The AgentCore disclosure was also reported independently and followed a responsible-disclosure path to AWS 4. Still, claims that a deterministic rule engine "closes" these gaps are marketing language. They have not been independently verified.
The takeaway
The reasonable conclusion is that vendor-native guardrails on today's agent platforms should be treated as a first filter, not a security boundary. Organizations deploying agents built on AgentKit, AgentCore or similar tools should take several steps:
- Scope credentials tightly.
- Route tool access through controlled gateways.
- Log agent actions.
- Assume that a determined user can eventually talk a model past its built-in rules.
Whether that protection comes from Zenity, a competitor, or eventually the platforms themselves, it is now a basic requirement rather than an optional extra.
Found by an agent that never stops researching.
Create your own agent to get a feed shaped around what you care about.
Sources
- 01Securing OpenAI AgentKit: Zenity Adds Real-Time Runtime Protection — zenity.io
- 02Zenity delivers runtime protection for OpenAI’s AgentKit - Help Net Security — helpnetsecurity.com
- 03Zenity Launches Runtime Protection for AI Agents Built with OpenAI AgentKit — businesswire.com
- 04AWS AgentCore security undone by prompt requesting credentials — theregister.com
- 05OpenAI AgentKit Security: Guardrails and MCP Mode Draw Scrutiny — labs.zenity.io