AI Security Crisis: Shady AI and Autonomous Agents Expose Enterprise Vulnerabilities

Why "Shady AI" is Security's Next Big Governance Problem

In March 2026, an internal AI agent at Meta triggered a "Sev 1" incident after sensitive company and user data was exposed to employees who weren't authorized to access it. The incident began when a Meta employee posted a technical question on an internal forum. An engineer used an approved AI agent to analyze it, but the agent posted its response publicly without approval. The employee followed its advice, inadvertently making a large volume of sensitive data available to unauthorized engineers for over two hours. This was not shadow AI. The tool was approved, but the AI behaved in ways nobody had anticipated. It's a perfect example of security's next big AI governance problem: shady AI. * Shadow AI is the unapproved use of AI tools * Shady AI is when employees use approved AI tools in unapproved, unexpected, or poorly governed ways Shadow AI happens outside the organization's visibility. Shady AI happens inside it. And that makes it much harder to see, control, and govern. The rise of shady AI AI governance isn't solely a security responsibility. But when AI touches sensitive data, enterprise systems, or access controls, security has a critical role to play. A July 2026 SANS survey found that 76% of security teams now have a role in governing enterprise AI. But security teams don't just need to worry about shadow AI. They need to think about shady AI, too. The difference matters because approving a tool is no longer the same thing as approving its use. You can block or ban an unsanctioned tool, but you can't simply block something you've already approved and rolled out across the organization. The control lever security teams are used to pulling doesn't exist here. Like shadow AI, shady AI has real consequences: * Security risks like increased exposure to data breaches, regulatory incidents, and data exfiltration * Financial costs from rising AI spend, including tokens spent on duplicative or unimportant tasks * Organizational drag as tightened controls block innovation and increase friction for employees * Security and IT team burnout as time is spent on retroactive governance and tool audits instead of proactively reducing the attack surface and strengthening access controls What's driving shady AI? There are three main reasons why shady AI is happening now. 1. The proliferation of approved AI tools As organizations continue to invest in AI tools, the opportunities for shady AI grow. Like SaaS sprawl before it, increased adoption creates a larger, more complex AI tech stack for security and IT to govern. With limited resources, it's increasingly difficult to understand how every AI capability is being used across every tool and system. 2. Permissions are broad by default AI is now woven into the tools that employees already use, and the functionality expands faster than security teams can keep up. An approved AI assistant might start as a way to summarize documents, then gain the ability to search internal knowledge, access business applications, create workflows, or take actions on an employee's behalf. Enterprise-grade compliance and security features - like restricting AI tool usage to devices on a company domain - are often gated behind the most expensive licensing tiers, while the AI features themselves are available by default. The tool hasn't necessarily changed from a governance perspective. What employees can do with it has. 3. Usage patterns evolve faster than policy can Employees can use AI embedded into approved tools to build applications and deploy them before security and IT even know they exist. Organizations can lock down controls to prohibit one risky practice only to find that employees have already adopted a new tool or discovered another route to the same outcome. The result is a widening gap between what policy says employees should do and what AI makes possible. What traditional governance misses Traditional governance is built around defining what's allowed and training employees to follow the rules. That works better when the technology and its use cases are predictable. AI makes both moving targets. 1. Policies can't anticipate every use case An Acceptable Use Policy (AUP) can establish principles, but it can't anticipate every new capability an AI tool might gain, or every way employees might use it. An approved AI assistant might be cleared for summarizing documents today, then gain the ability to search internal knowledge, access business applications, create workflows, or take actions on an employee's behalf tomorrow. 2. Training can't keep pace One-time training can't account for constantly evolving AI capabilities and usage patterns. Many non-technical employees also don't yet have a mental model for secure, responsible AI use. The rules are written in a vocabulary nobody taught them, making it difficult to apply principles like least privilege or secrets management. 3. Restrictions create workarounds Locking down individual capabilities can address a specific risk, but it doesn't solve the underlying problem. As AI capabilities evolve, employees may find another way to accomplish the same task - potentially making usage harder for security to see. The result is a governance model that's always playing catch-up. What actually works: governance by default The answer is making the easiest, most visible path the governed one. In practice, this means giving employees a place to build with AI where the necessary permissions, access controls, and oversight are built in -- rather than relying on employees to figure out the rules themselves. Instead of trying to predict every risky AI use case in advance, organizations can build governance into the environment where employees create and deploy AI-assisted workflows. That means controlling access to data and systems, applying appropriate permissions, maintaining visibility into what has been built, and putting controls around what AI-powered applications and agents can do. When creation, execution, and monitoring take place within a single environment, everybody benefits: * Employees can build and deploy fast within security-mandated boundaries, and use their unique subject matter expertise to solve problems, enhance workflows, and make meaningful improvements to their day-to-day work * IT and security teams can maintain visibility, apply consistent controls, reduce manual governance work, and scale AI adoption with confidence Governance stops being a roadblock. Instead, it's the path of least resistance. From blocker to strategic enabler Security doesn't need to choose between enabling AI adoption and mitigating risk. The goal is to make the governed path an easy one for employees to follow. By empowering employees to build in a secure environment with access only to tools and data they're authorized to use, security can spend less time chasing unexpected AI usage and more time proactively reducing the attack surface, strengthening access controls, and enabling the business to move faster. That's the approach behind Tines 3B, which gives teams the power to build AI-assisted apps, agents, and automations while giving security and IT teams the control and visibility to govern them. Get started for free with the Explore Edition.

