The future of technology is unfolding across EMEA, and Google Cloud is at the forefront of this transformation. We’re organizing a series of exciting events across the region, offering a unique opportunity for developers and tech enthusiasts to dive deep into the world of artificial intelligence, agents, and cloud computing. Whether you’re looking to use AI to make your applications smarter, get hands-on experience with cutting-edge developer tools, or network with industry experts, there’s an event for you nearby.

The Rise of the AI Agent

A major focus of these events is the “agentic era” of AI, where intelligent agents are set to empower developers and builders to automate tasks and be more efficient with their daily work. This event series is making stops in several EMEA cities, offering immersive experiences with hands-on labs. These events are designed to provide step-by-step guidance for building and scaling AI agents within your organization.

Developers will find plenty of opportunities to get hands-on experience with the latest Google Cloud technologies. The labs are specifically crafted for developers and technical practitioners, offering workshops that delve into cutting-edge technologies from Google and Google Cloud with sessions on Cloud Run, Vertex AI, Gemini, ADK, and much more.

Innovate with us!

This is more than just a series of events; it’s an invitation to be part of a movement that is shaping the future of technology and business. Don’t miss this opportunity to learn from Google, connect with your peers, and get hands-on with the tools that will define the next wave of innovation.

Ready to join the AI revolution? Explore the full list of events and register today to secure your spot. The future is being built now, and you can be a part of it. Visit the official Google Cloud events page to find an event near you and start your journey into the new era of AI and cloud. This is your chance to learn, connect, and innovate with Google Cloud.

Register now!

Distributed ledger technology (DLT) emerged with Bitcoin as a censorship-resistant way to conduct payments between distrusting peers. After a period, traditional financial institutions began to explore the technology, recognizing the potential of its immutability, decentralization, and programmability to redesign financial instruments and workflows.

However, a foundational issue has stalled many enterprise blockchain projects at the pilot stage: the data integrity problem. Moving from controlled test environments to production systems introduces attack vectors and failure modes that don’t exist in traditional centralized systems – a challenge that is particularly pressing for institutions like DZ BANK that are pioneering enterprise DLT adoption.

To solve these challenges, DZ BANK and Google Cloud built an architectural solution for trustworthy data delivery to blockchain applications. This post describes how market data can be securely fed into DZ BANK’s Smart Derivative Contracts (SDCs) using Google Cloud technology.

2025 is the year of strategic engagement

Distributed ledger technology (DLT) has reached a maturity inflection point. Regulatory frameworks are stabilizing, scalability limitations are being addressed, and the Eurosystem’s validation work demonstrates that smart contract protocols enable efficient settlement across separate DLT infrastructures. The exploratory phase is ending — institutions that haven’t moved beyond pilot projects risk being left behind as competitors deploy production blockchain systems.

The technology’s core value proposition — immutable, programmable, decentralized execution — enables new digital financial products that weren’t previously feasible. Smart contracts can eliminate counterparty risk, automate complex settlement procedures, and enable peer-to-peer financial interactions without traditional intermediaries. But realizing these benefits requires solving a fundamental challenge that early blockchain systems were designed to avoid.

Eurosystem research shows that smart contract protocols enable efficient settlement for financial instruments and functional interoperability across separate DLT infrastructures. Based on these results, the Eurosystem recently announced plans to strengthen activities in this field, aiming to create a harmonized digital European financial market infrastructure.

The need for trustworthy data

While DLT was conceptualized as a technology where code is law, banks, asset managers, and clearinghouses require off-ledger data from external sources. This includes price feeds, interest rate feeds, KYC/AML attestations, legal event triggers, proofs of reserves, IoT sensor data, and payment confirmations.

Data trustworthiness is paramount in DLT systems. Wrong data can have unintended consequences in any system, but DLT transactions are often irreversible. A payment using an incorrect interest rate can be cancelled in traditional systems, while DLT transactions are typically final – especially when participants are pseudonymous and unreachable by legal interventions. This creates new attack vectors: attackers who manipulate off-ledger data can cause significant financial harm, including theft of on-chain assets.

Building trustworthy oracle architecture

Off-chain data is supplied to DLT systems via oracles –-  interfaces that deliver external information to smart contracts. Trustworthy oracle services require addressing three key aspects:

1. Data must be correct at the source – underlying systems must produce accurate information.

2. Data must remain untampered during transit and processing.

3. Data must be delivered timely and reliably.

The combination of Google Cloud’s secure, highly available infrastructure with DZ BANK’s vision for standardized, deterministic financial protocols meets these requirements. Google’s global technical infrastructure provides security throughout the entire information processing lifecycle, ensuring data integrity and reliability at source and in transit. DZ BANK’s focus on technology-agnostic, deterministic patterns for financial instruments enables trustworthy, automatable financial innovations. Together this approach provides the foundation for delivering timely, untampered data to any DLT system and establishes scalable protocol standards for secure digital financial services.

This architectural pattern provides a blueprint for other institutions facing similar challenges, creating reusable components for trustworthy data delivery across different financial smart contracts and blockchain networks.

The Smart Derivative Contract: a DLT-based financial instrument relying on trustworthy data

The Smart Derivative Contract (SDC) use case covers a fully algorithmic financial product lifecycle that relies heavily on external data, serving as an archetype for oracle-based financial data feeds produced on Google Cloud and consumed by smart contracts. The deterministic settlement cycle requires robust oracle services to determine settlement values. Key functionalities include deterministic valuation, automated margining, netting, and trade termination handling to remove counterparty credit risk in OTC transactions. These processes depend on reliable real-time market data from oracles to determine net present value (NPV) and settlement amounts.

The underlying protocol is published as Ethereum Request for Comments (ERC) 6123. Based on this open protocol, DZ BANK has conducted several pilot transactions with binding legal effect and successfully validated the use case on Bundesbank’s DLT infrastructure (the Trigger Solution).

Why are derivatives the hardest test case? They require precise mathematical calculations using current market data to determine NPV for settlement. Interest rate swaps, for example, need current swap quotes to bootstrap discount and forward rate curves before calculating settlement amounts. The entire process must be deterministic and tamper-proof, with cryptographic evidence of data integrity throughout the pipeline. A secure oracle service is essential for the SDC lifecycle and automated settlement.

Mitigating software supply chain issues

For SDCs, an attacker might tamper with code that determines NPV calculations – for example,  modifying functionality to return artificially low values by default. This would cause settlement at incorrect amounts. To mitigate these issues, we follow Secure Software Supply Chain practices, leveraging Binary Authorization to enforce policies that only permit container images with valid attestation to be deployed. This attestation certifies that container images have passed required checks, such as build verification by trusted CI pipelines, generating build provenance. For maximum security, SLSA Level 3 assurance is desired. By verifying this attestation at deploy time, Binary Authorization blocks unauthorized or tampered images, preventing the malicious code from running.

Secure connections to data sources

Oracle functions calculating NPV need to access relevant market data, which could reside in cloud databases like Cloud SQL. The workload can connect via Private Service Connect, enabling access to the Cloud SQL instance using a private internal IP address within its own VPC network. This keeps all traffic within the Google Cloud network, allowing secure data access without traversing the public internet.

TEE attestation

Ensuring oracle data correctness requires proving that data was generated by specific untampered software versions. For SDCs, this applies to software responsible for value calculations. Using Confidential Space, a trusted execution environment, ensures that only authorized, unmodified software workloads can process data. 

This is achieved through remote attestation, where data owners set access conditions based on verification of authorized workload attributes, including the specific digest of containerized software images. Code identity verification complements the inherent trust participants place in the oracle’s business logic. A verifiable attestation token provides strong assurance and can be packaged with the oracle data output to prove origin and correctness.

Transport Layer Security

Transport Layer Security (TLS) adds an additional layer by encrypting oracle data output during transmission to the blockchain. While TEE attestation proves data was generated by authorized, unmodified software within a secure environment, TLS protects data from interception or tampering during network transit.

Applications beyond derivatives

The architectural patterns developed for SDCs apply to other enterprise blockchain use cases that require trustworthy external data. Cross-chain asset transfers, for example, need reliable payment confirmation data to avoid double-spending attacks. Supply chain applications need verified sensor readings and logistics confirmations.

Secure cross-chain protocols are essential for financial interoperability, especially for settling asset and cash legs across separate networks. However, current protocols like HTLC rely on time-outs, creating security vulnerabilities. A more secure approach, proposed in ERC-7573, uses a stateless oracle that releases cryptographic keys contingent on payment success to either complete asset swaps or return funds. By decrypting keys as instructed by a smart contract, the oracle enhances both security and efficiency – an example of how: trustworthy off-chain oracles enable smart contracts.

