Skip to content
Secure Smarter — Solutions for Modern Threats

From AI-driven SecOps to cloud security automation, Foresite delivers fully managed and scalable security solutions tailored for enterprise, hybrid, and multi-cloud environments.

Why Foresite — Security Excellence, Your Way

From our Adaptive Security Model to our Google Cloud Premier SecOps Partnership, we combine deep expertise, purpose-built technology, and customer-first flexibility.

Google Cloud Security — delivered by Foresite,
Premier SecOps Partner

Combine Google’s native security power with Foresite’s expert-driven, AI-powered operations to secure your cloud and unlock business growth.

Foresite - Google Cloud SecOps Delivery Partner Badge
Two API scope groups from the Wiz integration for Google SecOps: read scopes run unattended, write scopes require a named practitioner to authorize
Stephen MullerSeptember 21, 202611 min read

Google Threat Intelligence Is Now in Wiz. Here's What That Does and Doesn't Mean

Google Threat Intelligence Is Now in Wiz. Here's What That Does and Doesn't Mean
14:42

TL;DR

Wiz findings now come with Google Threat Intelligence context attached. The two products work together more closely, but they haven't merged. You still license them separately, and the enrichment only helps if someone with the authority to act is reading it.

Foresite runs both a  Google Cloud practice and a Wiz practice. (We're a Premier Partner with each, and Google Cloud's 2026 Security Partner of the Year for North America.) So when GTI context started appearing in the Wiz console, we knew customers would ask whether it changes their architecture or only what they see on screen. We wanted an answer first.

It changes what's on screen. The architecture underneath is the same.

 

What shipped

On August 4, 2026, Wiz announced that Google Threat Intelligence enrichment is live for all Wiz customers at no extra setup (Wiz, August 4, 2026). Findings now pull in Mandiant frontline intelligence, VirusTotal's crowdsourced data, and Google's own threat research. For a malware finding, you get more than a malicious/benign verdict. You get enough background on the threat to decide how urgent it is before anyone opens an investigation. GTI's intelligence on malicious AI Skills also flags open-source skills that are risky for AI agents to import.

A second piece is still being built. Google and Wiz have started connecting Wiz Attack Surface Management to the GTI correlation engine, so external exposures can be checked against current adversary activity. Google says so directly: "we've begun integration efforts" and "we will continue to build towards native integration." Behavior-based guidance on critical risks is described as planned, not available (Google Cloud, July 7, 2026).

For context, Wiz ASM maps your external attack surface across cloud, AI, SaaS, and on-prem, then checks whether exposures are actually exploitable: vulnerabilities, misconfigurations, default credentials, exposed secrets. The Wiz Red Agent goes further and uses AI to look for flaws that signature-based scanners tend to miss, like authentication bypasses, business logic errors, and multi-step attack chains.

So enrichment is available now, and correlation is on the way. Neither is trivial. Wiring Mandiant and VirusTotal data into cloud findings takes a vendor that owns both the intelligence and the platform, and Google now does.

 

Two products, still

We see a lot of confusion about this.

Google closed the Wiz acquisition on March 11, 2026. At the time it said the Wiz brand would stay, and that Wiz would keep supporting AWS, Azure, and Oracle Cloud (Google Cloud, March 11, 2026).

The GTI integration was planned before that. In November 2025, Wiz was one of the first three partners in the Google Unified Security Recommended program, along with CrowdStrike and Fortinet, and the GTI integration was already on its roadmap. Google described the program as "founded on the belief that security ecosystems must be open and interoperable, empowering customers with choice" (Wiz, November 13, 2025).

The order of events explains what shipped. This was designed as a partner integration months before the deal closed, and it launched that way. The July announcement even carries two bylines, one from GTI product management and one from Wiz product management.

In practical terms, Wiz is consuming a Google intelligence feed. Wiz hasn't become GTI, and GTI hasn't picked up cloud posture management. They're still separate products that do different jobs and come with separate contracts.

This matters most at budget time. We've already talked to buyers who assumed Wiz now includes threat intelligence, and others who assumed a GTI subscription now covers cloud posture. Neither assumption is correct. The enrichment is useful, but it doesn't let you drop a product from your stack.

 

What changes day to day

Cloud security teams already have plenty of findings. What they're short on is a solid reason to work one before another. With enrichment, part of that reasoning shows up on the finding itself, so the team doesn't have to reconstruct it later.

