Customer Story: Te Herenga Waka–Victoria University of Wellington

With Push, the Victoria University of Wellington (VUW) security team found a tool to govern AI usage across a diverse workforce, while also solving its phishing problem at the same time.

About Victoria University of Wellington

Victoria University of Wellington is a public research-intensive university in Wellington, New Zealand, with approximately 3,000 staff and faculty. A five-person security team manages a Microsoft-heavy environment with significant on-premises infrastructure and an in-house SOC with on-call coverage. Like most universities, VUW has to balance security with academic freedom. Blocking access to tools is a non-starter, so the team needed controls that could guide behavior without restricting it.

Why Victoria University of Wellington chose Push:

Existing tools offered binary choices — block or allow — but the university needed more granular guardrails that could surface policy when a tool is used without preventing access to AI or other applications.
Browser-based phishing was impacting up to 5 staff per month, and the team had no visibility into what was actually happening inside the browser session during an attack.
Both problems pointed to the same gap: Nothing in the stack could see or act inside the browser.
Push deployed to approximately 3,000 managed devices via group policy with no end-user problems and no service disruption.

Users protected by Push

phishing attacks blocked per month

The value of Push has been its ability to connect policy, education, and security into a single control — raising awareness across the university while demonstrably strengthening our prevention-first cyber approach.

Leanne Gibson

CIO, Victoria University of Wellington

Business Challenge

Two problems, one blind spot

University security teams face a constraint most enterprise security leaders don't: You can't block your way to safety.

Restricting access to a tool, even one with genuine risk, runs into a culture of academic freedom and researcher autonomy that shapes every security decision. That tension has always existed, but the combination of rapidly evolving browser-based attacks and an explosion of new AI tools has made it significantly harder to manage.

With the landscape shifting on a daily basis, VUW's security team needed to keep faculty and staff working securely without resorting to being overly restrictive.

The symptoms of these challenges were obvious to VUW’s five-person security team, led by cybersecurity manager Stephen Shkardoon.

They had identified two core security problems they needed to solve that at first seemed unrelated.

The first was browser-based phishing. As many as five staff members a month were being impacted by phishing, most apparently through email. But the actual chain of events was largely invisible. The team could see that someone had been compromised, but they couldn't see how.

"They'd get infected with malware," Stephen explained. "But we had too many infections to worry about root-causing every single one."

Without visibility into what happened inside the browser, attackers arriving through malicious search results, ClickFix-style lures, or transient infrastructure left no trace the team could reach.

The second problem was AI governance.

A cross-functional working group was grappling with how to govern staff use of AI tools. Microsoft Copilot was the sanctioned option. ChatGPT and others occupied a grey area. The university developed a policy, but as Stephen put it, "a published policy is not the same thing as people actually doing that."

What the working group needed was a mechanism to surface the university’s AI policy at the exact moment someone was about to act against it, without blocking the tool.

Stephen saw the connection. Both problems pointed to the same architectural gap: Nothing in the team’s existing stack could see or act inside the browser session. The phishing problem needed browser-layer visibility. The AI governance problem needed browser-layer controls.

The same tool could solve both — if it existed.

So much phishing protection is just trying to train your users to be experts. I really don't like it.

Victoria University of Wellington

Technical Challenge

The blunt instrument problem

VUW's large existing security stack, which includes Microsoft Defender and firewall-based IP blocking, offered binary options: block or allow. That worked for malware. It didn't work for AI governance at a university.

Moreover, the AI working group wasn't asking to block everything. They needed a way to present a policy at the exact moment it mattered, then let the user get on with their day.

"We didn't see a tool in our existing toolbox that would let us do that really soft guidance," Stephen said. He envisioned something like a full-screen warning that describes the policy, links to it, and lets the user click accept and continue.

The phishing picture had a similar gap. The team could see email-delivered threats through existing tools, but the browser session itself was a blind spot. Attacks arriving through malicious search results or ClickFix-style lures, which use transient infrastructure that disappears before it can be attributed, weren’t getting logged in any of their existing security tools. The compromises were happening, but the team couldn't see the attack chain.