The Modern Attack Chain: Rethinking Google Workspace Security in the Age of AI

By Rajan Kapoor, VP Security, Material Security Over the past two months, I've written about the Vercel breach and the Composio breach separately. Both offer lessons to learn on their own. But reading them together, I keep coming back to the same observation: these aren't isolated incidents They're the same attack, run twice, against different targets, where email was not the entry point into the workspace. And once you see the pattern clearly, it changes what you think you need to defend. It also raises an uncomfortable question that I've been sitting with. The pattern I'm describing, where an OAuth grant is used to access an account, read sensitive data from email and Drive, and use that access to move past the workspace, doesn't only describe what attackers do. It increasingly describes what AI agents do, by design, every day. Before jumping into that discussion, let's take a moment to map out the workspace attack chain. The old mental model: email is where the danger lies For most of the last decade, the dominant mental model for workspace security looked something like this: email is the dangerous channel, and everything else in Google Workspace is relatively safe. That model made sense when attackers were primarily trying to steal credentials through phishing. It doesn't hold anymore because attackers have learned to chain their way through the workspace, not just get in via an inbox. The model most security teams are familiar with looks something like this: * Email is the entry point: A malicious email (a phishing link, a weaponized attachment, a convincing pretext, a prompt intended to misdirect an AI agent) is how most attacks begin. * A credential is stolen: The attack results in a valid credential being stolen and an account takeover happening. * Sensitive data is accessed in Gmail and Drive: Once the takeover happens, the attacker easily jumps to connected apps within Google Workspace. * Lateral pivots: An attacker inside an inbox can reset passwords and get into additional apps via magic links. * Establish persistence: Attackers can sit undetected within accounts for days, weeks, or months, quietly exfiltrating data across systems. Taken together, this is the nightmare scenario that is widely recognized as the account takeover (ATO). The workspace attack chain begins with an identity compromise via email and expands from there. The evolving attack chain: OAuth is the entry point The elements of the workspace attack chain attack haven't changed, but the order in which the attacks unfold has evolved. The sequence I've now watched play out across Vercel, Composio, and a growing number of incidents we're tracking doesn't start with email at all. Instead, the script gets flipped and an OAuth token becomes the entryway into email, not the other way around. Here's what these attacks looked like: * OAuth is the entry point: These attacks started by establishing persistence through a stolen OAuth token. These tokens survive password resets, don't expire, and are hard to observe. They are invisible to users and largely invisible to security teams who aren't monitoring app behavior. Even scarier, the stolen token is a supply chain attack. A supplier is compromised and the result is access into your environment. * Sensitive data is accessed: Using the stolen token, the attacker was able to get into data stored in Gmail and Drive. * Email accounts are taken over: The ATO is initially executed using OAuth, not email. The access to email converts a compromised inbox into a much broader incident. * Lateral pivots: Using a combination of credentials stored in Drive and password resets or magic links via email,the attacker can then move laterally across connected systems. We can anticipate that the building blocks of the workspace attack chain will remain consistent, but that attackers - equipped with AI tools to sniff out vulnerabilities and scale their efforts - will continue to find ways to recombine them. These OAuth-centric attacks are only one example of this evolution. The same chains, a different actor Now let's shift our thinking, while keeping those four-step sequences I just described in our minds. Your employees are connecting AI agents to Google Workspace right now. Those agents are authorized. They're using legitimate OAuth grants. They're reading email, searching Drive, operating on behalf of real users to do real work. In most organizations, this is happening faster than security teams can track it. When an AI agent behaves unexpectedly -- because its instructions were ambiguous, because it followed a chain of reasoning its developers didn't anticipate, because it was fed a prompt through content it encountered in the environment -- it can walk the same path as an attacker: * It accesses an inbox or Drive folder it wasn't explicitly intended to reach, because its scope was broader than its task required. * It reads sensitive content like credentials in email threads or confidential documents in shared drives and makes use of that information. * It takes an action downstream from that access: sending a message, following a link, making a request to another service. * It moves laterally across applications and sensitive information winds up getting exfiltrated to a third party. No malicious actor. No compromised credential. Just an agent doing something its operator didn't intend, in an environment that didn't have the controls to stop it. Why this matters for how you think about defense Most conversations about AI agent security are framed around preventing prompt injection, red-teaming agent behavior, or reviewing what apps your employees are connecting. Those are real problems and worth solving. But the threat I'm describing isn't about an agent being weaponized. It's about an agent operating exactly as it was built to operate, in an environment where the guardrails weren't designed with that kind of actor in mind. A human operator acting in an environment where they've been overpermissioned will generally know how to navigate this situation using a combination of common sense and understanding of company norms and policies. OAuth tokens granted to an AI agent carry the same access as tokens granted to a person, but the agent won't understand that it's been overpermissioned before it acts. It will simply do what it needs to do in order to execute the task. The controls that matter here aren't controls on the agent. They're controls on the environment the agent operates in. If you know where sensitive data lives across email and Drive, you can enforce policies that restrict access to it before an agent (or an attacker) gets there. If you're investigating OAuth grants, you can understand and limit exposure to the prying eyes of an attacker or an errant agent. If you can redact password reset links and require step-up verification before sensitive inbox content is readable, it doesn't matter whether the entity trying to access that content is an attacker or an agent acting outside its intended scope. The same coverage that defends against the modern attack chain also defends against the modern agent risk. They're the same problem, wearing different hats. What defense looks like across the full chain I don't think the answer is to add more point solutions to each stage of this chain. I think the answer is coverage that understands the chain as a chain, that can see what's happening across email, OAuth, Drive, and account behavior, and connect the dots before things go wrong at step three or four. That's what we've built at Material. Here's how our coverage maps to each step: Blocking the initial email payload. Our email security is designed to catch what native controls miss: sophisticated phishing, payloads that bypass reputation-based filters, attacker-in-the-middle techniques. Stopping the most common attack method before it starts remains the highest-leverage intervention for the malicious threat. Detecting suspicious OAuth behavior. Material goes beyond cataloging what apps exist and what scopes they hold. The platform watches what apps actually do: what they read, when they read it, how that behavior changes over time. Whether an OAuth token is being used by an attacker or an AI agent operating outside its intended parameters, anomalous behavior at the activity layer surfaces the danger. Detecting and protecting sensitive data at rest. You can't protect what you can't see, and you can't design a policy around access you don't know exists. Material's file security gives teams visibility into where sensitive data lives across email and Drive: which shared drives carry broad access, which email threads contain credentials or PII, which Drive folders are exposed beyond their intended audience. This is the foundation for enforcing least-privilege access against any actor, human or automated. Blocking lateral movement via password resets. Material can redact sensitive message content, including password reset links, and require step-up verification before that content becomes accessible. An attacker with inbox access can't use it as a pivot point if the reset links aren't available in plaintext. An AI agent reaching the inbox looking for something to act on encounters the same restriction. The pattern is going to repeat Vercel. Composio. I expect this list will keep growing, and I expect the next entries on it won't always fit neatly into the category of "external attacker." Some of them will involve AI agents doing something unexpected. Some will involve overpermissioned integrations that reach data they were never supposed to see. The mechanism will look familiar even when the story around it doesn't. The right response isn't to be alarmed about AI agents or to slow down adoption. Agents are genuinely useful and the productivity case for them is real. The right response is to recognize that the workspace those agents operate in needs controls that are appropriate for a world where OAuth-authenticated software (authorized or not) is a first-class actor in your environment. If your Google Workspace security strategy ends at the inbox, it has a gap. That gap is exactly where the modern attack chain runs, and it's exactly where an AI agent operating outside its intended scope will run too. If you want to talk through what full-chain workspace coverage looks like for your environment, reach out to us at Material Security.