Building production-ready blockchain infrastructure

The collaboration between DZ BANK and Google Cloud demonstrates that enterprise blockchain adoption is no longer limited by technology. Success depends on integrating decentralized applications with existing business systems while maintaining security and reliability standards.

For developers and architects working on enterprise blockchain projects, this collaboration provides both technical patterns to emulate and infrastructure components to leverage. The challenge isn’t building blockchain applications — it’s building blockchain applications that enterprises can trust with critical business processes.

Ready to explore how these architectural approaches can support your blockchain infrastructure requirements? The frameworks and patterns developed through this collaboration offer practical starting points for building trustworthy oracle systems that meet enterprise security and reliability standards.

The team would also like to thank Christian Fries at DZ BANK and Googlers Chris Diya, Yuriy Babenko, and Latif Ajouaoui for their contributions.

Written by: Omar ElAhdan, Matthew McWhirt, Michael Rudden, Aswad Robinson, Bhavesh Dhake,
                    Laith Al

Background

Protecting software-as-a-service (SaaS) platforms and applications requires a comprehensive security strategy. Drawing from analysis of UNC6040’s specific attack methodologies, this guide presents a structured defensive framework encompassing proactive hardening measures, comprehensive logging protocols, and advanced detection capabilities. While emphasizing Salesforce-specific security recommendations, these strategies provide organizations with actionable approaches to safeguard their SaaS ecosystem against current threats.

Google Threat Intelligence Group (GTIG) is tracking UNC6040, a financially motivated threat cluster that specializes in voice phishing (vishing) campaigns specifically designed to compromise organizations’ Salesforce instances for large-scale data theft and subsequent extortion. Over the past several months, UNC6040 has demonstrated repeated success in breaching networks by having its operators impersonate IT support personnel in convincing telephone-based social engineering engagements. This approach has proven particularly effective in tricking employees, often within English-speaking branches of multinational corporations, into actions that grant the attackers access or lead to the sharing of sensitive credentials, ultimately facilitating the theft of organization’s Salesforce data. In all observed cases, attackers relied on manipulating end users, not exploiting any vulnerability inherent to Salesforce.

A prevalent tactic in UNC6040’s operations involves deceiving victims into authorizing a malicious connected app to their organization’s Salesforce portal. This application is often a modified version of Salesforce’s Data Loader, not authorized by Salesforce. During a vishing call, the actor guides the victim to visit Salesforce’s connected app setup page to approve a version of the Data Loader app with a name or branding that differs from the legitimate version. This step inadvertently grants UNC6040 significant capabilities to access, query, and exfiltrate sensitive information directly from the compromised Salesforce customer environments. This methodology of abusing Data Loader functionalities via malicious connected apps is consistent with recent observations detailed by Salesforce in their guidance on protecting Salesforce environments from such threats.

In some instances, extortion activities haven’t been observed until several months after the initial UNC6040 intrusion activity, which could suggest that UNC6040 has partnered with a second threat actor that monetizes access to the stolen data. During these extortion attempts, the actor has claimed affiliation with the well-known hacking group ShinyHunters, likely as a method to increase pressure on their victims.

We have observed the following patterns in UNC6040 victimology:

• Motive: UNC6040 is a financially motivated threat cluster that accesses victim networks by vishing social engineering.

• Focus: Upon obtaining access, UNC6040 has been observed immediately exfiltrating data from the victim’s Salesforce environment using Salesforce’s Data Loader application. Following this initial data theft, UNC6040 was observed leveraging end-user credentials obtained through credential harvesting or vishing to move laterally through victim networks, accessing and exfiltrating data from the victim’s accounts on other cloud platforms such as Okta and Microsoft 365.

• Attacker infrastructure: UNC6040 primarily used Mullvad VPN IP addresses to access and perform the data exfiltration on the victim’s Salesforce environments and other services of the victim’s network.

Proactive Hardening Recommendations

The following section provides prioritized recommendations to protect against tactics utilized by UNC6040. This section is broken down to the following categories: 

1. Identity
   • Help Desk and End User Verification 
   • Identity Validation and Protections 
2. SaaS Applications
   • SaaS Application (e.g., Salesforce) Hardening Measures 
3. Logging and Detections

Note: While the following recommendations include strategies to protect SaaS applications, they also cover identity security controls and detections applicable at the Identity Provider (IdP) layer and security enhancements for existing processes, such as the help desk.

1. Identity

Positive Identity Verification

To protect against increasingly sophisticated social engineering and credential compromise attacks, organizations must adopt a robust, multilayered process for identity verification. This process moves beyond outdated, easily compromised methods and establishes a higher standard of assurance for all support requests, especially those involving account modifications (e.g., password resets or multi-factor authentication modifications).

Guiding Principles

• Assume nothing: Do not inherently trust the caller’s stated identity. Verification is mandatory for all security-related requests.
• Defense-in-depth: Rely on a combination of verification methods. No single factor should be sufficient for high-risk actions.
• Reject unsafe identifiers: Avoid relying on publicly available or easily discoverable data. Information such as:

  • Date of birth

  • Last four digits of a Social Security number

  • High school names

  • Supervisor names

This data should not be used as primary verification factors, as it’s often compromised through data breaches or obtainable via open source intelligence (OSINT).

Standard Verification Procedures

Live Video Identity Proofing (Primary Method)

This is the most reliable method for identifying callers. The help desk agent must:

1. Initiate a video call with the user

2. Require the user to present a valid corporate badge or government-issued photo ID (e.g., driver’s license) on camera next to their face

3. Visually confirm that the person on the video call matches the photograph on the ID

4. Cross-reference the user’s face with their photo in the internal corporate identity system

5. Verify that the name on the ID matches the name in the employee’s corporate record
   
   Contingency for No Video: If a live video call is not possible, the user must provide a selfie showing their face, their photo ID, and a piece of paper with the current date and time written on it.

   Additionally, before proceeding with any request – help desk personnel must check the user’s calendar for Out of Office (OOO) or vacation status. All requests from users who are marked as OOO should be presumptively denied until they have officially returned.

Out-of-Band (OOB) Verification (For High-Risk Requests)

For high-risk changes like multi-factor authentication (MFA) resets or password changes for privileged accounts, an additional OOB verification step is required after the initial ID proofing. This can include:

• Call-back: Placing a call to the user’s registered phone number on file

• Manager approval: Sending a request for confirmation to the user’s direct manager via a verified corporate communication channel

Special Handling for Third-Party Vendor Requests

Mandiant has observed incidents where attackers impersonate support personnel from third-party vendors to gain access. In these situations, the standard verification principals may not be applicable.

Under no circumstances should the Help Desk move forward with allowing access. The agent must halt the request and follow this procedure:

1. End the inbound call without providing any access or information

2. Independently contact the company’s designated account manager for that vendor using trusted, on-file contact information

3. Require explicit verification from the account manager before proceeding with any request

Outreach to End Users 

Mandiant has observed the threat actor UNC6040 targeting end-users who have elevated access to SaaS applications. Posing as vendors or support personnel, UNC6040 contacts these users and provides a malicious link. Once the user clicks the link and authenticates, the attacker gains access to the application to exfiltrate data.

To mitigate this threat, organizations should rigorously communicate to all end-users the importance of verifying any third-party requests. Verification procedures should include:

• Hanging up and calling the official account manager using a phone number on file

• Requiring the requester to submit a ticket through the official company support portal

• Asking for a valid ticket number that can be confirmed in the support console

Organizations should also provide a clear and accessible process for end-users to report suspicious communications and ensure this reporting mechanism is included in all security awareness outreach.

Salesforce has additional guidance that can be referenced.

Identity Protections 

Since access to SaaS applications is typically managed by central identity providers (e.g., Entra ID, Okta), Mandiant recommends that organizations enforce unified identity security controls directly within these platforms. 

Guiding Principles

Mandiant’s approach focuses on the following core principles:

• Authentication boundary This principle establishes a foundational layer of trust based on network context. Access to sensitive resources should be confined within a defined boundary, primarily allowing connections from trusted corporate networks and VPNs to create a clear distinction between trusted and untrusted locations.

• Defense-in-depth This principle dictates that security cannot rely on a single control. Organizations should layer multiple security measures,such as strong authentication, device compliance checks, and session controls.

• Identity detection and response  Organizations must continuously integrate real-time threat intelligence into access decisions. This ensures that if an identity is compromised or exhibits risky behavior, its access is automatically contained or blocked until the threat has been remediated.

Identity Security Controls 

The following controls are essential for securing access to SaaS applications through a central identity provider.

Utilize Single Sign-On (SSO)

