This week, the theme is AI, with articles on securing APIs against agentic misuse and preventing unintended behaviors. We cover two critical vulnerabilities in AI platforms Langflow and Dify, both caused by API security flaws, and highlight a major data leak due to unauthenticated internal APIs. Finally, we look at an engaging conversation around using OpenAPI to auto-generate MCP servers.
Article: AI Agents prompted to attack APIs
First up this week, an article by Facundo Fernandez on security vulnerabilities in autonomous AI agents highlights a growing concern for securing APIs from AI agents. The article provides examples of how an AI agent might be abused to launch common API authorization attacks, such as BOLA and BFLA from the OWASP Top 10 API security vulnerabilities list.
Autonomous agents aren’t inherently malicious, but they don’t need to be. If you hand one an API token and let it loose with vague instructions, it might just exfiltrate data or perform sensitive actions purely by following what it thinks is a logical flow. The attacker doesn’t need to penetrate and exploit your APIs directly, they just need to socially engineer an AI agent.
At the end of the day, APIs are still gatekeepers to critical services and sensitive user data, and must ensure adequate and effective security on behalf of the user. So strong authentication and authorization will remain critically important API security controls. The bigger, or at least newer, challenge today seems to be fine-grained control over what agents are allowed to do via APIs, plus runtime validation that any API request from an AI agent aligns with expected behavior.
The takeaway: if autonomous agents are becoming first-class API clients, they need to be governed as such. Trust, but verify. And preferably, constrain.
Article: Securing APIs for agentic access
As a counter to the security concerns raised in the previous article, Kristopher Sandoval of NordicAPIs recently shared his take on “5 Ways to Secure Agentic Access to APIs”.
Unsurprisingly, securing APIs against the relatively unpredictable behavior of AI agents calls for some advanced and, at times, novel solutions.
Among the recommendations, using an identity framework like SPIFFE to authorize API consumption, layering behavior-based access controls on top of attribute-based ones, and developing your own internal agents to intercept and manage API calls.
But even for sophisticated clients, core API security policies and governance rules still need to be enforced by the API. If the baseline API security is lacking to begin with, any client, human or agent, can find and exploit API those gaps.
Vulnerability: API flaw exposes agentic AI workflow tool
An API vulnerability was recently discovered in Langflow, a popular open-source tool for building agentic AI workflows. The flaw centers on an unauthenticated API that executes untrusted user input using Python’s ‘exec’ function.
Researchers at Horizon3.ai published their findings after an exploit for the vulnerability was already made public. The issue allows an unauthenticated user to remotely execute malicious code on Langflow servers, effectively granting full control over the AI tool.
This incident highlights the importance of testing the exposed functionality of API endpoints that do not require authentication. Vulnerabilities can arise from two common errors: failing to enforce authentication when it should be required, or deliberately disabling authentication for an endpoint but unintentionally exposing sensitive data or privileged operations.
Open source tools like Langflow provide amazing value and the benefits of development velocity. But by adopting open-source tools and libraries, software teams inherit the burden of validating and securing that dependency.
Vulnerability: LLM platform API undermines client-side security
A recent security advisory highlights an API authorization vulnerability in Dify, an open-source LLM app development platform. This vulnerability allows non-admin users to enable or disable applications via the API, despite the web UI restricting this functionality to administrators.
The issue lies in the API’s failure to enforce proper authorization checks. While the UI correctly disables certain actions for non-admin users, the backend API does not validate the user’s role before processing requests to change application states. This discrepancy enables attackers to bypass frontend restrictions by directly interacting with the API.
APIs should never assume the frontend has handled authorization. Every API request must be authenticated and authorized independently to prevent unauthorized access or actions. Relying on the UI for security checks is insufficient, as APIs can be accessed through various tools or scripts, bypassing any client-side restrictions.
Vulnerability: Unprotected APIs expose 33,000 employees
In another recent report, unprotected APIs embedded in an internal web application were found exposing sensitive data of over 33,000 employees. These APIs returned names, contact details, device information, and internal project credentials, all without requiring authentication.
This incident is similar to the previous vulnerability discussed about the Dify platform: APIs servicing internal apps, whether web or mobile, are often deployed without proper security controls. In both cases, the problem wasn’t how users interacted with the application, but rather the lack of protection at the API layer.
Assuming APIs are internal or only accessible through a UI is a common mistake in API development.
As more functionality shifts to microservices and APIs, every endpoint becomes a potential entry point. If it handles sensitive data or critical actions, it must be authenticated and authorized, no exceptions.
Discussion: Kickstarting an MCP server with OpenAPI
42Crunch founder and CTO Philippe Leothaud’s recent LinkedIn post has sparked an engaging discussion on the evolution of API design and its impact on automation and interoperability. Philippe suggests that well-crafted APIs, complete with a comprehensive OpenAPI Specification (OAS), can pave the way for automatically generating Model-Context-Protocol (MCP) servers. This approach could significantly streamline the development process, reducing manual coding and enhancing consistency across services.
Several industry experts joined the conversation. Frank Kilcommins, Principal API Technical Evangelist at SmartBear, highlighted ongoing efforts to integrate MCP support into Swagger Codegen, referencing an open feature request on GitHub. Mark O Neill, VP Distinguished Analyst and Chief of Researcher at Gartner, pointed to potential challenges with using Arazzo in this context, specifically how to manage authorization across multiple APIs under a single MCP server. Erik Wilde from INNOQ also cautioned that automation doesn’t always produce optimal results, like generating OpenAPI specs from existing code.
Tools like Swagger Codegen already auto-generate SDKs and documentation from a well-crafted OpenAPI file, but the key to high-quality output lies in how precise and complete that description is. The richer the OpenAPI file, the more value you get from automation tools.
A timely and insightful discussion, well worth a read.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