AI agents are inside the enterprise - are your security foundations ready for them?

The recent release of Anthropic Mythos is a wake-up call for the tech industry - and the fact that Anthropic themselves chose not to release it publicly speaks volumes about the level of risk we have now reached. AI agents have evolved from chatbots with upgraded capabilities to effective employees with database access, API keys, and system privileges. However, the security protecting them is built on the same strategy that failed to stop ChatGPT jailbreaks in 2023. And this time, there's no human to review an agent's output, just an autonomous agent carrying out commands in a silo. AI agents are reshaping enterprise systems and the way work gets done. Securing them requires an equally fundamental shift in thinking. Ultimately, now that agents act independently, resilience must be rooted in foundational controls, including hardware-level and lower-stack security, to be ready when the higher-level safeguards fail. How AI agents expand the attack surface Before agentic AI, the biggest AI risks were bad recommendations, inappropriate responses, and conversational data exposure. Human oversight acted as a safeguard for every action, and AI systems operated without direct access to sensitive information. The primary concern was reputational damage rather than risks to underlying infrastructure. When Anthropic released the Model Context Protocol (MCP) in November 2024, it established a standardized framework that allows AI agents to connect to databases, file systems, and enterprise tools. But within eight months, a critical vulnerability emerged (CVE-2025-49596, CVSS9.4), triggering emergency security responses across the industry. The risk came from four factors working together. Autonomy means agents can decide and act without human review. Privileged access gives them credentials, tokens and file system permissions. Machine-speed execution leaves little time for human intervention. And cross-system reach means one compromised agent can move across connected environments. Together, these factors expanded the attack surface far beyond what traditional security controls - even AI-enabled ones - were built to manage. Why software-only defences keep falling short The industry is moving quickly to secure AI agents, but the response largely mirrors a familiar approach: adding more layers of software. Most companies are focusing on two main layers: input guardrails - implementing more software tools designed to stop malicious instructions from ever reaching AI agents, and permissions and monitoring - limiting what compromised agents can access. It's the same strategy the industry had relied on for decades: deploy quickly, remain agile, and address vulnerabilities as they emerge. Both methods operate inside the software trust boundary. But history shows this approach often ends the same way: with the need for hardware-layer protections. In the 1990s and 2000s, network security responded to software exploits by deploying additional software layers. Breaches persisted until organizations eventually adopted hardware-enforced network segmentation. The same pattern played out with endpoint security in the 2000s and 2010s. As malware evolved to bypass detection, the response was behavioral analysis, sandboxing, and endpoint detection and response. Yet more software. Breaches continued until TPM (Trust Platform Module) chips and hardware-enforced secure boot became widely adopted. Cloud security, in the 2010s and 2020s, followed a similar path. A common lesson runs through each of these domains: when the software trust boundary is compromised, the hardware layer - where data actually lives - must be secured too. The case for hardware-level security This time, we cannot afford to learn slowly. Agents are already being connected to the systems that business rely on for their daily operations. Incidents like the MCP critical vulnerability and recent reports of a data leak caused by a Meta AI agent show how quickly the risks can become real. Guardrails, permissions, and monitoring are necessary, but they are insufficient, and they represent the security layers that history shows will eventually be bypassed. Effective defense requires a third layer - one that exists beyond the software trust boundary and provides oversight at the hardware level, where sensitive data is ultimately stored and processed. Hardware Root of Trust serves as the final security barrier, helping contain breaches before they escalate into a full system compromise. As the number of companies using AI agents continues to grow, security needs to move deeper than the application layer. The industry has already learned that software alone cannot secure complex systems - it should not wait for a major compromise to learn the same lesson again. We've featured the best endpoint protection software. This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