Ensure that all users accessing SaaS applications are accessing via a corporate-managed SSO provider (e.g., Microsoft Entra ID or Okta), rather than through platform-native accounts. A platform-native break glass account should be created and vaulted for use only in the case of an emergency.

In the event that SSO through a corporate-managed provider is not available, refer to the content specific to the applicable SaaS application (e.g., Salesforce) rather than Microsoft Entra ID or Okta.

Mandate Phishing-Resistant MFA

Phishing-resistant MFA must be enforced for all users accessing SaaS applications. This is a foundational requirement to defend against credential theft and account takeovers. Consider enforcing physical FIDO2 keys for accounts with privileged access. Ensure that no MFA bypasses exist in authentication policies tied to business critical applications.

For Microsoft Entra ID:

• General MFA Policy: Enforce MFA for all users with Conditional Access

• Passkey (FIDO2) Setup: Enable passkey and FIDO2 security keys

For Okta:

• Configure FIDO2 (WebAuthn): Set up the FIDO2 (WebAuthn) authenticator

• Enforce via Policy: Create an Authentication Policy to require strong authenticators

For Google Cloud Identity / Workspace:

• General MFA Policy: Deploy 2-Step Verification

• Security Key enforcement: Use a security key for 2-Step Verification

For Salesforce:

• MFA is required by default for local Salesforce accounts: Salesforce Multi-Factor Authentication FAQ

• Configure FIDO2 (WebAuthn): Register a Security Key as an Identity Verification Method for Salesforce Orgs

Enforce Device Trust and Compliance

Access to corporate applications must be limited to devices that are either domain-joined or verified as compliant with the organization’s security standards. This policy ensures that a device meets a minimum security baseline before it can access sensitive data.

Key device posture checks should include:

• Valid host certificate: The device must present a valid, company-issued certificate
• Approved operating system: The endpoint must run an approved OS that meets current version and patch requirements
• Active EDR agent: The corporate Endpoint Detection and Response (EDR) solution must be installed, active, and reporting a healthy status

For Microsoft Entra ID:

• Device Compliance Policy: Require compliant devices for all users with Conditional Access

For Okta:

• Device Trust Overview: Configure Okta Device Trust for managed devices

For Google Cloud Identity / Workspace:

• Context-Aware Access: Overview of Context-Aware Access
• Endpoint Verification: Monitor and gather details about devices with Endpoint Verification

Automate Response to Identity Threats

Mandiant recommends that organizations implement dynamic authentication policies that respond to threats in real time. By integrating identity threat intelligence feeds—from both native platform services and third-party solutions—into the authentication process, organizations can automatically block or challenge access when an identity is compromised or exhibits risky behavior.

This approach primarily evaluates two categories of risk:

• Risky sign-ins: The probability that an authentication request is illegitimate due to factors like atypical travel, a malware-linked IP address, or password spray activity
• Risky users: The probability that a user’s credential has been compromised or leaked online

Based on the detected risk level, Mandiant recommends that organizations apply a tiered approach to remediation.

Recommended Risk-Based Actions

• For high-risk events: Organizations should apply the most stringent security controls. This includes blocking access entirely.
• For medium-risk events: Access should be granted only after a significant step-up in verification. This typically means requiring proof of both the user’s identity (via strong MFA) and the device’s integrity (by verifying its compliance and security posture).
• For low-risk events: Organizations should still require a step-up authentication challenge, such as standard MFA, to ensure the legitimacy of the session and mitigate low-fidelity threats.

For Microsoft Entra ID:

• Overview
• Configuration

For Okta:

• Behavior detection
• Risk-based policies

For Google Cloud Identity / Workspace:

• Access context manager overview: Use Context-Aware Access to create granular, risk-based access policies

For Salesforce Shield: 

• Overview
• Event monitoring: Provides detailed logs of user actions—such as data access, record modifications, and login origins—and allows these logs to be exported for external analysis
• Transaction security policies: Monitors for specific user activities, such as large data downloads, and can be configured to automatically trigger alerts or block the action when it occurs

2. SaaS Applications 

Salesforce Targeted Hardening Controls 

This section details specific security controls applicable for Salesforce instances. These controls are designed to protect against broad access, data exfiltration, and unauthorized access to sensitive data within Salesforce.

Network and Login Controls

Restrict logins to only originate from trusted network locations.

See Salesforce guidance on network access and profile-based IP restrictions. 

Restrict Login by IP Address

This control prevents credential misuse from unauthorized networks, effectively blocking access even if an attacker has stolen valid user credentials.

• Define login IP ranges at the profile level to only permit access from corporate and trusted network addresses.

• In Session Settings, enable “Enforce login IP ranges on every request” to ensure the check is not bypassed by an existing session.

See Salesforce guidance on setting trusted IP ranges.

Application and API Access Governance

Govern Connected App and API Access

Threat actors often bypass interactive login controls by leveraging generic API clients and stolen OAuth tokens. This policy flips the model from “allow by default” to “deny by default,” to ensure that only vetted applications can connect.

• Enable a “Deny by Default” API policy: Navigate to API Access Control and enable “For admin-approved users, limit API access to only allowed connected apps.” This blocks all unapproved clients.

• Maintain a minimal application allowlist: Explicitly approve only essential Connected Apps. Regularly review this allowlist to remove unused or unapproved applications.

• Enforce strict OAuth policies per app: For each approved app, configure granular security policies, including restricting access to trusted IP ranges, enforcing MFA, and setting appropriate session and refresh token timeouts.

• Revoke sessions when removing apps: When revoking an app’s access, ensure all active OAuth tokens and sessions associated with it are also revoked to prevent lingering access.

• Organizational process and policy: Create policies governing application integrations with third parties. Perform Third-Party Risk Management reviews of all integrations with business-critical applications (e.g., Salesforce, Google Workspace, Workday).

See Salesforce guidance on managing API access.

User Privilege and Access Management

Implement the Principle of Least Privilege

Users should only be granted the absolute minimum permissions required to perform their job functions.

• Use a “Minimum Access” profile as a baseline: Configure a base profile with minimal permissions and assign it to all new users by default. Limit the assignment of  “View All” and “Modify All” permissions. 

• Grant privileges via Permission Sets: Grant all additional access through well-defined Permission Sets based on job roles, rather than creating numerous custom profiles. 

• Disable API access for non-essential users: The “API Enabled” permission is required for tools like Data Loader. Remove this permission from all user profiles and grant it only via a controlled Permission Set to a small number of justified users.

• Hide the ‘Setup’ menu from non-admin users: For all non-administrator profiles, remove access to the administrative “Setup” menu to prevent unauthorized configuration changes.

• Enforce high-assurance sessions for sensitive actions: Configure session settings to require a high-assurance session for sensitive operations such as exporting reports.

See Salesforce guidance on modifying session security settings.

See Salesforce guidance on requiring high-assurance session security.

See Salesforce guidance on “View All” and “Modify All” permissions.  

Granular Data Access Policies

Enforce “Private” Organization-Wide Sharing Defaults (OWD)

• Set the internal and external Organization-Wide Defaults (OWD) to “Private” for all sensitive objects.

• Use strategic Sharing Rules or other sharing mechanisms to grant wider data access, rather than relying on broad access via the Role Hierarchy.

Leverage Restriction Rules for Row-Level Security

Restriction Rules act as a filter that is applied on top of all other sharing settings, allowing for fine-grained control over which records a user can see.

See Salesforce guidance on restriction rules.

Revoke Salesforce Support Login Access

Ensure that any users with access to sensitive data or with privileged access to the underlying Salesforce instance are setting strict timeouts on any Salesforce support access grants.

Revoke any standing requests and only re-enable with strict time limits for specific use cases. Be wary of enabling these grants from administrative accounts.

See Salesforce guidance on granting Salesforce Support login access. 

Mandiant recommends running the Salesforce Security Health Check tool to identify and address misconfigurations. For additional hardening recommendations, reference the Salesforce Security Guide.

3. Logging and Detections

Salesforce Targeted Logging and Detections Controls 

This section outlines key logging and detection strategies for Salesforce instances. These controls are essential for identifying and responding to advanced threats within the SaaS environment.

SaaS Applications Logging 

To gain visibility into the tactics, techniques, and procedures (TTPs) used by threat actors against SaaS Applications, Mandiant recommends enabling critical log types in the organization’s Salesforce environment and ingesting the logs into their Security Information and Event Management (SIEM).

What You Need in Place Before Logging

Before you turn on collection or write detections, make sure your organization is actually entitled to the logs you are planning to use – and that the right features are enabled. 

1. Entitlement check (must-have) 

