"Agentic AI is already running in production environments across many organizations today," Ahmed Abugharbia wrote, and security teams largely do not understand what they are facing.
Three categories of agents: Claude Code and GitHub Copilot, MCP vendors, and custom agents
Abugharbia separates agentic AI into three practical buckets that matter for defenders. The first is general-purpose coding and productivity agents — examples named in the piece include Claude Code and GitHub Copilot — which are already embedded in developer workflows and therefore represent baseline security knowledge. The second is vendor-built agents powered by the Model Context Protocol (MCP), the integration layer that lets agents connect to external services and act on users' behalf; in practice this can mean an agent managing a calendar, email, or ticketing system and receiving inputs from those channels. The third is custom agents built by individual users: tools, automations, and agents that non-developers can now assemble without traditional coding skills.
MCP-powered agents and a real attack surface
The MCP-enabled model creates concrete, exploitable channels. Abugharbia gives a clear example: an agent that manages a user's calendar can receive a malicious calendar invite with hidden instructions embedded in the event description; the agent reads the embedded prompt and executes. That combination — integration into everyday systems plus the ability to act on inputs — is presented as a live attack surface that demands deliberate configuration and security review.
Custom agents as a new supply chain problem
Where custom agents matter most is in who can now build them. Abugharbia argues the historical barrier between security practitioners and operational code has disappeared: "anyone in the organization can build functional tools — automations, workflows, agents with real system access — without writing traditional code." That capability accelerates useful work inside security — for incident investigation, threat hunting, and triage — but it also multiplies unreviewed endpoints across marketing, finance, operations, and elsewhere. Most of those agents, he warns, will not go through a security review before they go live, effectively creating a new form of supply chain risk.
The cost of arriving late: broad permissions and lateral movement
Abugharbia lays out a familiar pattern when security teams lag: the rest of the organization moves forward without security input; exposure compounds as agents gain broader access; and blast radius increases because agents often need permission to calendars, communication platforms, file systems, code repositories, and internal APIs to be useful. He emphasizes a specific lateral-movement risk: "An 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."
Skills, configuration, and the practical controls
The article identifies two layers of knowledge security teams need. First, practitioners must understand AI application architecture from an operational perspective: how agents consume inputs, chain tools, and what a session with an MCP-connected agent looks like from an access-control standpoint. Second, teams must remain current as tooling, threat taxonomies, and vendor controls evolve. Abugharbia stresses that many risky deployments stem not from fundamentally broken tools but from insecure configuration: for example, a self-hosted assistant connected to Telegram that responds to anyone who messages it can be closed to most exposure by pairing the agent with a single trusted account. The broader principle: scope agents strictly to intended functions — a calendar agent should not have terminal access, and a request-processing agent should not have write access to a code repository.
What this means for security teams, business units, and vendors
- Security teams: Without hands-on familiarity, they risk being bypassed and unable to challenge design decisions, propose workable controls, or ask informed questions. Abugharbia's prescription is practical: "Try building an agent. Experiment with the tools your developers are already using."
- Business units and developers: They will continue to deploy agents to realize productivity gains; absent early security involvement, those deployments will shape architectures and permissions that are costly to change later.
- Vendors and product teams: Many vendors already have MCP servers in production or are building them, and are marketing AI security controls — but the article warns that security teams lacking foundational knowledge will struggle to separate substantive controls from marketing wrappers.
Getting ahead at SANSFIRE 2026: SEC545 and hands-on work
Abugharbia will teach SEC545: GenAI and LLM Application Security at SANSFIRE 2026 in July. The course, he says, covers how AI applications are built, how agentic systems function in practice, the attack surfaces security teams need to understand, and the tools and controls available — including hands-on techniques such as model scanning to detect compromised models before they run in production. For practitioners who want to engage with AI systems from "a foundation of real understanding," Abugharbia presents this class as a concrete starting point.
In short: the immediate task is not only deciding whether to allow, restrict, or monitor agentic AI. It is to gain fluency. As Abugharbia puts it, "You cannot secure what you do not understand" — and the way to begin is practical engagement, configuration discipline, and early security involvement in design.
https://thehackernews.com/2026/05/why-agentic-ai-is-securitys-next-blind.html