Weak API controls are one of the biggest threats in the agentic AI era

Artificial intelligence agents are already running inside your enterprise workflows, whether you know it or not. International Data Corp. projects full agentic AI deployment across the enterprise by 2027. Gartner Inc. estimates 40% of enterprise applications will integrate task-specific agents by the end of this year, up from less than 5% in 2025. The application programming interfaces these agents depend on weren't built for them. They were designed for human-driven applications that assume the implicit judgment a developer exercises. But enterprises now manage thousands of APIs across teams, vendors and legacy systems, many of which are undocumented and ungoverned. That sprawl was already a problem; agents make it a crisis. These systems can hallucinate actions, not just text, and that can be amplified dramatically by poorly defined APIs. An agent connected to a financial system that misinterprets a request can initiate an unauthorized payment, modify records incorrectly and expose sensitive data -- all through a misused API endpoint. This isn't hypothetical. In 2024, attackers at a major financial institution sent an email with hidden instructions embedded that caused an AI assistant to approve fraudulent wire transfers totaling $2.3 million. The agent did exactly what it was designed to do. The API didn't know the difference. To make the situation worse, an agent can continue to crank away at machine speed and scale before any human intervenes. If guardrails are insufficient, the damage accumulates faster than can be detected. Build a strong foundation When managing the risks of AI agents, the best response is to focus on proven security approaches, though these are often implemented inconsistently. Here's what that looks like in practice: * Inventory: Do you know where all your APIs are? You should have an API catalog that spans the entire lifecycle, not just what's in production today. * Policy: Define clear governance for how agents and APIs should behave. What happens when actions go out of bounds? Strong policies include schema-first validation on every field, authentication, rate limiting and robust continuous integration/continuous deployment processes. * Enforcement: Policies must be actively enforced, not just documented. This means applying controls consistently across all APIs and agent interactions. * Detection: Implement monitoring functions that can identify and respond to anomalies; systems should detect when behavior deviates from normal patterns and act on it. Exercise constraint The next step is to apply best practices. First, constrain your AI agents. Map out workflows and anticipate potential adverse consequences. That process requires time and cross-functional input from people who understand the business processes involved. Constraints are not limitations on agent power; they are what makes agents reliable, effective and secure. Next, implement permission-aware data access and deterministic execution boundaries. Agents should operate with clearly defined identities, roles, and least-privilege access controls. But go further. Execution boundaries define the specific actions an agent is permitted to take, not just the data it can see. This is the difference between controlling what an agent knows and controlling what it can do. Use-intent logging is another essential practice. Collect the user prompt, the agent's reasoning steps, the proposed action, the human approval or rejection and the final outcome. This creates the audit trail needed to understand whether agents are improving or degrading over time. Document reasoning This approach aligns with critical regulatory requirements: use-intent logging maps directly to the Health Insurance Portability and Accountability Act's HIPAA 45 CFR §164.312(b) technical safeguard standard for audit controls. You must document the entire execution chain: the initial prompt, reasoning steps, intended action and the resulting human intervention. When agents execute mutating API calls autonomously at scale, this high-fidelity log stream determines whether an incident is defensible to a regulator or a total compliance failure. Data management is nonnegotiable. Agents should only see what they need for the task at hand, nothing more. Enforce ephemeral containers, encrypt at rest, in transit and in use, strip personally identifiable information before it reaches the model and hold sub-processors to zero data retention agreements where possible. If a regulator asks what data the agent touched, you should be able to answer precisely. Simplify your AI supply chain. Having too many tools, models, and integrations doesn't scale; it creates security blind spots and governance failures. The more complex the stack, the harder it is to maintain observability and control. Administrative controls round out the picture. These include kill switches, user and group-based access controls and Model Context Protocol server allow lists. Governance should also be calibrated to the deployment stage: Experimental projects need flexibility while production systems demand stricter controls, auditing and compliance frameworks. Responsible enablement The goal here is not to block agentic AI but to build the foundation that makes it worth deploying. Attackers aren't going to build novel exploits for your AI agents; they're going to find the API you forgot to inventory, the OAuth token that was scoped too broadly and the logging gap that means nobody noticed. The rise of AI agents, and their deep reliance on APIs, demands a more disciplined approach to API management. The agentic era doesn't need new security principles. It needs the proven ones implemented properly. The right guardrails don't constrain what agents can do; they're what makes them trustworthy enough to do more. Get the API governance right, and the blast radius shrinks. Get it wrong, and it expands faster than any team can manage. Chehab is head of security and IT at Postman Inc. He wrote this article for SiliconANGLE.