1. Most security logs/features are gated behind Event Monitoring via Salesforce Shield or the Event Monitoring Add-On. This applies to Real-Time Event Monitoring (RTEM) streaming and viewing.

1. RTEM – Streams (near real-time alerting): Available in Enterprise/Unlimited/Developer subscriptions; streaming events retained ~3 days.

2. RTEM – Storage: Many are Big Objects (native storage); some are standard objects (e.g. Threat Detection stores)

3. Event Log Files (ELF) – CSV model (batch exports): Available in Enterprise/Performance/Unlimited editions.

4. Event Log Objects (ELO) – SOQL model (queryable history): Shield/add-on required.

1. Use Event Manager to enable/disable streaming and storing per event; viewing RTEM events.

2. Grant access via profiles/permissions sets for RTEM and Threat Detection UI.

1. Threat Detection events are viewed in UI with Shield/add-on; stored in corresponding EventStore objects.

2.  Enhanced Transaction Security (ETS) is included with RTEM for block/MFA/notify actions on real-time events.

Recommended Log Sources to Monitor

• Login History (LoginHistory): Tracks all login attempts, including username, time, IP address, status (successful/failed), and client type. This allows you to identify unusual login times, unknown locations, or repeated failures, which could indicate credential stuffing or account compromise.

• Login Events (LoginEventStream): LoginEvent tracks the login activity of users who log in to Salesforce.

• Setup Audit Trail (SetupAuditTrail): Records administrative and configuration changes within your Salesforce environment. This helps track changes made to permissions, security settings, and other critical configurations, facilitating auditing and compliance efforts.

• API Calls (ApiEventStream): Monitors API usage and potential misuse by tracking calls made by users or connected apps.

• Report Exports (ReportEventStream): Provides insights into report downloads, helping to detect potential data exfiltration attempts.

• List View Events (ListViewEventStream): Tracks user interaction with list views, including access and manipulation of data within those views.

• Bulk API Events (BulkApiResultEvent): Track when a user downloads the results of a Bulk API request.

• Permission Changes (PermissionSetEvent): Tracks changes to permission sets and permission set groups. This event initiates when a permission is added to, or removed from a permission set. 

• API Anomaly (ApiAnomalyEvent): Track anomalies in how users make API calls. 

• Unique Query Event Type: Unique Query events capture specific search queries (SOQL), filter IDs, and report IDs that are processed, along with the underlying database queries (SQL).

• External Identity Provider Event Logs: Track information from login attempts using SSO. (Please follow the guidance provided by your Identity Provider for monitoring and collecting IdP event logs.)

These log sources will provide organizations with the logging capabilities to properly collect and monitor the common TTPs used by threat actors. The key log sources to monitor and observable Salesforce activities for each TTP are as follows:

SaaS Applications Detections  

While native SIEM threat detections provide some protection, they often lack the centralized visibility needed to connect disparate events across a complex environment. By developing custom targeted detection rules, organizations can proactively detect malicious activities. 

Data Exfiltration & Cross-SaaS Lateral Movement (Post-Authorization) 

MITRE Mapping: TA0010 – Exfiltration & TA0008 – Lateral Movement

Scenario & Objectives

After an user authorizes a (malicious or spoofed) Connected App, UNC6040 typically:

1. Performs data exfiltration quickly (REST pagination bursts, Bulk API downloads, lards/sensitive report exports).

2. Pivots to Okta/Microsoft 365 from the same risky egress IP to expand access and steal more data. 

The objective here is to detect Salesforce OAuth → Exfil within ≤10 minutes, and Salesforce OAuth → Okta/M365 login within ≤60 minutes (same risky IP), plus single-signal, low-noise exfil patterns.

Baseline & Allowlist

Re-use the lists you already maintain for the vishing phase and add two regex helpers for content focus.

• STRING

• ALLOWLIST_CONNECTED_APP_NAMES 

• KNOWN_INTEGRATION_USERS (user ids/emails that legitimately use OAuth)

• VPN_TOR_ASNS (ASNs as strings)

• ENTERPRISE_EGRESS_CIDRS (your corporate/VPN public egress)

• SENSITIVE_REPORT_REGEX

(?i)b(all|export|dump)b.*b(contact|lead|account|customer|pii|email|phone|ssn)b

• • M365_SENSITIVE_GRAPH_REGEX

(?i)^https?://graph.microsoft.com/(beta|v1.0)/(users|me)/messages
(?i)^https?://graph.microsoft.com/(beta|v1.0)/drives/.*/items/.*/content
(?i)^https?://graph.microsoft.com/(beta|v1.0)/reports/
(?i)^https?://graph.microsoft.com/(beta|v1.0)/users(?|$)

High Fidelity Detection Catalog (Pseudo-Code)

Salesforce OAuth → Data Exfil in ≤10 Minutes (Multi-Event)

Suspicious OAuth followed within 10m by Bulk result download, REST pagination burst, or sensitive/large report export by the same user.

Why high-fidelity: Matches UNC6040’s “approve → drain” pattern; tight window + volume thresholds.

Key signals:

• OAuth success (unknown app OR allowlisted+risky egress), bind on user.

• Then any of:

• BulkApiResultEvent with big RowsProcessed/RecordCount

• ApiEventStream many query/queryMore calls

• ReportEventStream large/sensitive report export

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$bulk.metadata.product_name = "SALESFORCE"
$bulk.metadata.log_type = "SALESFORCE"
$bulk.metadata.product_event_type = "BulkApiResultEvent"
$uid = coalesce($bulk.principal.user.userid, $bulk.extracted.fields["UserId"])

match:
$uid over 10m

Or

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$api.metadata.product_name = "SALESFORCE"
$api.metadata.log_type = "SALESFORCE"
$api.metadata.product_event_type = "ApiEventStream"
$uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"])

match:
$uid over 10m

Or

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) )
$uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"])

$report.metadata.product_name = "SALESFORCE"
$report.metadata.log_type = "SALESFORCE"
$report.metadata.product_event_type = "ReportEventStream"
strings.to_lower(coalesce($report.extracted.fields["ReportName"], "")) in regex SENSITIVE_REPORT_REGEX
$uid = coalesce($report.principal.user.userid, $report.extracted.fields["UserId"])

match:
$uid over 10m

Note: Single event rule can also be used instead of multi-event rules in this case where only the Product Event Types like ApiEventStream, BulkApiResultEvent, ReportEventStream can be used as a single event rule to be monitored. But, care has to be taken if a single event rule is established as these can be very noisy, and thus the reference lists should be actively monitored.

Bulk API Large Result Download (Non-Integration User)

Bulk API/Bulk v2 result download above threshold by a human user.

Why high-fidelity: Clear exfil artifact.

Key signals: BulkApiResultEvent, user not in KNOWN_INTEGRATION_USERS.

Lists/knobs: KNOWN_INTEGRATION_USERS, size threshold.

$e.metadata.product_name = "SALESFORCE"
$e.metadata.log_type = "SALESFORCE"
$e.metadata.product_event_type = "BulkApiResultEvent"
not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)

REST Query Pagination Burst (query/queryMore)

High-rate query*/queryMore calls over a short window.

Why high-fidelity: Mimics scripted drains; steady human usage won’t hit burst thresholds.

Key signals: ApiEventStream, Operation in query, queryMore, query_all, queryall, count ≥ threshold in 10m, user not in KNOWN_INTEGRATION_USERS.

Lists/knobs: burst threshold, KNOWN_INTEGRATION_USERS.

$api.metadata.product_name = "SALESFORCE"
$api.metadata.log_type = "SALESFORCE"
$api.metadata.product_event_type = "ApiEventStream"
not (coalesce($api.principal.user.userid, $api.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)
strings.to_lower(coalesce($api.extracted.fields["Operation"], "")) in regex `(?i)^(query|querymore|query_all|queryall)$`
$uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"])

Sensitive Report Export by Non-Integration User

Exports of large or sensitive-named reports by a human.

Why high-fidelity: Report extracts are a common, noisy-to-attackers but high-signal vector.

Key signals: ReportEventStream, high RowsProcessed or ReportName matches SENSITIVE_REPORT_REGEX, user not in KNOWN_INTEGRATION_USERS.

Lists/knobs: SENSITIVE_REPORT_REGEX, KNOWN_INTEGRATION_USERS.

$e.metadata.product_name = "SALESFORCE"
$e.metadata.log_type = "SALESFORCE"
$e.metadata.product_event_type = "ReportEventStream"
not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS)
strings.to_lower(coalesce($e.extracted.fields["ReportName"], "")) in regex %SENSITIVE_REPORT_REGEX

Salesforce OAuth → Okta/M365 Login From Same Risky IP in ≤60 Minutes (Multi-Event)

