Vineet Arora, CTO & Co-Founder, WinWire, with 30+ years in IT Consulting helping CxOs drive Business Transformation thru AgenticAI Solutions
getty
Gartner’s latest projection puts it plainly: "By 2028, 25% of all enterprise generative AI (GenAI) applications will experience at least five minor security incidents per year, up from 9% in 2025." And by 2029, 15% will face at least one major incident, up from 3% in 2025. Numbers like that land differently when you have seen what an incident looks like.
Last year, researchers at Aim Labs disclosed EchoLeak, a zero-click vulnerability in Microsoft 365 Copilot. A crafted email, without links or attachments, could cause the agent to follow hidden instructions and expose sensitive data within its access scope. Microsoft patched the issue before any known real-world exploitation.
A few months later, Noma Labs disclosed ForcedLeak, a critical vulnerability in Salesforce Agentforce, where malicious instructions embedded in Web-to-Lead form fields could be executed by AI agents, enabling the exfiltration of sensitive CRM data.
In both cases, the defenders got lucky that the researchers found the flaw first.
The second category of incident is already live in production. In developer tooling, there are emerging reports of agent misexecution. For example, a documented issue involving Google’s Gemini CLI describes unintended file operations that resulted in data loss, with the system later acknowledging failure. In another widely reported incident, an AI coding agent from Replit deleted a production database during a development workflow, prompting a public apology from the company’s CEO.
The OWASP Foundation responded by releasing its first Top 10 for Agentic Applications, cataloging the 10 highest-impact threats specific to autonomous AI systems. It reads less like a traditional vulnerability report and more like a reckoning with what happens when software can plan, decide and act on our behalf without anyone rethinking how we secure it.
I spend most of my time working with enterprises that are building and governing agentic systems. The question I get asked most often is whether existing security tools can handle this. Traditional controls were designed to catch bad actors, not well-intentioned systems operating beyond their intended scope. If the risk lives in permissions, memory, tools and what agents decide to do on their own, security must be part of how the thing gets built.
Each of the 10 OWASP risks maps to a design constraint that either exists before the agent ever reaches production or does not. That distinction separates the agents that should be deployed.
Start with what the agent can reach. Agents should be built from predefined actions, vetted connectors and scoped capabilities, not assembled from an open plugin marketplace where an unvetted component enters the execution chain. Administrators govern which connectors are available. Custom logic runs in sandboxed environments. That single design decision addresses unexpected code execution (ASI05), tool misuse and exploitation (ASI02) and agentic supply chain vulnerability (ASI04) through architecture, rather than through policy documents sitting in a SharePoint folder nobody reads.
Identity is where most agentic deployments get it wrong. I have watched it happen. An agent that inherits a service account’s broad permissions can access anything that account touches. The better pattern is for agents to operate under the end user’s directory permissions by default, so a compromised agent can only access what that specific user can access. That constraint limits the blast radius of agent goal hijack (ASI01) and identity and privilege abuse (ASI03) before anyone writes a security policy.
Memory is the other risk, one that rarely surfaces in procurement conversations. Agents that retain context across sessions give attackers a persistent foothold. If session memory does not carry over between conversations and there is no shared global memory store, memory and context poisoning (ASI06) has nowhere to live.
Multiagent connections should require explicit configuration rather than automatic trust inheritance, which closes the door on insecure inter-agent communication (ASI07) by default, not by exception.
Containment handles what is left. Agents that cannot rewrite their own logic without going through a full republish cycle are the structural answer to rogue agents (ASI10). Monitoring and quotas function as circuit breakers against cascading failures (ASI08). For the highest-stakes actions, human-in-the-loop configurations require explicit confirmation before execution. That is not a feature toggle. It is the only reliable defense against the kind of human-agent trust exploitation (ASI09) that lets a finance manager approve a fraudulent payment because the copilot said it was urgent.
Architecture only gets you halfway. A well-designed agent still needs watching once it hits production. Good design reduces risk at the start. Visibility is what catches the risk that accumulates after.
At one enterprise we recently worked with, the finance, sales and customer experience teams had each deployed AI agents independently: different tools, no shared governance and no audit trail connecting any of them. The fix was unglamorous. It involved a tenant-wide control plane with role-based access, centralized policy enforcement and audit logging that worked across every agent regardless of how it was built or who built it. For the first time, leadership had a single view of agent activity across the business, and IT could answer the question, “How many agents do we have?”
A control plane of that kind is now emerging across the major enterprise platforms. Whether you standardize on one vendor’s fleet-management layer or build a multi-platform inventory yourself, the requirement is the same. You need a single place to observe, govern and secure every agent in the tenant, with detailed logging, risk reporting and audit trails across the entire fleet.
The OWASP Agentic Top 10 makes something clear that the industry has been slow to acknowledge: Agents amplify existing vulnerabilities. The document’s authors put it directly: "Deploying agentic behavior where it is not needed expands the attack surface without adding value." They call it the principle of "least agency."
The conversation about agentic security should not start with which threats to mitigate. It should start with whether you need an agent at all and, if you do, whether the platform you are building on treats security as part of the architecture or as an afterthought. That is the question worth answering before the next deployment, not after the first incident.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。