AI Has Turned Software Security Into a Race You Can't Afford to Lose

The solution is proving, at the speed you now generate software, that what you are about to ship does what the business asked for and will hold up against someone actively trying to break it. Sometime last September, a group working for a nation-state pointed an AI coding agent at roughly 30 companies, several of them major banks, and told it to break in. Then they mostly let it run on its own. According to Anthropic, which disclosed the operation in November, the AI did an estimated 80% to 90% of the work itself: finding the weak points, writing the exploits and pulling out the data, faster than any human team could. A number of those companies were breached, and the people running the attack spent hardly any time on it. I have spent much of this year arguing that we handed AI the job of writing our code and lost the ability to check it before it ships. That was only half of the problem. The half of the story I underplayed Here is the other half. While you are still trying to review what your own AI wrote, someone else's AI is reading it too, and it is faster than you are. For most of software's history, a flaw you shipped was like an unlocked window on the 10th floor. It was a mistake, but one you could live with, because reaching it meant a person had to find the building, spot the window and climb. That is no longer how it works. The climbing is automated now, and it runs against everyone's code at once, around the clock, for almost nothing. We are already seeing the results. In May, Google's threat intelligence team reported the first case it had caught of criminals using a zero-day exploit it believes was written by AI, built for mass use and shut down only just before it went live. John Hultquist, who runs that team, called it the tip of the iceberg. The speed numbers should change how you run engineering. CrowdStrike found that the average time for an intruder to break in and start moving through a network dropped to 29 minutes last year, and the fastest case took 27 seconds. In one break-in, data started leaving four minutes after the attacker got in. Attacks tied to AI-enabled adversaries rose 89% in a single year, and 42% of exploited vulnerabilities were used before they were even public, which means before anyone could have written a patch. As Adam Meyers, who runs counter adversary operations at CrowdStrike, put it: "This is an AI arms race." Why speed stopped being your advantage Put those two shifts together, and the way most engineering teams still work stops making sense. For a decade we chased a single number, which was how fast we could ship, and AI has now handed that number to everyone, including who or what is attacking you. Speed is no longer the advantage; it is the baseline. The code did not get safer to make up for it. Independent testing shows AI-generated code still fails security review at close to the rate it did two years ago, even as the models got better at writing code that runs. Hold that rate steady, and the arithmetic is unforgiving: far more code at the same failure rate means far more flawed code reaching production, not less. And the steady flaw rate is not even the whole problem. The code is also getting harder to maintain. Researchers who studied hundreds of millions of lines of working code found teams leaning on copy-paste far more than they used to as AI spread. The cleanup and refactoring that keeps a codebase healthy dropped off over the same years. Google's DevOps research points the same way; it found that the more a team relied on AI, the less stable its releases became. There is more code now, and it is rougher than what came before. The testing built to catch its flaws has not kept up, so more of them slip through to customers. "Ship fast, fix later" always assumed you would get to the fixing. Now you may never. The answer is not another testing tool, and it is not only the verification I have been calling for. It is a discipline: proving, at the speed you now generate software, that what you are about to ship does what the business asked for and will hold up against someone actively trying to break it. A discipline with no name does not get a budget, so I gave it one. I call it AI-Unified Release Assurance, or AURA. In practice, it is a stricter definition of "done." Done can no longer mean the build passed and the tests you had time to write went green. It has to mean you can show, continuously, that the release matches intent and is safe to put in front of customers. What to do before your next release You do not need to reorganize anything to start. You need to move three things out of the "we will get to it" pile. First, let your checks move as fast as your code does. If AI writes a large share of what you ship, the tests and reviews on that code have to be generated and updated the same way, rather than resting on a shrinking group of senior engineers who become the bottleneck. Second, connect what you learn in testing to what actually happens in production. Most teams run pre-release testing and live monitoring as separate worlds with separate owners. Attackers do not see that line, and the first sign of trouble usually shows up in production anyway. Third, keep a person's name on every decision to release. Automate the work, not the responsibility. When a breach happens, and for most companies it will, "the agent did it" is not an answer your board or a regulator will accept. Someone has to be able to say what shipped, why it was judged safe and how you would know if it was not. None of this is complicated. It is the plain work of proving your software can be trusted as fast as you now build it, and most companies are not doing it yet. The companies that come through the next few years intact will not be the ones that shipped fastest. Everyone ships fast now, attackers included. They will be the ones that could stand behind what they shipped, at the speed they shipped it. So before your next release, ask the question your board will eventually ask you: Can we prove, right now, that what we just shipped is not an attacker's way in? If the honest answer is no, that is the biggest risk in the business, and it is sitting in plain sight.