GTI rates vulnerability risk as low, medium, high, critical, or unrated. Unrated means Google assessed the vulnerability but couldn't settle on a rating (
Google Cloud documentation). We like that Google admits when it doesn't know. It's also a reminder that a rating feeds a decision. Someone still has to make the decision.

 

Where the permissions split

Enriched findings are only worth something if a downstream process acts on them. That process already exists in Google SecOps, and its configuration shows how these tools are meant to be governed.

Google SecOps has one marketplace integration for Wiz and a separate one for Google Threat Intelligence, each with its own credentials and configuration (
Google SecOps documentation). If you still wondered whether these are one product, that settles it.

Google groups the Wiz integration's actions into read operations and write operations, and each action needs specific API scopes.

 

Read and query operations

Operation Required scopes
Test Connectivity read:issues
Get Issue Details read:issues, read:posture_issues, read:threat_issues, read:comments
List Resource Vulnerability Findings read:vulnerabilities
Get Blue Agent Analysis read:threat_issues

 

Write and modify operations

Operation Required scopes
Reopen Issue write:issue_status, update:posture_issue_status, write:threat_issue_status
Resolve Issue write:threat_issue_status, write:threat_issues
Ignore Issue update:posture_issue_ignore, write:issue_ignore
Add Comment To Issue write:issue_comments, write:threat_issue_comments, write:comments

 

Google also notes that if your security policy doesn't require granular scoping, an admin can grant read:all, write:all, and update:all and cover everything above. That's a reasonable option to document. Some teams need the integration running on day one and will tighten it later.

We always scope granularly, and write:all is the grant we'd most like people to avoid. It's the fastest way through a deployment call, and it gives your automation authority that no one consciously decided to give it. If your Wiz integration has write:all today, nothing technical separates an agent that investigates from an agent that makes changes.

 

The read path changes nothing. The write path changes someone else's environment. A named practitioner sits on the boundary.

The read path changes nothing. The write path changes someone else's environment. A named practitioner sits on the boundary.


Separating the two is straightforward. An automated investigation pipeline gets the read scopes and can move as fast as it likes: pull issue details, list vulnerabilities on the affected resource, fetch Wiz's Blue Agent analysis, correlate against GTI. None of that changes anything in the customer's tenant.

The write scopes do change things. Resolving, ignoring, or reopening an issue alters state in someone else's environment, so at Foresite those actions sit behind a named practitioner. Google and Wiz provided the controls. Our part is applying them consistently on every tenant.

That gets more important as Wiz's agents take on more work. There are three, and they're easy to mix up:

  • Red Agent (generally available) reasons through business logic to find exploitable flaws that scanners miss.

  • Blue Agent speeds up investigation by gathering the context an analyst needs.

  • Green Agent analyzes an issue and applies fixes. Its Remediation and Response capability, now in public preview, runs tailored actions inside the customer's cloud environment.

Green is why the write scopes deserve careful attention. An agent that remediates inside a customer's environment should be approved by a person, not covered by a blanket grant. David Grable argued in April that autonomy without an audit trail is a liability. The scope table above is where that argument turns into actual configuration.

 

Closure reasons are audit data

There's one more useful detail in the same documentation. Ignore and Resolve aren't interchangeable:

  • Ignore applies only to Graph Control and Cloud Configuration issues. Reasons: False Positive, Exception, Won't Fix.

  • Resolve applies only to Threat Detection issues. Reasons: Malicious Threat, Not Malicious Threat, Security Test Threat, Planned Action Threat, Inconclusive Threat.

If nobody sets rules for these, each analyst settles on a favorite reason and your closure data stops meaning anything within a quarter or so. If the rules are enforced, that field becomes an audit trail. It shows what you dismissed and why, and whether the pattern would hold up in front of a regulator.

It's tedious work, and it's much of the difference between owning a tool and running a security program.

 

How Foresite runs this

Google and Wiz build the intelligence and the platform. Running them in a live environment, with real compliance obligations and real change windows, takes different skills. That's the work we do, and inside our Catalyst platform it falls into five areas:

  1. Cloud security posture and exposure. Discovery across cloud, identity, workload, and data using Security Command Center and Wiz. The Security Graph connects individual findings into attack paths.

  2. Platform operations. Certified engineers run your Google SecOps platform. This is where the SOAR integration and its scopes live, so the read/write split is a configuration we own for you on every tenant.

  3. Threat operations. GTI and Mandiant produce more intelligence than most teams can act on. We turn it into correlation, risk scoring, detection content, and hunting priorities on a regular schedule.

  4. Managed detection and response. A prioritized exposure becomes an investigation with an owner, a timeline, and a decision.

  5. AI workload protection. GTI's malicious AI Skill intelligence matters most here, as agents start importing open-source skills into production.