When Stephen discovered Push, he immediately recognized that he could solve both problems with one solution — protecting against modern browser-based attacks and helping to educate and enforce the university’s AI policies.

We have our firewalls which can block access to particular IP addresses, we have Defender which can block access to websites, but that’s really all they could do.

Victoria University of Wellington

Solution

A simple, silent deployment

The security team piloted Push first with the AI working group to help prove out the business case internally.

After the successful pilot, broader deployment to approximately 3,000 managed devices via group policy was simple.

"We had literally no one even comment on it initially," Stephen said. "That was exactly what we were going for."

The team next implemented Push’s detection and response controls, starting in warn mode first, watching before blocking. A month in, with zero false positives, they switched to blocking with high confidence.

"Every single detection had been legitimate," Stephen said. "We just switched it over to blocking. Without any fuss, without any hassle."

Browser-layer policy guardrails went live across AI tools, plagiarism-checking services, and consumer file storage — surfacing university policy at the point of access. The AI working group now had granular telemetry on which tools staff were actually using and in what volumes in a level detail that existing logging tools couldn’t provide. Policy conversations that had previously relied on assumptions now had data behind them.

The phishing problem, solved

Since implementing Push a year ago, browser-based phishing has gone from a monthly remediation task to a blocked-and-logged event.

When a SharePoint-themed AiTM campaign began circulating across the higher education sector, appearing to originate from trusted contacts and harvesting credentials and MFA tokens in real time, VUW's staff weren't affected. Push had already intercepted the attacks.

The visibility shift was just as significant as the prevention. Where the team previously had to guess at root causes, Push now surfaces the full attack chain: the initial lure, the page the user was served, and exactly where the detection fired. Stephen regularly uses Push's screenshot capability to show non-security stakeholders the actual phishing page a user encountered and the point at which Push intervened. This evidence resonates for the team far more than a log entry.

"The information we're getting from Push tells us: These people were clicking the links. They were going to interact with it, but Push had already served them the block page," Stephen said. "Before, if we reported the number of phishing emails Microsoft blocked, it's thousands — who knows, tens of thousands. But that doesn't tell us who would have fallen for it. Push does."

The information we're getting from Push tells us: These people were clicking the links. They were going to interact with it, but Push had already served them the block page.

Victoria University of Wellington

More than the sum of its parts

Once Push was in the browser, VUW's security team found it solved problems they'd been working around for years.

Stolen credential detection was one example. When staff credentials surfaced in a breach dataset, the previous response was a mass email to potentially affected users suggesting they might want to consider changing their password. But the team worried that these messages were easy to ignore because the risk felt abstract.

Push replaced that blanket notification with real-time detection at the point of login, cross-referenced against breach data, so the team now sends a targeted automated email only when a specific user actually logs in with a compromised credential.

"That actually fully solves a problem I didn't realize was going to be solved," Stephen said.

The team also found that browser-layer telemetry from managed staff devices could inform network-level blocking decisions for their student population. When Push identifies a targeted phishing domain hitting staff, the team pushes that intelligence to their firewall. This protects students on the same network without the extension deployed to their devices.

Push also feeds into VUW's SOC stack via Sentinel and FortiSOAR, integrating browser-layer telemetry into the same automated workflows the team uses for every other alert category.

A different security conversation

Stephen now describes browser-based attacks as a solved problem for VUW.

"When I talk about where we should be focusing our security energy now, browser-based attacks aren't the area anymore,” he said.

For a security team of five managing 3,000 users with an in-house SOC and limited budget, that shift in focus is the outcome that matters most. The team isn't spending hours per month on phishing remediation. The AI working group has real data instead of assumptions. And the security program can direct its energy to the problems that haven't been solved yet.

"I can't think of a tool that has been more cost-effective and time-saving than Push," Stephen said.

Explore more customer stories