AI Is Reshaping Cybersecurity: The New Digital Battle for Businesses

Artificial Intelligence is fast transforming from a tool of productivity and automation into a game-changing element of cybersecurity while influencing the cybersecurity threat landscape. Businesses have shown increasing interest in employing AI technologies. Cybercriminals in their turn did not miss a chance to make use of this technology to conduct cyber attacks. Thus, the continuous technological development has led to a situation of arms race in cybersecurity. The statistics depict a pressing need for timely actions. According to IBM's Cost of Data Breaches report of 2026, the expenditure on breaches in India has reached ₹25.5 crore (15.9% more than the cost of ₹22 crore reported in the previous year). The average breach affects approximately 39,500 records, compared to 38,200 records in the past year. Moreover, the fact that attacks through AI accounted for 26% of all attacks in India indicates how quick criminals are to include AI in their arsenal. The good news is that AI can boost companies' defenses. According to IBM's research, only a third of firms in India utilized AI or automated their security measures. Those companies that had implemented these solutions had an average breach cost of ₹21.3 crore while the cost for other companies without such solutions was ₹31.6 crore on average, which gives a difference of ₹10.3 crore for each breach. Nonetheless, implementing AI for defence is just part of the battle. Along with AI deployment, companies need to secure them, especially because employees increasingly rely on generative AI tools in their information retrieval and work process. The uncontrolled or inappropriate use may lead to risks that enable sensitive information to be leaked outside of the organisation. The findings of the IBM study indicate that the shadow AI presence in India increased by ₹1.79 crore average from the breach costs incurred in India. According to the Global Cybersecurity Outlook 2026 by the World Economic Forum, the size of the problem becomes clear because 87% of the people polled considered AI-related vulnerabilities to be the fastest-growing cyber threat. Thus, it is crucial for businesses to progress from conventional security measures to cutting-edge AI-based proactive cyber security techniques. The application of AI involves constant monitoring of ongoing network activities, spotting of strange behaviours, and accelerating of responses to risks so as to warn the business before the incidents escalate. Nevertheless, reliance on technology is not enough to ensure an adequate level of security. Besides technology there is an essential need for effective access control strategies, employee training, careful data management, software and AI policy development. To be truly cyber resilient a business needs to take into account AI technologies as a part of its overall security approach rather than just spot different AI programs. As a result, the future of network security is likely to be determined not by how fast businesses implement AI; rather, it is how responsibly and securely they use it. Companies that combine machine learning solutions with reliable governance and security principles may find a way to utilize AI smartly. In connected environments where technology becomes a regular business practice, it is essential to reach the right equilibrium between innovation and security. (The author is Manish Mohta, Managing Director, Learning Spiral, and the views expressed in this artcile are his own)

5 Infrastructure Controls for Securing AI Agents

