{“lastseen”:”2026-05-12T10:46:30″,”description”:”\\n\\nAgentic AI is already running in production environments across many organizations today. It is executing tasks, consuming data, and taking actions \u2014 most likely without meaningful involvement from the security team. The industry conversation has largely framed this as a question of policy: allow it, restrict it, or monitor it? However, that framing misses the point. \\n\\nThe more urgent question is whether security professionals actually understand what they are dealing with. In most organizations, they don’t right now. And that gap is compounding by the week.\\n\\n## **You cannot secure what you do not understand**\\n\\nThe foundational principle of information security has not changed: genuine fluency in a technology must come before you can meaningfully defend it.\\n\\nThink about firewalls. You cannot configure one well without understanding networking. When cloud computing arrived, organizations that skipped the foundational work ended up with environments they could not reason about \u2014 tools purchased, policies written, and still no real control. We have cloud security as its own discipline today precisely because the technology demanded that practitioners develop deep familiarity with it before security could follow.\\n\\nThe same dynamic is playing out with AI, at a faster pace and with higher stakes.\\n\\nThe practical consequence of being behind on agentic AI goes beyond technical exposure. Security teams that cannot speak the language of AI engineering \u2014 that cannot challenge design decisions, propose workable controls, or ask informed questions \u2014 get bypassed. Business units move forward without them, not out of bad faith, but because a security team that cannot engage substantively with the technology is not a useful partner for decisions about it. This has played out with every major technology shift over the past two to three decades. AI will be no different.\\n\\nThe starting point is engagement. Try building an agent. Experiment with the tools your developers are already using. This hands-on familiarity is where real understanding begins, and real understanding is what makes everything else possible.\\n\\n## **Three categories of agents, three categories of risk**\\n\\nThe agentic AI landscape is broad, and the risk profile varies significantly across it. Three categories are worth understanding distinctly.\\n\\nThe first is **general-purpose coding and productivity agents** \u2014 tools like Claude Code and GitHub Copilot. These are already embedded in developer and engineering workflows across your organization. Whether they have been formally approved or not, they are being used. What data they can access, how they interact with codebases, and what actions they can take is baseline security knowledge at this point.\\n\\nThe second is **vendor-built agents powered by the Model Context Protocol** , or MCP. MCP is the integration layer that allows agents to connect to external services and act on their behalf. Nearly every major vendor either has an MCP server in production or is actively building one. In practice, this means an agent managing a user’s calendar, email, or internal ticketing system can receive input from those channels and act on it. A malicious calendar invite carrying hidden instructions in the event description is a real attack vector \u2014 the agent reads it, interprets the embedded prompt, and executes. This is a live attack surface that requires deliberate configuration and security review.\\n\\nThe third category is **custom agents built by individual users** , and this is where the dynamic gets particularly interesting. For years, a real barrier existed between security practitioners who understood risk and the code that ran in their environments. Most security professionals are not programmers. Building custom tooling required development skills that were not widely distributed across security teams.\\n\\nThat barrier is gone.\\n\\nWith agentic AI, anyone in the organization can build functional tools \u2014 automations, workflows, agents with real system access \u2014 without writing traditional code. For security teams, this is genuinely valuable. Incident investigation, forensic triage, threat hunting workflows \u2014 these can be accelerated when practitioners can build the tools they actually need. But that same capability extends to every other team. Marketing, finance, operations \u2014 everyone can build agents now. Many will. Most of those agents will not go through a security review before they go live. This is a supply chain problem in a different form.\\n\\n## **The cost of arriving late**\\n\\nWhen security teams lag behind on a major technology shift, the pattern is consistent.\\n\\nFirst, the rest of the organization moves forward without security input. Developers deploy, business units adopt, and security is consulted as a formality \u2014 or not at all. Second, the exposure compounds. The more powerful the agents an organization deploys, the more access those agents require. Broad permissions are what make agents useful: access to calendars, communication platforms, file systems, code repositories, internal APIs. That access is also what makes the blast radius significant when something goes wrong.\\n\\nAn agent with access to both a terminal and an email inbox can be manipulated through either channel to act in the other. That is a lateral movement path an attacker will look for. Reasoning about it requires understanding how the agent was built \u2014 the kind of understanding that only comes from genuine engagement with the technology.\\n\\n## **The skills that matter right now**\\n\\nBuilding competency in agentic AI security requires two distinct layers of knowledge.\\n\\nThe first is **understanding how AI applications are architected** \u2014 from a practitioner’s perspective, not a data scientist’s. What are the components of an AI application? How do agents consume inputs, chain tools together, and produce outputs? What does a session with an MCP-connected agent actually look like from an access control standpoint? This is the foundation that makes everything else actionable.\\n\\nThe second layer is **currency**. The tooling and threat landscape around AI is moving fast. Vendors are building security controls for AI systems, though most are still maturing. Open-source frameworks are emerging. OWASP and others are publishing threat taxonomies that evolve week to week. Once the foundational layer is in place, staying current becomes the ongoing discipline \u2014 knowing which tools are worth evaluating, which frameworks are gaining traction, and what questions to ask when vendors come in with solutions.\\n\\nThat second point matters more than it might seem. Security teams are already being approached by vendors selling AI security products. Without foundational knowledge of how these applications are built, those conversations are almost impossible to navigate well. You cannot distinguish a well-designed control from a marketing wrapper if you don’t understand what you’re trying to control.\\n\\n## **Configuration as a security control**\\n\\nMany agentic AI deployments carry risk because they were stood up without security-conscious configuration \u2014 not because the underlying tools are fundamentally broken.\\n\\nTake a self-hosted AI assistant connected to a communication channel like Telegram, which can be common. without proper controls, the agent could respond to anyone who messages it. That is a wide-open entry point. A simple configuration change \u2014 pairing the agent with a single trusted account \u2014 closes most of that exposure. One decision, made early, with a meaningful security outcome.\\n\\nThe broader principle is scope. An agent built to manage your calendar should not have access to your terminal. An agent processing incoming requests should not have write access to your code repository. Scoping agents to their intended function limits the blast radius and reduces the attack surface available for exploitation.\\n\\nThe tension is real: powerful agents need broad access to be useful. That is the trade-off organizations will push back on. Finding the right balance requires security involvement early in the design process \u2014 before the architecture is set and before the permissions are already in place.\\n\\n## **Getting ahead of it at SANSFIRE 2026**\\n\\nThe organizations building genuine AI security fluency now will be positioned to shape how these systems are deployed. Those who arrive late will find themselves, once again, applying controls to an architecture that was already decided without them.\\n\\nThis July, I will be teaching SEC545: GenAI and LLM Application Security at SANSFIRE 2026. The course covers how AI applications are actually built, how agentic systems work in practice, the real attack surfaces security teams need to understand, and the tools and controls available to address them \u2014 including hands-on work with techniques like model scanning to detect compromised models before they run in your environment. For practitioners who want to engage with AI systems from a foundation of real understanding, this is where to start. \\n\\n****\\n\\n\\u003e **Register for SANSFIRE 2026 here.**\\n\\n**Note:** _This article has been expertly written and contributed byAhmed Abugharbia, SANS Certified Instructor._\\n\\nFound this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.\\n”,”published”:”2026-05-12T10:30:00″,”modified”:”2026-05-12T10:30:00″,”type”:”thn”,”title”:”Why Agentic AI Is Security’s Next Blind Spot”,”source”:””,”references”:””,”id”:”THN:11F380113636A764307AAEDFADA2B6FB”,”bulletinFamily”:”info”,”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:\/\/thehackernews.com\/2026\/05\/why-agentic-ai-is-securitys-next-blind.html”,”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-05-12T10:46:30″,”description”:”\\n\\nAgentic AI is already running in production environments across many organizations today. It is executing tasks, consuming data, and taking actions \u2014 most likely without…<\/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,43,5],"class_list":["post-53339","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-thn","tag-vulnerability"],"yoast_head":"\n