{“lastseen”:”2026-04-28T12:07:14″,”description”:”Most organizations treating AI security as a model problem are defending the wrong layer. Security teams filter prompts, patch jailbreaks, and tune model behavior, which is all necessary work, while the actual attack surface sits largely unexamined underneath. That surface is the API layer: the endpoints AI systems use to retrieve data, call tools, and take action on behalf of users.\\n\\nThis isn’t a theoretical gap. According to Wallarm’s 2026 ThreatStats Report, 36% of AI vulnerabilities are actually API vulnerabilities. Attackers aren’t inventing new techniques for AI systems; they’re reusing proven API abuse patterns against a rapidly expanding, often undocumented set of endpoints.\\n\\nHere are six lessons security leaders need to internalize about where AI risk actually lives, and what it takes to control it.\\n\\n## 1\\\\. AI Risk Lives in the API Layer, Not the Model\\n\\nMost organizations start their AI security efforts by securing the model. These are all vital protections, but they fail to consider AI\u2019s primary risk surface: APIs. \\n\\nAPIs are essentially the control plane for AI. They enable agents to retrieve information, update systems, and execute workflows. They define how AI systems interact with the rest of your business. They allow AI systems to:\\n\\n * Retrieve data through RAG pipelines\\n * Execute actions through agent tools\\n * Connect to internal systems like databases, CRMs, and SaaS platforms\\n\\n\\n\\nThink of it like this: AI doesn\u2019t actually act. APIs act for it. If an attacker compromises the model, they can manipulate the logic of its responses; if they compromise the API, they can hijack the actions the system performs. That includes accessing sensitive data, triggering transactions or workflows, modifying system states, or moving laterally across connected devices. \\n\\n## 2\\\\. You Can’t Secure What You Can’t See\\n\\nBefore you can secure APIs and, hence, AI, you need to know they exist. \\n\\nAI development is supercharging API sprawl. Teams are rapidly building new capabilities and deploying endpoints to support model inference, connect to external data sources, enable agent-driven actions, and orchestrate internal workflows. That wouldn\u2019t be a problem, except they often don\u2019t go through a formal security review. \\n\\nThat\u2019s how shadow APIs appear. \\n\\nShadow APIs are production endpoints that security teams don\u2019t know about. And when security teams don\u2019t know about APIs, they can\u2019t enforce authentication or authorization, test them for vulnerabilities, monitor their use, or detect abuse. 81% of APIs expose sensitive data, so securing all of them is crucial. \\n\\nPeriodic inventories assume that your API surface is stable. That used to be the case, but the rapid rate of change AI has introduced has changed that. By the time you\u2019ve \u201cfinished\u201d documenting your APIs, new ones will already exist. \\n\\nThat\u2019s why you need continuous visibility into your API environment. Wallarm API Discovery provides:\\n\\n * Automatic discovery of APIs as they\u2019re created\\n * Tracking changes in real time\\n * Maintaining an up-to-date inventory of all endpoints\\n * Understanding where sensitive data is flowing\\n\\n\\n\\nThis is where API security begins. \\n\\n## 3\\\\. Treat AI Agents as Users and Authorize Them Accordingly\\n\\nAgentic AI breaks traditional assumptions about how authorization works. Agents act autonomously, hold their own credentials, and chain API calls across internal systems. The mental model most security programs still use \u2014 users act, systems respond, permissions follow human identity \u2014 no longer fits. The agent is now the actor.\\n\\nAgents themselves decide which APIs to call, what data to retrieve, and what actions to execute using the permissions they have been given. That means if an actor manipulates an agent, the agent will act on their behalf, allowing them to:\\n\\n * Access sensitive systems\\n * Execute privileged actions\\n * Chain operations across multiple services\\n * Move laterally through your environment\\n\\n\\n\\nThe problem is that many organizations still think about agents as applications, not actors. They grant them excessive agency, which allows attackers to escalate their privileges. As such, security leaders must think explicitly about:\\n\\n * How agent credentials are issued and managed\\n * What tools and API agents are allowed to access\\n * How permissions are scoped and limited\\n * How services authenticate and trust each other\\n\\n\\n\\n## 4\\\\. Traditional Security Tools Miss the Attacks that Matter in AI Environments\\n\\nMost security tools assume that malicious traffic looks obviously malicious. But API attacks in AI environments often appear to be normal, legitimate activity. \\n\\nToday, attackers use valid authentication, properly formatted requests, and legitimate-looking traffic. They exploit business logic flaws, excessive permissions, and undocumented or forgotten endpoints. In short, attackers use systems as they were designed, just not in ways you intended. \\n\\nTraditional tools can\u2019t pick that up. \\n\\nWAFs pattern-match on known signatures, so if the request looks valid, it passes. SIEMs collect logs, but API environments generate massive volumes of data, and the signal gets lost in the noise. DAST tools can only test what you\u2019ve already discovered, so if an API isn\u2019t known, it isn\u2019t tested.\\n\\nMany security leaders turn to point-in-time pentests to address these challenges, but they can\u2019t keep pace with the pace of AI deployment. The solution really lies in: \\n\\n * Behavioral analysis that shows how APIs are used.\\n * Context across workflows\\n * Runtime enforcement that can stop abuse as it happens\\n\\n\\n\\nBecause AI-era API security requires behavioral analysis and runtime enforcement, not signature matching.\\n\\n## 5\\\\. Governance Requires Both Visibility and Enforcement\\n\\nYou\u2019re aware of your AI risk. But are you actually controlling it? \\n\\nThe EU AI Act requires documented evidence of control over high-risk AI systems. Boards now ask for defensible reporting. That means showing that you know what systems exist, what risks are present, what controls are in place, and that you\u2019re actually enforcing those controls. \\n\\nThat evidence comes from the API layer, where data is accessed, decisions are triggered, and actions are executed. If you can\u2019t see and control what\u2019s happening there, you can\u2019t prove governance. That visibility relies on:\\n\\n * Continuous monitoring of API activity\\n * Enforcement on policies in real-time\\n * Audit-ready records that show what happened and when\\n\\n\\n\\nIt\u2019s not enough to show you understand risk \u2013 in the AI era, you need to prove you can control it. \\n\\n## 6\\\\. API Security Must Move at AI’s Deployment Speed\\n\\nAs noted, AI-driven environments are inherently in flux. New APIs, integrations, data sources, and agents ship constantly. And yet, too many organizations still rely on point-in-time \u2013 quarterly or annual \u2013 security reviews that can\u2019t keep pace with AI deployment speed. \\n\\n97% of API vulnerabilities can be exploited in a single request, meaning there\u2019s no window for delayed detection. Essentially, if your controls aren\u2019t in place at runtime, they might as well not exist. \\n\\nSecurity must be continuous \u2013 discovering APIs as they\u2019re created, integrated into CI\/CD pipelines, and enforced at runtime. That\u2019s exactly what Wallarm does. \\n\\n## AI Security Starts with APIs\\n\\nThe through-line across these six lessons is simple: AI security is API security applied to a faster, more autonomous, and more consequential environment. The risk has moved from the model to the layer beneath it. The pace of change has outrun point-in-time controls. And the governance expectations \u2014 from boards, regulators, and auditors \u2014 now require evidence that only the API layer can produce.\\n\\nSecurity leaders who treat AI and API security as separate programs will keep finding gaps between them. The ones who recognize they’re the same problem, at different altitudes, will be positioned to enable AI innovation without compromising control.\\n\\nSchedule a demo with Wallarm to see how you can discover your complete API inventory, assess your APIs for risk, and block attacks in real time.\\n\\nThe post 6 Lessons Security Leaders Must Learn About AI and APIs appeared first on Wallarm.”,”published”:”2026-04-28T11:00:00″,”modified”:”2026-04-28T11:00:00″,”type”:”wallarmlab”,”title”:”6 Lessons Security Leaders Must Learn About AI and APIs”,”source”:””,”references”:””,”id”:”WALLARMLAB:B3F040CCD47A73357D4DB09E9D6BE014″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/lab.wallarm.com\/6-lessons-security-leaders-must-learn-about-ai-and-apis\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-28T12:07:14″,”description”:”Most organizations treating AI security as a model problem are defending the wrong layer. Security teams filter prompts, patch jailbreaks, and tune model behavior, which…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,13,33,7,11,5,105],"class_list":["post-49910","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability","tag-wallarmlab"],"yoast_head":"\n