Join the DZone community and get the full member experience. Join For Free In July 2026, the AI Red Team at NVIDIA published findings of a six-month assessment review of enterprise AI agents, ranging from tools for interactive coding to continuously running autonomous assistants. Across every framework and harness, the pattern that emerges is consistently the same -- the agents that failed did so for four primary reasons: no access controls on the agent itself, capabilities to execute arbitrary code, no restrictions on outbound networking or segregation, and plaintext secrets available to the agent. The problem is inherently architectural in nature. Any kind of defense relying on the control plane of the model -- for example, constraining the system prompt or having the large language model serve as an adjudicator of the commands issued -- inherits the statistical nature of the underlying model. There are three primary methods to bypass these defenses: disguising malicious activities as legitimate ones (e.g., "I'm debugging" or "I'm an admin"); gradual escalation through the dialogue until enough history accumulates to establish the legitimacy of the commands; and embedding code execution in legitimate behavior (e.g., installing a package). This last one is especially worth noting. The coding agent that installs a library is expected behavior. The command pip install git+https://... pointing to a repository that is under the control of the attacker is arbitrary code execution disguised as legitimate development, and no policy-judging model can prevent this action from being performed without disabling the functionality of the agent entirely. For the companies running such agents, the prompt must not be seen as the security boundary. Here are some considerations that better fit the situation. Control 1: Identify the Agent via Authentication and Propagate the Caller's Identity The first and most common vulnerability is an agent that holds a service identity that can be accessed by any entity on the internal network. This configuration elevates a simple productivity tool into a common privilege escalation endpoint, where each user automatically receives the combined set of privileges of the agent. Two key prerequisites have been established: This token would be limited to a single audience, to the two scopes necessary for the job, and to a short expiration. In case of misuse of the agent's powers, the impact will be limited to the privileges of a single user, rather than the aggregated privileges of all users. Consider the agent to be a non-human identity with a registered owner, a scheduled rotation period, and an expiration. An agent with no owner is virtually never going to get decommissioned. Control 2: Assume Code Execution and Limit Its Effects Instead of trying to prevent code execution through careful design, make the assumption that the agent will run attacker-influenced code and arrange for the effect of that code to be benign and insignificant. It is important to note that a shell utility is not needed for achieving that goal - only write access is required. When an agent can modify configuration files like ~/.bashrc, ~/.gitconfig, a Git hook, MCP.json, or its own instruction file, then code execution happens as soon as another process reads the modified file. Configuration files, in this sense, serve as executable code, but with some extra steps in between. When creating a hardened baseline of containers, the following points should be emphasized: * A read-only root filesystem will ensure that write attempts to dotfiles fail at the OS level rather than at the model's discretion. * Use of noexec on writable mounts breaks the "read, write, execute" pattern. * Dropping all capabilities and setting no-new-privileges blocks privilege escalation mechanisms. Then, mount the agent's configuration as read-only and from a different mount point than the workspace of the agent: An agent that is able to change its own instructions can assume a completely different persona, including the "authorized debugging user" frame the red team was able to demonstrate. In cases where providing a command utility is unavoidable, use the following strategy: * Use an allowlist of binaries and wrap each invocation in a wrapper that removes shell metacharacters, resolves paths, and does not allow any action that goes beyond /workspace. * Treat any external inputs - filenames, ticket titles, and document names coming from external systems - as tainted. Control 3: Default-Deny Egress From Each Perimeter Outbound network connectivity turns the constrained execution environment primitive into an actual incident by serving as the means of exfiltration and establishing a reverse shell connection. When NVIDIA tested their system under proper egress restriction, the red team had to perform their activities through the agent process itself -- characterized by low speed, high noise, and unreliable performance. Restrict egress in places where the agent does not have direct access to the enforcement point. In case of Kubernetes environments: All network connections are restricted except those that are explicitly allowed, including blocking the cloud metadata endpoint (169.254.169.254), which provides a credential source without requiring any exploitation. Route the allowed connections through an authenticating proxy server that uses an allowlist of fully qualified domain names (FQDNs), optionally terminates TLS for analysis, and records every request with user identification data attached. This logging creates the incident timeline. Control 4: The Agent Never Holds a Persistent Secret The common practice is to inject secrets via environment variables without making any write calls to the disk, because it is commonly accepted that the only code supposed to run in the container is the expected one. This is untrue for modern times, where a large language model (LLM) runs with the shell in the same process space -- env, printenv, and /proc/self/environ are one prompt away, and CLI tools helpfully cache credentials in predictable locations: .netrc, .git-credentials, shell history, and .env files. The most interesting observation made during red teaming was the ability to extract secrets via the chat interface even when all network-based data exfiltration is prevented. The model can read environment variables and return credentials. Regardless of any network isolation, there is no way to protect data the agent is authorized to see. Thus, secrets cannot be accessible to the agent at all. Broker tokens per task instead: Recommendations: * Never inject secrets into the container image, environment, volume mounts, or context window. * Set very short time-to-live (TTL) values for secrets, measured in minutes. * Invalidate tokens after finishing the task. * Record every secret issuance along with the identification of the human user. * Once the secret is available to the agent, it is already a win for the attacker. Control 5: Package Installation Is a Supply Chain Control Use an internal proxy repository to control the agent's package manager and stop VCS and URL installations of any packages: ignore-scripts=true is the silent victory -- this will stop postinstall from being used as an execution vector. The agent must only install packages which are resolvable through the internal repository. Trust, But Verify Ship these as test cases, not as documentation: Run these on every release, and run the multi-turn variants -- the escalation that works is rarely the one in a single message. Key Takeaway Prompt-based guardrails are meant to be a usability feature that prevents accidental damage, but they do not hinder an adversarial actor who intends to cause harm. Each request needs to be validated through identity authentication (JWT validation or equivalent), confirming the caller is who they say they are -- alongside a secure sandbox environment without writable-executable paths, default-deny network egress at every boundary, and short-lived credentials issued to the agent per task. This is not new security engineering. It is the application of least privilege, isolation, and secrets management to a workload that interacts with untrusted input in real time. The mistake is assuming the model is the enforcement point, when it is in fact the thing being defended.

'Who's Guarding AI? When Automation Outpaces Governance': Ben Mudie, Tenable

AI adoption is accelerating across Indian companies, but security governance is struggling to keep pace. Ben Mudie of Tenable highlights the risks posed by overprivileged non-human identities, dormant accounts and vulnerable third-party packages, arguing that exposure management can provide continuous visibility across AI, cloud, code and identity environments. Authored by Ben Mudie, Field CTO for Asia Pacific and Japan at Tenable Artificial intelligence is being adopted rapidly by Indian companies seeking a first-mover advantage, but the pace of deployment is creating new security and governance challenges. As AI agents, machine identities, and automated systems become embedded in enterprise environments, traditional security frameworks struggle to keep pace with the risks posed by non-human identities and excessive permissions. According to the Cloud and AI Security Risk Report 2026, 52% of non-human identities, including machine identities, AI agents, and service accounts, hold critical excessive permissions, compared with 37% of human identities. Nearly half (49%) of identities with administrative-level privileges have also been inactive for 90 days but remain 'always-on' targets. Ben Mudie, Field CTO for APJ at Tenable, argues that organizations need to rethink their approach to AI security as automation accelerates. He highlights the growing exposure stemming from overprivileged machine identities, dormant administrative accounts, compromised third-party packages, and the limitations of conventional security tools for monitoring AI-driven environments. He also emphasizes how exposure management can provide continuous visibility across human and non-human identities, cloud, code, infrastructure, and AI systems without slowing down innovation.