Suspicious Salesforce OAuth followed within 60m by Okta or Entra ID login from the same public IP, where the IP is off-corp or VPN/Tor ASN.

Why high-fidelity: Ties the attacker’s egress IP across SaaS within a tight window.

Key signals:

• Salesforce OAuth posture (unknown app OR allowlisted+risky egress)

• OKTA* or OFFICE_365 USER_LOGIN from the same IP

Lists/knobs: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS. (Optional sibling rule binding by user email if identities are normalized.)

$oauth.metadata.product_name = "SALESFORCE"
$oauth.metadata.log_type = "SALESFORCE"
$oauth.extracted.fields["LoginType"] = "Remote Access 2.0"
($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success")
( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES)
and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS )
$ip = coalesce($oauth.principal.asset.ip, $oauth.principal.ip)

$okta.metadata.log_type in "OKTA"
$okta.metadata.event_type = "USER_LOGIN"
$ip = coalesce($okta.principal.asset.ip, $okta.principal.ip) = $ip

$o365.metadata.log_type = "OFFICE_365"
$o365.metadata.event_type = "USER_LOGIN"
$ip = coalesce($o365.principal.asset.ip, $o365.principal.ip)

match:
$ip over 10m

M365 Graph Data-Pull After Risky Login

Entra ID login from risky egress followed by Microsoft Graph endpoints that pull mail/files/reports.

Why high-fidelity: Captures post-login data access typical in account takeovers.

Key signals: OFFICE_365 USER_LOGIN with off-corp IP or VPN/Tor ASN, then HTTP to URLs matching M365_SENSITIVE_GRAPH_REGEX by the same account within hours.

Lists/knobs: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS, M365_SENSITIVE_GRAPH_REGEX.

$login.metadata.log_type = "OFFICE_365"
$login.metadata.event_type = "USER_LOGIN"
$ip  = coalesce($login.principal.asset.ip, $login.principal.ip)
( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS)
 or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS )
$acct = coalesce($login.principal.user.userid, $login.principal.user.email_addresses)

$http.metadata.product_name in ("Entra ID","Microsoft")
($http.metadata.event_type = "NETWORK_HTTP" or $http.target.url != "")
$acct = coalesce($http.principal.user.userid, $http.principal.user.email_addresses)
strings.to_lower(coalesce($http.target.url, "")) in regex %M365_SENSITIVE_GRAPH_REGEX

match:
$acct over 30m

Tuning & Exceptions

• Identity joins – The lateral rule groups by IP for robustness. If you have strong identity normalization (Salesforce <-> Okta <-> M365), clone it and match on user email instead of IP.

• Change windows – Suppress time-bound rules during approved data migrations/Connected App onboarding (temporarily add vendor app to ALLOWLIST_CONNECTED_APP_NAMES)

• Integration accounts – Keep KNOWN_INTEGRATION_USERS current; most noise in exfil rules comes from scheduled ETL.

• Egress hygiene – Keep ENTERPRISE_EGRESS_CIDRS current; stale NAT/VPN ranges inflate VPN/Tor findings.

• Streaming vs stored – The aforementioned rules assume Real-Time Event Monitoring Stream objects (e.g., ApiEventStream, ReportEventStream, ListViewEventStream, BulkApiResultEvent). For historical hunts, query the stored equivalents (e.g., ApiEvent, ReportEvent, ListViewEvent) with the same logic.

IOC-Based Detections

Scenario & Objectives

A malicious threat actor has either successfully accessed or attempted to access an organization’s network.

The objective is to detect the presence of known UNC6040 IOCs in the environment based on all of the available logs.

Reference Lists

Reference lists organizations should maintain:

• STRING

• UNC6040_IOC_LIST (IP addresses from threat intel sources eg. VirusTotal)

List of indicators of compromise (IOCs).

High Fidelity Detection Catalog (Pseudo-Code)

UNC6040 IP_IoC Detected

A known IOC associated with UNC6040 was detected in the organization’s environment either from a source or destination connection.

• High-fidelity when conditioned on source or destination IP address matches a known UNC6040 IOC.

($e.principal.ip in %unc6040_IoC_list) or ($e.target.ip in %unc6040_IoC_list)

Acknowledgements

We would like to thank Salesforce for their collaboration and assistance in building this guide.

This powerful combination of technical and financial flexibility isn’t just theoretical. It’s being used by leading companies today to drive real-world results. At Google Cloud Next ’25, Justin Reid, a principal engineer at Shopify, shared how the company leverages GKE compute classes to power one of the world’s largest GKE fleets.

GKE compute classes enabled Shopify to serve up massive scale during Black-Friday / Cyber Monday by implementing the exact strategy described above: they defined a compute class that prioritizes the new N4 machines and included N2 machines as a seamless fallback option. 

“Compute Classes played a critical role in helping Shopify scale during our most demanding events… It removed a ton of operation complexity for us…” – Justin Reid, principal engineer, Shopify

Watch the whole Next ‘25 session here.

Another example: High-performance workloads with C-series Family

For demanding workloads, C-series VMs are a popular choice, offering consistently high performance and access to enterprise features such as locally attached SSDs, advanced maintenance controls, larger VM shapes, and higher CPU frequencies. You can set up a compute class to prioritize new, performant options like C4 and C4D, which deliver compelling price-performance gains over prior-generation VMs, and also include a fallback to a VM you’ve used extensively.

Your ComputeClass can set C4 or C4D as a primary VM, the other as a fallback option, and C2 VMs as a last. This can allow you to maximize your obtainability for the newest machine types and confidently take advantage of supply for multiple previous-generation platforms without sacrificing availability.

Your ComputeClass manifest might look something like this:

YAML:

Verve Group SE is a leading digital media company that empowers advertisers and publishers with AI-driven ad-software solutions, connecting them to deliver impactful campaigns with a focus on first-party data and privacy-first technologies. 

“Verve uses a variety of machine series including the new C4D as well as other VMs like C3D and N2D. We use custom compute classes to orchestrate fall backs, ranked for cost/performance across regions. The bulk of our spend is covered by Compute Flex CUDs, which plays a vital role in giving us discount flexibility across many of the machine series we consume.” – Pablo Loschi, Principal Systems Engineer, Verve

A winning combination for modern infrastructure

By pairing the technical resilience of GKE compute classes with the discounting adaptability of Compute Flex CUDs, you can create a robust and economically sound strategy for hardware adoption like the new generation of Compute Engine machine shapes. This integrated approach empowers you to:

• Innovate safely: Gradually introduce and test new machine series with your critical workloads.

• Optimize performance and cost: Leverage the latest and most cost performant hardware Google Cloud has to offer.

• Enhance resilience: Ensure high availability for your applications even as you integrate new hardware.

• Simplify operations: Let GKE manage the complexities of node provisioning and scaling across different machine types.

Leverage these capabilities to stay at the forefront of innovation and confidently explore and harness the benefits of Google Cloud’s rapidly evolving compute landscape — securely, efficiently, and cost-effectively.

To learn more, this video offers a helpful overview of how custom compute classes can improve infrastructure autoscaling in GKE. Then, explore Compute Engine’s fourth generation machine types, GKE compute classes and Compute Flexible CUDs today!

Acknowledgements: We’d like to thank Yasmin Mowafy, Senior Product Manager, Google Compute Engine, for her contributions to this post. 

In episode #8 of The Agent Factory, Ivan Nardini and I are joined by Prateek Dudeja, product manager from the Agent Payment Protocol Team, to dive into one of the biggest hurdles for AI agents in eccomerce: trust, especially when it comes to money.

This post guides you through the key ideas from our conversation. Use it to quickly recap topics or dive deeper into specific segments with links and timestamps.

Introducing Agent Payment Protocol

Timestamp: [01:43]

What if an agent could buy concert tickets for you at a specific time that the tickets go on sale. You don’t want to miss out! Maybe you want two tickets, and you don’t want to spend more than $200. You definitely want to sit in a section with a great view of the stage. To have an agent act as your ticket buyer, you would have to trust that agent with all facets of your request and your credit card. How can you be sure that the agent won’t buy 200 tickets or that it won’t charge you for a lifetime supply of rubber duckies?

The potential for a messy outcome with this concert ticket request provides insight into a “Crisis of Trust” that can hold back agentic commerce. The good news is there’s a way to move forward and build trust. 

To solve the “Crisis of Trust,” Google introduced the Agent Payment Protocol (AP2), a new open standard. It’s not a new payment system; it’s a “trust layer” that sits on top of existing infrastructure. AP2 is designed to create a common, secure language for agents to conduct commerce, using role-based architecture and verifiable credentials.

Agent Payments and the Current Payment System