What ties these together can't come from a vendor. Enrichment can tell you a vulnerability is being exploited in the wild. It can't tell you whether the affected workload is in scope for your cardholder data environment, whether the owning team has a change window this week, or whether the fix breaks a dependency. Only people who know your environment can answer those.

 

What to do now

  1. Look at what you already have. If you use Wiz, check what GTI context is attached to your findings now. Some findings you triaged last quarter may look different.

  2. Audit your service account scopes. If your Wiz integration has write:all, split read from write before you add more automation.

  3. Decide who owns enriched findings. If Wiz output goes to cloud engineering and GTI context goes to a threat intel team that meets once a week, nobody acts on the enrichment. Send both to a single queue owned by someone who can act.

  4. Don't consolidate based on assumptions. GTI in Wiz isn't a reason to cut either contract. Get what your entitlement covers in writing before renewal.

 

What comes next

Google has said the bigger pieces are still to come: exposure data flowing into the GTI correlation engine, plus guidance on how attackers typically behave after exploiting a specific vulnerability, down to host commands and malware. Once that ships, enrichment can trigger playbooks automatically instead of serving only as background.

Google's July post opens by noting that AI is speeding up vulnerability discovery and exploitation for attackers and defenders alike. Teams that haven't decided in advance who can approve what will feel that first. Faster signals flowing into a process nobody owns just grow the backlog faster.

Not sure how your Wiz integration is scoped? If Google SecOps connects to Wiz in your environment, those scopes are already set, whether or not anyone chose them deliberately. A Foresite practitioner can go through your configuration with you and show exactly what your automation is allowed to do in your tenant.

Talk to a cloud security specialist →



FAQ

Is Google Threat Intelligence now included in Wiz?

Partly. GTI enrichment of Wiz findings went live in August 2026. According to Google, the deeper integration between Wiz Attack Surface Management and the GTI correlation engine is still being built. Check with your Wiz representative which capabilities your entitlement includes, and don't assume full GTI coverage.

 

Did Google merge Wiz and Google Threat Intelligence into one product?

No. Google finished acquiring Wiz in March 2026 and said it would keep the Wiz brand and continue supporting AWS, Azure, and Oracle Cloud. GTI enrichment in the Wiz console means one product is using another's intelligence feed. They're licensed separately and do different jobs: Wiz covers cloud exposure, and GTI covers adversary intelligence.

 

What is a GTI Risk Rating?

GTI gives vulnerabilities a rating of low, medium, high, critical, or unrated. Unrated means Google assessed the vulnerability but couldn't assign a rating. The rating reflects Google's view of real-world risk, not raw CVSS severity. Use it as one input to prioritization alongside what you know about your own environment.

 

How does Foresite run Wiz and Google Threat Intelligence together?

We run cloud posture and exposure management on Security Command Center and Wiz, and platform operations on Google SecOps, which is where the integration scopes are managed. Our threat operations team turns GTI and Mandiant intelligence into detection content, and our MDR team runs investigations. A named practitioner approves any action that changes state in a customer environment.

 

What permissions does the Wiz integration for Google SecOps need?

Read actions need read:issues, read:posture_issues, read:threat_issues, read:comments, and read:vulnerabilities. Write actions need various combinations of write:issue_status, update:posture_issue_status, write:threat_issue_status, write:threat_issues, update:posture_issue_ignore, write:issue_ignore, write:issue_comments, write:threat_issue_comments, and write:comments (see the tables above for each action). Google lets you grant read:all, write:all, and update:all instead, but we recommend against it. Keeping read and write separate lets automated investigation run quickly while a person approves anything that changes state.

avatar
Stephen Muller
Stephen Muller is a Senior Customer Engineer at Foresite Cybersecurity, a Google Cloud Premier Partner and the 2026 Google Cloud Security Partner of the Year. He works hands-on with customer deployments of Google SecOps and Wiz, including the integration scoping and SOAR configuration described in this post.

RELATED ARTICLES