AI Agents Create New Enterprise Security Risks as Traditional Defenses Fall Short

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.

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.