Timestamp: [02:29]

The current payment system was built for humans using trusted interfaces like browsers, not for autonomous agents, resulting in three main challenges for agents: authorization, agent error, and accountability.

The Agent Payment Protocol addresses these challenges by helping agents communicate securely with merchants and payment partners. The Agent Payment Protocol is available today as an extension for the A2A (Agent2Agent) protocol and relies on agents using the Model Context Protocol (MCP). 

Deep Dive into the Agent Payment Protocol

Learn more about how this protocol works, including concepts and flow.

A Role-Based Ecosystem

Timestamp: [04:33]

The protocol is built on a “separation of concerns.” Your agent doesn’t have to do everything. There are specialized roles:

• Shopping Agent: The AI agent you build, great at finding products.

• Merchant Endpoint: The seller’s API.

• Credential Provider: A secure digital wallet (like PayPal, Google Pay, etc.) that manages payment details.

• Merchant Payment Processor: The entity that constructs the final authorization message for the payment networks.

Critical: Your shopping agent never touches the raw credit card number. It doesn’t need to be PCI compliant because it delegates the payment to the specialized, secure providers.

Verifiable Credentials (VCs)

Timestamp: [06:15]

The “handshakes” between these roles in the Agent Payment Protocol ecosystem are secured by Verifiable Credentials (VCs). Think of credentials as protocolized, cryptographically signed digital receipts that prove what was agreed upon.

There are three types of verifiable credentials:

Cart Mandate: For “human-present” scenarios. The user reviews a final cart and cryptographically signs it as proof of approval.

Intent Mandate: For “human-not-present” scenarios (like the concert ticket example). The user signs an intent (e.g., “buy tickets under $200”), giving the agent authority to act within those guardrails.

Payment Mandate: Provides clear visibility to payment networks and banks that an AI agent was involved in the transaction.

A Contractual Conversational Model

Timestamp: [08:03]

The Agent Payment Protocol process creates a “Contractual Conversational Model,” moving beyond simple API calls to a flow built on verifiable proof.

To understand this flow, we’ll walk through a human-present scenario:

1. Delegation: You tell your agent, “Buy two concert tickets.”

2. Discovery & Negotiation: The agent contacts the merchant’s endpoint to prepare the cart.

3. Finalize Cart: The agent reaches out to your Credential Provider (e.g., your digital wallet). You select the payment method. The agent only gets a reference (like the last 4 digits), never the full credential.

4. Authorization with Mandates: The agent shows you the final, finalized cart.

5. You cryptographically sign the Cart Mandate. This is the non-repudiable proof, the “contract.”

6. Purchase: The agent sends this signed mandate to the merchant. The merchant can now trust the purchase mandate is from you. The merchant’s payment processor uses the mandate to securely get the payment token from the credential provider and complete the transaction.

This flow all hinges on trust. In the short term, this trust is built using manual allow lists of approved agents and merchants. In the long term, the plan is to use open web standards like HTTPS and DNS ownership to verify identities.

Q&A with Prateek Dudeja

Timestamp: [13:07]

With the concepts explained, the discussion moved to a Q&A with Prateek.

Why a New Protocol for Payments?

Timestamp: [13:30]

Prateek gave a great analogy: HTTPS is a baseline protocol for browsing. Signing in requires stronger authentication. Making a payment requires an even higher level of trust. AP2 provides that “payments-grade security” on top of baseline protocols like A2A and MCP, ensuring the transaction is high-trust and truly from a human.

How Will Agents Find Trusted Partners?

Timestamp: [14:42]

In the short term, agents will use “decentralized registries of trust” (or allow lists) to find merchants they can interact with. Prateek noted that all the roles (merchant, credential provider, etc.) already exist in the payments industry today. The only new role is the Shopping Agent itself.

Accountability: What Happens When Things Go Wrong?

Timestamp: [16:03]

This is the big question. What if your agent shows you blue shoes, you wanted teal, but you click “approve” anyway?

Prateek explained that the signed Cart Mandate solves this. Because you biometrically signed a tamper-proof credential showing the blue shoes, the responsibility is on you. The merchant has cryptographic evidence that you saw and approved the exact product. This protects merchants from fraudulent chargebacks and users from unauthorized agent actions.

Demo: Reference Implementation

Timestamp: [18:04]

Prateek walked through a demo showing the human-present flow. It showed the user prompting the agent, the agent discovering products, and then the Credential Provider (PayPal) getting involved. The user selected their shipping and payment info from PayPal, and the agent only saw a reference. The user then signed the Cart Mandate, and the purchase was completed.

Compatibility and Getting Started

Timestamp: [19:43]

A key question was – Is this compatible with frameworks like LangGraph or CrewAI? Yes. Prateek confirmed the protocol is compatible with any framework. As long as your agent can communicate over A2A or MCP, you can use AP2.

To get started, Prateek directed developers to the GitHub repo. The first step is to see which role you want to play (merchant, credentials provider, etc.) and explore the sample code for that role.

The Future: Dynamic Negotiation

Timestamp: [21:13]

Looking ahead, Prateek shared an exciting vision for “dynamic negotiation.” Imagine telling your agent: “I want that red dress that’s out of stock. I need it by tomorrow… and I’m willing to pay 30% more”.

A merchant’s agent could see this “intent” and, if the dress becomes available, automatically complete the sale. What was a lost sale for the merchant becomes a completed order at a markup, and the user gets the exact item they desperately wanted. 

Your turn to build

This conversation made it clear that building a secure payment infrastructure is a foundational step toward creating agents that can perform truly useful tasks in the real world. We’re moving from a simple, programmatic web to a conversational, contractual one, and this protocol provides the framework for it.

We encourage you to check out the Agent Payment Protocol GitHub repo, think about which role you could play in this new ecosystem, and start building today!

Connect with us

• Shir Meir Lador → LinkedIn, X

• Ivan Nardini → LinkedIn, X

• Prateek Dudeja → Linkedin

A year ago today, Google Cloud filed a formal complaint with the European Commission about Microsoft’s anti-competitive cloud licensing practices — specifically those that impose financial penalties on businesses that use Windows Server software on Azure’s biggest competitors. 

Despite regulatory scrutiny, it’s clear that Microsoft intends to keep its restrictive licensing policies in place for most cloud customers. In fact, it’s getting worse. 

As part of a recent earnings call, Microsoft disclosed that its efforts to force software customers to use Azure are “not anywhere close to the finish line,” and represented one of three pillars “driving [its] growth.” As we approach the end of September, Microsoft is imposing another wave of licensing changes to force more customers to Azure by preventing managed service providers from hosting certain workloads on Azure’s competitors.

Regulators have taken notice. As part of a comprehensive investigation, the U.K.’s Competition and Markets Authority (CMA) recently found that restrictive licensing harms cloud customers, competition, economic growth, and innovation. At the same time, a growing number of regulators around the world are also scrutinizing Microsoft’s anti-competitive conduct — proving that fair competition is an issue that transcends politics and borders.

While some progress has been made, restrictive licensing continues to be a global problem, locking in cloud customers, harming economic growth, and stifling innovation.

Economic, security, and innovation harms

Restrictive cloud licensing has caused an enormous amount of harm to the global economy over the last year. This includes direct penalties that Microsoft forces businesses to pay, and downstream harms to economic growth, cybersecurity, and innovation. Ending restrictive licensing could help supercharge economies around the world.

Microsoft still imposes a 400% price markup on customers who choose to move legacy workloads to competitors’ clouds. This penalty forces customers onto Azure by making it more expensive to use a competitor. A mere 5% increase in cloud pricing due to lack of competition costs U.K. cloud customers £500 million annually, according to the CMA. A separate study in the EU found restrictive licensing amounted to a billion-Euro tax on businesses. 

In the United States, the lack of competition due to Microsoft’s licensing tactics amounts to $750 million in overspending by government agencies every year. 

Cybersecurity and reliability also suffer, as Microsoft drives customers into an insecure monoculture that becomes a single point of failure. Attacks on Microsoft’s insecure software have spread across governments and critical industries.

With AI technologies disrupting the business market in dramatic ways, ending Microsoft’s anti-competitive licensing is more important than ever as customers move to the cloud to access AI at scale. Customers, not Microsoft, should decide what cloud — and therefore what AI tools — work best for their business.

The ongoing risk of inaction

Perhaps most telling of all, the CMA found that since some of the most restrictive licensing terms went into place over the last few years, Microsoft Azure has gained customers at two or even three times the rate as competitors. Less choice and weaker competition is exactly the type of “existential challenge” to Europe’s competitiveness that the Draghi report warned of. 

