Key Takeaways
- Palo Alto Networks Unit 42 exposed a “double agent” flaw in Google Cloud’s Vertex AI, showing how overprivileged AI agents can compromise cloud environments by exploiting default permission scoping.
- Enterprises should implement least-privilege principles — including Google’s “Bring Your Own Service Account (BYOSA)” recommendation — to prevent AI agents from escalating privileges and exfiltrating data.
- Securing agentic AI deployments in GCP requires layering granular native IAM controls and just-in-time access with AI Security Posture Management (AI-SPM) tools for continuous monitoring and threat detection. An AI agent you deployed to automate cloud workflows can be turned against you — and Palo Alto Networks Unit 42 just proved it. Their recent research exposed a “double agent” vulnerability in Google Cloud’s Vertex AI, where overprivileged agents can be weaponised to exfiltrate data and escalate permissions across your entire cloud environment. Google has since updated its documentation and introduced new security guidance, but the responsibility to lock things down sits squarely with builders and security teams.
The Rise of ‘Double Agents’ in Vertex AI
Unit 42’s findings landed alongside a cluster of security announcements from Google. At the RSAC conference in March 2026, Google highlighted its completion of the Wiz acquisition — a move aimed at building a more comprehensive, AI-ready security platform. Around the same time, updated Google Cloud documentation drew attention to Privileged Access Manager (PAM) for just-in-time privilege elevation, specifically for the service accounts that AI agents typically run under. The timing wasn’t coincidental. The threat is real, and the ecosystem is scrambling to catch up.
Understanding the Threat: Overprivileged AI Agents
Vertex AI agents are built to operate autonomously — calling services, making decisions, executing tasks. That autonomy is the point. It’s also the problem. When an agent is misconfigured with excessive permissions, or when an attacker finds a foothold, that same autonomy becomes an attack vector.
Unit 42’s research showed that a compromised agent running in Vertex AI’s Agent Engine could gain privileged access to data in a consumer project — including unrestricted read access to Google Cloud Storage buckets. One compromised service agent, and the blast radius extends across your data layer. The research also flagged misconfigured Artifact Registry deployments that exposed restricted internal images, potentially allowing attackers to map internal software supply chains.
Google’s response was to revise its official documentation to clarify how Vertex AI uses resources, accounts, and agents. The key recommendation: “Bring Your Own Service Account” (BYOSA) — replacing default service agents with custom, tightly scoped accounts that follow least-privilege principles from the start.
Comparison Criteria for Securing AI Agents
Before choosing a security approach, enterprises need a clear framework for evaluation. Here’s what actually matters when locking down AI agents in GCP:
- Granular Access Control: Can you define and enforce specific permissions per agent, scoped only to what each one genuinely needs?
- Threat Detection & Monitoring: Does the solution continuously monitor agent behaviour for anomalies — prompt injection, unexpected data access, lateral movement?
- Automated Remediation: Can it revoke access or isolate a compromised agent automatically, without waiting for a human to act?
- Compliance & Governance: Does it support audit trails and alignment with frameworks like NIST and OWASP, and help you evidence compliance?
- Integration & Scalability: How cleanly does it plug into existing GCP services and security infrastructure as your AI workloads grow?
- Operational Overhead & Cost: What’s the real cost — in engineering time and tooling spend — to implement and maintain it?
Criterion
GCP Native IAM & Security Controls
Enhanced AI Security Posture Management (AI-SPM)
Granular Access Control
Strong, via custom service accounts (BYOSA) and fine-grained IAM roles. Just-in-Time (JIT) access with PAM.
Augments native controls with AI-driven recommendations and continuous entitlement monitoring for least privilege.
Threat Detection & Monitoring
Audit logging, Security Command Center (SCC) with AI Protection, Model Armor for runtime risks.
AI-powered classification, real-time behavioural anomaly detection, sensitive data leakage prevention.
Automated Remediation
Automated policy enforcement, integration with SOAR tools via SCC.
Automated response workflows, real-time security incident remediation.
Compliance & Governance
Built-in baselines and AI-specific controls in SCC Compliance Manager. Alignment with NIST/OWASP.
Continuous compliance enforcement with NIST/OWASP standards, comprehensive audit visibility.
Integration & Scalability
Deeply integrated with Vertex AI and other GCP services; scales with GCP infrastructure.
Designed for multi-cloud; typically integrates with existing CSPM/CNAPP and GCP services.
Operational Overhead & Cost
Requires in-house expertise for configuration; costs embedded in GCP usage.
Introduces additional vendor costs and integration complexity, but reduces manual security effort.
GCP Native IAM and Security Controls
Google Cloud’s native IAM controls are the right place to start — but only if you actually use them properly. The default configuration, as Unit 42’s research made clear, is not safe enough for production agentic workloads.
BYOSA is the most important immediate change. Provisioning custom service accounts with narrow, explicitly defined permissions — rather than relying on default service agents — directly cuts the blast radius of any compromise. You’re granting specific IAM roles scoped to exactly what Vertex AI needs for training or inference, nothing more.
Beyond IAM, GCP offers several more layers worth deploying. VPC Service Controls create security perimeters around sensitive data, isolating ML projects from the public internet. Cloud Data Loss Prevention (DLP) can scan training data for PII before it enters the model pipeline. Security Command Center (SCC) provides centralised posture management with AI Protection features — detecting threats targeting agents and defending against prompt injection and data leakage via Model Armor. Privileged Access Manager adds just-in-time, temporary privilege elevation for service accounts, reducing the window of exposure when elevated access is genuinely needed.
For generative AI workloads specifically, Google Cloud’s security documentation maps controls to NIST 800-53, covering foundational workload security alongside Vertex AI-specific guidance for services including Artifact Registry, BigQuery, and related tooling. If you’re building on GCP, this is required reading before you ship anything to production.
Enhanced AI Security Posture Management (AI-SPM) & Runtime Protection
Native controls give you the foundation. AI-SPM tools give you the visibility and speed to catch what slips through — and with agentic systems, things will slip through.
Google is building its own answer here. The “agentic security operations centre” strategy, powered by Gemini models, introduces Triage and Investigation agents that autonomously analyse alerts, gather evidence, and feed into real-time remediation workflows. That’s a meaningful shift from static playbooks — though it remains to be seen how it performs against novel attack patterns in practice.
Third-party AI-SPM platforms — including Cortex AI-SPM, cited in the Unit 42 report — are designed specifically for this problem space. They deliver continuous visibility into agent permissions and behaviour, enforce compliance with NIST and OWASP, detect real-time anomalies, and sit within a broader cloud security context rather than operating as a bolt-on. For teams running complex multi-agent orchestration, that unified view matters.
Google’s Wiz acquisition adds another dimension. Wiz’s agentless approach to identifying cloud risks is planned for integration into Google’s broader platform, targeting a multicloud security solution that spans infrastructure, AI workloads, and the CI/CD pipeline. The stated goal is faster detection and response, with enhanced AI Protection and Model Armor capabilities folded into Security Command Center over time.
In practice, these tools deliver what native IAM can’t easily do at scale: continuous entitlement monitoring, accurate misconfiguration detection, and real-time analysis of access patterns across a large fleet of agents. They also integrate with Cloud-Native Application Protection Platforms (CNAPPs) for a proactive stance throughout the deployment lifecycle.
Comparison Summary: Balancing Control and Innovation
This isn’t a choice between native controls and AI-SPM — it’s a question of how to layer them. Native GCP controls (BYOSA, granular IAM, VPC Service Controls, PAM) form the non-negotiable baseline. They’re deeply integrated, well-documented, and essential for compliance. But managing them at scale, across fast-moving AI deployments, requires significant in-house expertise. Miss a permission boundary during a rapid iteration cycle and you’ve recreated the exact conditions Unit 42 exploited.
AI-SPM tools fill that gap with automation, specialised detection, and continuous posture management tailored to agent behaviour. They catch the novel attack vectors — prompt injection, agent impersonation, cross-service privilege creep — that traditional security tooling wasn’t built to handle. The trade-off is vendor cost and integration complexity, particularly in hybrid or multi-cloud environments.
One point worth taking seriously from Google Cloud’s cybersecurity research: many successful intrusions still trace back to foundational failures — neglected governance, poor hygiene, misconfigured defaults. Advanced tooling amplifies a solid foundation. It doesn’t substitute for one. If you’re thinking about controlling agent deployment costs while scaling security, that trade-off between native controls and third-party tooling is worth modelling carefully.
Recommendations for Enterprise Security Leaders
Here’s what to act on now:
- Implement BYOSA immediately: Apply “Bring Your Own Service Account” to all Vertex AI Agent Engine deployments. Custom service accounts with minimal, explicit permissions are the single most effective mitigation against privilege escalation. This is not optional for production workloads.
- Maximise native GCP controls: Deploy VPC Service Controls for network isolation, Cloud DLP for sensitive data scanning, and robust audit logging across all AI-related activity. Use Privileged Access Manager for just-in-time access to critical resources, with automated approvals where your risk tolerance allows.
- Add AI-specific threat detection: Enable AI Protection in Security Command Center and deploy Model Armor to catch runtime risks — prompt injection, data leakage, tool manipulation. Evaluate whether Google’s new agentic SOC capabilities fit your detection and response workflow.
- Deploy dedicated AI-SPM: Evaluate AI Security Posture Management platforms — through Google’s expanded tooling via Wiz, or third-party options. You need continuous visibility, compliance enforcement, and behavioural anomaly detection across the full agent lifecycle, not just at deployment time.
- Treat agent deployments like production code: Validate permission boundaries, review source integrity, restrict OAuth scopes, and run red team exercises before rollout. Build these steps into your deployment pipeline — not as a post-launch audit, but as a gate.
The “double agent” vulnerability in Vertex AI is a clear signal: as AI agents take on more autonomy and deeper access to business-critical systems, security can’t be an afterthought. The combination of tight native GCP controls and purpose-built AI-SPM tooling is the architecture that holds. Build on both, iterate fast, and assume your agents will be tested by someone other than your own team. For more on AI agents and automation tools, visit our AI Agents section.
Originally published at https://autonainews.com/unmasking-vertex-ai-double-agents/
Top comments (0)