Kaspersky GreAT Expert Warns of Growing Security Risks as AI Trust Outpaces Verification

Kaspersky's security researcher recently explained how modern AI agents have become a new supply chain layer and how cybercriminals are exploiting the gap between the chain of trust between people, AI agents, tools, and external code. With the current speed of Artificial Intelligence (AI) development known to speed up and improve enterprises' productivity, Kaspersky researcher underscored the dangers of "blind trust" and lack of verification on AI, and how cyberattackers exploit these gaps with no vulnerability but with just trust. "AI has advanced at a tremendous pace over the past few years. In its early stages, AI took the form of tools that could generate, summarise, and draft content. The next phase brought copilots, embedding AI directly into workflows to assist, suggest and guide users as they worked. Fast forward to now, we have entered the era of AI agents, which can plan, use tools, call APIs, and act autonomously. While humans remain present to verify each stage of an AI-driven development, we see more and more incidents where verification is often overlooked to maximise productivity, and when speed outpaces verification, that speed can also amplify risks," warns Sojun Ryu, security researcher at Kaspersky's GReAT (Global Research and Analysis Team). How cybercriminals exploit blind trust in AI agents Recently, Kaspersky GReAT researchers found 92,000 malicious attacks in 2026 disguised as AI services. Almost half (49%) of them were disguised as ChatGPT applications, while Claude and Gemini each represented 18%. These legitimate applications are essential for working with AI agents, and they form the starting point of the development environment. However, attackers exploit that trust by distributing fake versions specifically designed to target those users. In addition, researchers identified over 15,000 malware samples disguised as agentic AI software. They were classified as trojans, spyware, exploits, downloaderers, droppers, and backdoors - all containing actual malicious functionality. This means that simply running one of these disguised applications could allow attackers to steal internal information and establish command-and-control access. Ryu also detailed the dangers that overshadow AI use and developments: open-source packages. "The truth is that developers need open source. AI needs open source. And attackers understand this very well, which is why software supply chain attacks targeting open-source packages remain one of the most significant threats. Across multiple open-source ecosystems -- especially npm and PyPI -- major compromises spread in rapid succession. Since the middle of last year, we have seen at least ten large-scale attack campaigns, and the pace continues to rise. From attacks on highly popular packages such as Axios to self-propagating worms such as Shai-Hulud, these campaigns are beginning to shake the foundations of the open-source ecosystem," adds Ryu, The March 2026 supply chain attack involving Axios highlighted how cybercriminals are increasingly targeting trusted software components to reach a large number of victims. Axios, one of the world's most widely used JavaScript libraries, is downloaded more than 100 million times every week and is used by over 170,000 software packages. After compromising the lead maintainer's computer, the attacker gained access to the project's npm account and published malicious versions of the library. Although the compromised packages were available for only about three hours, they were downloaded by hundreds of devices during that time. The incident demonstrates how a single compromise in a trusted open-source project can quickly spread across the software supply chain, reinforcing the importance of verifying software components and monitoring for suspicious changes. "According to our survey last year, 31% of enterprise businesses had been impacted by a supply chain attack. This reflects how deeply open-source software is embedded in enterprise development environments. We should expect open-source ecosystems to remain a major target for attackers because it's their door to crack into the intelligence inside the enterprises," he adds. How to reduce blind trust without sacrificing productivity With productivity driving not only operational efficiency but also companies' profitability, Ryu listed practical ways on how to keep enterprise productivity without sacrificing security. He underscored the need to define clear trusted development zones between external content and internal development assets. That should harden not only the IDE (Integrated Development Environment), but also extensions, workspaces, and agent permissions. He also highlighted the need to control the paths through which software enters the environment and maintain visibility into every activity. The objective from which is not to add more approval prompts, but rather, to make the secure path the easiest and most efficient path. Kaspersky, for its part, is also contributing to building a secure development environment and workflow for developers and IT security professionals alike. In particular, Kaspersky GreAT monitors all the open-source software mentioned earlier and provides a feed that flags any vulnerable or malicious components. Kaspersky's elite team of researchers also audited GitHub Actions workflows using Kaspersky Container Security capability to ensure a secure build path and discovered that over 250,000 potential misconfigurations in continuous‑integration/continuous‑delivery (CI/CD) processes, underscoring the widespread adoption of insecure configuration practices. "As a security researcher, I strongly believe that we should shift security not only toward earlier stages of software development, but also from protecting deployed systems to securing the environments where software is created. Because when trust is verified before execution, organisations move faster, not slower. Most importantly, security fails when we prioritise speed, money, and delivery over protection and visibility," he adds.