Ending restrictive licensing could help governments “unlock up to €1.2 trillion in additional EU GDP by 2030” and “generate up to €450 billion per year in fiscal savings and productivity gains,” according to a recent study by the European Centre for International Political Economy. Now is the time for regulators and policymakers globally to act to drive forward digital transformation and innovation. 

In the year since our complaint to the European Commission, our message is as clear as ever: Restrictive cloud licensing practices harm businesses and undermine European competitiveness. To drive the next century of technology innovation and growth, regulators must act now to end these anti-competitive licensing practices that harm businesses.

Autopilot is an operational mode for Google Kubernetes Engine (GKE) that provides a fully managed environment and takes care of operational details, like provisioning compute capacity for your workloads. Autopilot allows you to spend more time on developing your own applications and less time on managing node-level details. This year, we upgraded Autopilot’s autoscaling stack to a fully dynamic container-optimized compute platform that rapidly scales horizontally and vertically to support your workloads. Simply attach a horizontal pod autoscaler (HPA) or vertical pod autoscaler (VPA) to your environment, and experience a fully dynamic platform that can scale rapidly to serve your users.

More and more customers, including Hotspring and Contextual AI, understand that Autopilot can dramatically simplify Kubernetes cluster operations and enhance resource efficiency for their critical workloads. In fact, in 2024, 30% of active GKE clusters were created in Autopilot mode. The new container-optimized compute platform has also proved popular with customers, who report rapid performance improvements in provisioning time. The faster GKE provisions capacity, the more responsive your workloads become, improving your customers’ experience and optimizing costs. 

Today, we are pleased to announce that the best of Autopilot is now available in all qualified GKE clusters, not just dedicated Autopilot ones. Now, you can utilize Autopilot’s container-optimized compute platform and ease of operation from existing GKE clusters. It’s generally available, starting with clusters enrolled in the Rapid release channel and running GKE version 1.33.1-gke.1107000 or later. Most clusters  will qualify and be able to access these new features as they roll out to the other release channels, except clusters enrolled in the Extended channel and those that use the older routes-based networking. To access these new features, enroll in the Rapid channel and upgrade your cluster version, or wait to be auto-upgraded.

How to use it

Autopilot features are offered in Standard clusters via compute classes, which are a modern way to group and specify compute requirements for workloads in GKE. GKE now has two built-in compute classes, autopilot and autopilot-spot, that are pre-installed on all qualified clusters running on GKE 1.33.1-gke.1107000 or later and enrolled in the Rapid release channel. Running your workload on Autopilot’s container-optimized compute platform is as easy as specifying the autopilot (or autopilot-spot) compute class, like so:

Better still, you can make the Autopilot container-optimized compute platform the default for a namespace, a great way to save both time and money. You get efficient bin-packing, where the workload is charged for resource requests (and can even still burst!), rapid scaling, and you don’t have to plan your node shapes and sizes. 

Here’s how to set Autopilot as your default for a namespace:

Pod sizes for the container-optimized compute platform start at 50 milli-CPU (that’s just 5% of 1 CPU core!), and can scale to 28vCPU. With the container-optimized compute platform you only pay for the resources your Pod requests, so you don’t have to worry about system overhead or empty nodes. Pods such as those larger than 28 vCPU or with specific hardware requirements can also run in Autopilot mode on specialized compute with node-based pricing via customized compute classes.

Run AI workloads on GPUs and TPUs with Autopilot

It’s easy to pair Autopilot’s container-optimized compute platform with specific hardware such as GPUs, TPUs and high-performance CPUs to run your AI workloads. You can run those workloads in the same cluster side by side Pods on the container-optimized compute platform. By choosing Autopilot mode for these AI workloads, you benefit from the Autopilot’s managed node properties, where we take a more active role in management. Furthermore, you also get our enterprise-grade privileged admission controls that require workloads to run in user-space, for better supportability, reliability and an improved security posture.

Here’s how to define your own customized compute class that runs in Autopilot mode with specific hardware, in this example a G2 machine type with NVIDIA L4s with two priority rules:

A new way to use compute classes

We’re also making compute classes work better with a new provisioning mode that automatically provisions resources for compute classes, without changing how other workloads are scheduled on existing node pools. This means you can now adopt the new deployment paradigm of compute class (including the new Autopilot-enabled compute classes) at your own pace, without affecting existing workloads and deployment strategies.

Until now, to use compute class in Standard clusters with automatic node provisioning, you needed to enable node auto-provisioning for the entire cluster. Node auto-provisioning has been part of GKE for many years, but it was previously an all-or-nothing decision — you couldn’t easily combine a manual node pool with a compute class provisioned by node auto-provisioning without potentially changing how workloads outside of the compute class were scheduled. Now you can, with our new automatically provisioned compute classes. All Autopilot compute classes use this system, so it’s easy to run workloads in Autopilot mode side-by-side with your existing deployments (e.g., on manual node pools). You can also enable this feature on any compute class starting with clusters in the Rapid channel running GKE version 1.33.3-gke.1136000 or later.

Here’s how:

With the Autopilot mode for compute classes in Standard clusters, and the new automatic provisioning mode for all compute classes, you can now introduce compute class as an option to more clusters without impacting how any of your existing workloads are scheduled. Customers we’ve spoken to like this, as they can adopt these new patterns gradually for new workloads and by migrating existing ones, without needing to plan a disruptive switch-over.

Autopilot for all

At Google Cloud, we believe in the power of GKE’s Autopilot mode to simplify operations for your GKE clusters and make them more efficient. Now, those benefits are available to all GKE customers! To learn more about GKE Autopilot and how to enable it for your clusters, check out these resources.

1. How to run workloads on Autopilot in GKE Standard clusters.

2. Learn how the container-optimized compute works under the hood to drive performance.

3. Watch the GKE Spotlight from NEXT ‘25, and read the announcement.

The role of the data scientist is rapidly transforming. For the past decade, their mission has centered on analyzing the past to run predictive models that informed business decisions. Today, that is no longer enough. The market now demands that data scientists build the future by designing and deploying intelligent, autonomous agents that can reason, act, and learn on behalf of the enterprise.

This transition moves the data scientist from an analyst to an agentic architect. But the tools of the past — fragmented notebooks, siloed data systems, and complex paths to production — create friction that breaks the creative flow.

At Big Data London, we are announcing the next wave of data innovations built on an AI-native stack, designed to address these challenges. These capabilities help data scientists move beyond analysis to action by enabling them to:

• Stop wasting time context-switching. We’re delivering a single, intelligent notebook environment where you can instantly use SQL, Python, and Spark together, letting you build and iterate in one place instead of fighting your tools.

• Build agents that understand the real world. We’re giving you native, SQL-based access to the messy, real-time data — like live event streams and unstructured data — that your agents need to make smart, context-aware decisions.

• Go from prototype to production in minutes, not weeks. We’re providing a complete ‘Build-Deploy-Connect’ toolkit to move your logic from a single notebook into a secure, production-grade fleet of autonomous agents.

Unifying the environment for data science

The greatest challenge of data science productivity is friction. Data scientists live in a state of constant, forced context-switching: writing SQL in one client, exporting data, loading it into a Python notebook, configuring a separate Spark cluster for heavy lifting, and then switching to a BI tool just to visualize results. Every switch breaks the creative “flow state” where real discovery happens. Our priority is to eliminate this friction by creating the single, intelligent environment an architect needs to engineer, build, and deploy — not just run predictive models. 

Today, we are launching fundamental enhancements to Colab Enterprise notebooks in BigQuery and Vertex AI. We’ve added native SQL cells (preview), so you can now iterate on SQL queries and Python code in the same place. This lets you use SQL for data exploration and immediately pipe the results into a BigQuery DataFrame to build models in Python. Furthermore, rich interactive visualization cells (preview) automatically generate editable charts from your data to quickly assess the analysis. This integration breaks the barrier between SQL, Python, and visualization, transforming the notebook into an integrated development environment for data science tasks.

But an integrated environment is only half the solution; it must also be intelligent. This is the power of our Data Science Agent, which acts as an “interactive partner” inside Colab. Recent enhancements to this agent mean it can now incorporate sophisticated tool usage (preview) within its detailed plans, including the use of BigQuery ML for training and inferencing, BigQuery DataFrames for analysis using Python, or large scale Spark transformations. This means your analysis gets more advanced, your demanding workloads are more cost-effective to run, and your models get into production quicker. 

In addition, we are also making our Lightning Engine generally available. The Lightning Engine accelerates Spark performance more than 4x compared to open-source Spark. And Lightning Engine is ML and AI-ready by default, seamlessly integrating with BigQuery Notebooks, Vertex AI, and VS Code. This means you can use the same accelerated Spark runtime across your entire workflow in any tool of choice — from initial exploration in a notebook to distributed training on Vertex AI. We’re also announcing advanced support for Spark 4.0 (preview), bringing its latest innovations directly to you. 

Building agents that understand the real world

Agentic architects build systems that will sense and respond to the world in real time. This requires access to data that has historically been siloed in separate, specialized systems such as live event streams and unstructured data. To address this challenge we are making real-time streams and unstructured data more accessible for data science teams.

First, to process real-time data using SQL we are announcing stateful processing for BigQuery continuous queries (preview). In the past, it was difficult to ask questions about patterns over time using just SQL on live data. This new capability changes that. It gives your SQL queries a “memory,” allowing you to ask complex, state-aware questions. For example, instead of just seeing a single transaction, you can ask, “Has this credit card’s average transaction value over the last 5 minutes suddenly spiked by 300%?” An agent can now detect this suspicious velocity pattern — which a human analyst reviewing individual alerts would miss — and proactively trigger a temporary block on the card before a major fraudulent charge goes through. This unlocks powerful new use cases, from real-time fraud detection to adaptive security agents that learn and identify new attack patterns as they happen.

Second, we are removing the friction to build AI applications using a vector database, by helping data teams with autonomous embedding generation in BigQuery (preview) over multimodal data. Building on our BigQuery Vector Search capabilities, you no longer have to build, manage, or maintain a separate, complex data pipeline just to create and update your vector embeddings. BigQuery now takes care of this automatically as data arrives and as users search for new terms in natural language. This capability enables agents to connect user intent to enterprise data, and it’s already powering systems like the in-store product finder at Morrisons, which handles 50,000 customer searches on a busy day. Customers can use the product finder on their phones as they walk around the supermarket. By typing in the name of a product, they can immediately find which aisle a product is on and in which part of that aisle. The system uses semantic search to identify the specific product SKU, querying real-time store layout and product catalog data.

Trusted, production ready multi-agent development 

When an analyst delivers a report and their job is done. When an architect deploys an autonomous application or agent, their job has just begun. This shift from notebook-as-prototype to agent-as-product introduces a critical new set of challenges: How do you move your notebook logic into a scalable, secure, and production-ready fleet of agents?

To solve this, we are providing a complete “Build-Deploy-Connect” toolkit for the agent architect. First, the Agent Development Kit (ADK) provides the framework to build, test, and orchestrate your logic into a fleet of specialized, production-grade agents. This is how you move from a single-file prototype to a robust, multi-agent system. And this agentic fleet doesn’t just find problems — it acts on them. ADK allows agents to ‘close the loop’ by taking intelligent, autonomous actions, from triggering alerts to creating and populating detailed case files directly in operational systems like ServiceNow or Salesforce.

A huge challenge until now was securely connecting these agents to your enterprise data, forcing developers to build and maintain their own custom integrations. To solve this, we launched first-party BigQuery tools directly integrated within ADK or via MCP. These are Google-maintained, secure tools that allow your agent to intelligently discover datasets, get table info, and execute SQL queries, freeing your team to focus on agent logic, not foundational plumbing. In addition, your agentic fleet can now easily connect to any data platform in Google Cloud using our MCP Toolbox. Available across BigQuery, AlloyDB, Cloud SQL, and Spanner, MCP Toolbox provides a secure, universal ‘plug’ for your agent fleet, connecting them to both the data sources and the tools they need to function.

This “Build-Deploy-Connect” toolkit also extends to the architect’s own workflow. While ADK helps agents connect to data, the architect (the human developer) needs to manage this system using a new primary interface: the command line (CLI). To eliminate the friction of switching to a UI for data tasks, we are integrating data tasks directly into the terminal with our new Gemini CLI extensions for Data Cloud (preview). Through the agentic Gemini CLI, developers can now use natural language to find datasets, analyze data, or generate forecasts — for example, you can simply state gemini bq “analyze error rates for ‘checkout-service'” — and even pipe results to local tools like Matplotlib, all without leaving your terminal.

Architecting the future

These innovations transform the impact data scientists can have within the organization. Using an AI-native stack we are now unifying the development environment in new ways, expanding data boundaries, and enabling trusted production ready development. 

You can now automate tasks and use agents to become an agentic architect helping your organization to sense, reason, and act with intelligence. Ready to experience this transformation? Check out our new Data Science eBook with eight practical use cases and notebooks to get you started building today.

In June, Google introduced Gemini CLI, an open-source AI agent that brings the power of Gemini directly into your terminal. And today, we’re excited to announce open-source Gemini CLI extensions for Google Data Cloud services. 

Building applications and analyzing trends with services like Cloud SQL, AlloyDB and BigQuery has never been easier — all from your local development environment! Whether you’re just getting started or a seasoned developer, these extensions make common data interactions such as app development, deployment, operations, and data analytics more productive and easier. So, let’s jump right in!

Using a Data Cloud Gemini CLI extension

Before you get started, make sure you have enabled the APIs and configured the IAM permissions required to access specific services.

To retrieve the newest functionality, install the latest release of the Gemini CLI (v0.6.0):

npm install -g @google/gemini-cli@latest

Next, install the extension:

gemini extensions install https://github.com/gemini-cli-extensions/<EXTENSION>

Replace <EXTENSION> with the name of the service you want to use. For example, alloydb, cloud-sql-postgresql or bigquery-data-analytics. 

Before starting the Gemini CLI, you’ll need to configure the extension to connect with your Google Cloud project by adding the required environment variables. The table below provides more information on the configuration required. 

Now, you can start the Gemini CLI using command gemini. You can view the extensions installed with the command /extensions

You can list the MCP servers and tools included in the extension using command /mcp list

Using the Gemini CLI for Cloud SQL for PostgreSQL extension

The Cloud SQL for PostgreSQL extension lets you perform a number of actions. Some of the main ones are included below:

1. Create instance: Creates a new Cloud SQL instance for PostgreSQL (and also MySQL, or SQL Server)

2. List instances: Lists all Cloud SQL instances in a given project

3. Get instance: Retrieves information about a specific Cloud SQL instance

4. Create user: Creates a new user account within a specified Cloud SQL instance, supporting both standard and Cloud IAM users

Curious about how to put it in action? Like any good project, start with a solid written plan of what you are trying to do. Then, you can provide that project plan to the CLI as a series of prompts, and the agent will start provisioning the database and other resources:

After configuring the extension to connect to the new database, the agent can generate the required tables based on the approved plan. For easy testing, you can prompt the agent to add test data.

Now the agent can use the context it has to generate an API to make the data accessible.

As you can see, these extensions make it incredibly easy to start building with Google Cloud databases!

Using the BigQuery Analytics extensions 

For your analytical needs, we are thrilled to give you a first look at the Gemini CLI extension for BigQuery Data Analytics. We are also excited to give access to the Conversational Analytics API through the BigQuery Conversational Analytics extension. This is the first step in our journey to bring the full power of BigQuery directly into your local coding environment, creating an integrated and unified workflow. 

With this extension you can 

1. Explore data: Use natural language to search for your tables.

2. Analyze: Ask business questions on the data and generate intelligent insights. 

3. Dive deeper: Use conversational analytics APIs to dive deeper into the insights. 

4. And extend: Use other tools or extensions to extend into advanced workflows like charting, reporting, code management, etc. 

This initial release provides a comprehensive suite of tools to Gemini CLI:

• Metadata tools: Discover and understand the BigQuery data landscape. 

• Query execution tool: Run any BigQuery query and get the results back, summarized to your console.

• AI-powered forecasting: Leverage BigQuery’s built-in AI.Forecast function for powerful time-series predictions directly from the command line.

• Deeper data Insights: The“ask_data_insights” tool provides access to server-side BigQuery agent for richer data insights.

• And more …

[Note: To use the conversational analytics extension you need to enable additional APIs. Refer to documentation for additional info.]

Here is an example journey with analytics extensions: 

Explore and analyze your data , e.g.,

Run deeper insights  

Using “ask_data_insights” to trigger an agent on the BigQuery (Conversational analytics API) to answer your questions. The server side agent is smart enough to gather additional context about your data and offer deeper insights into your questions.

You can go further and generate charts and reports by mixing BigQuery data with your local tools. Here’s a prompt to try:

”using bigquery-public-data.pypi.file_downloads can you forecast downloads for the last four months of 2025 for package urllib3? Please plot a chart that includes actual downloads for the first 8 months, followed by the forecast for the last four months”

Get started today!

Ready to level up your Gemini CLI extensions for our Data Cloud services? Read more in the extensions documentation. Check out our templates and start building your own extensions to share with the community!