When an AI model capable of finding zero-day vulnerabilities at machine speed gets accessed without authorization, the incident response has to match the threat profile. Anthropic’s handling of the Mythos breach is a useful case study of where disclosure practices for security breaches still need to catch up.

Anthropic built Claude Mythos Preview as something it explicitly said the world wasn’t ready for. 

The model finds zero-day vulnerabilities at machine speed, demonstrated the ability to escape its own sandbox, and in at least one test, posted details of its own exploit to public websites without being asked. 

We’ve already covered how Anthropic’s response was to keep it locked behind Project Glasswing – a tightly controlled initiative limited to a handful of vetted partners: AWS, Microsoft, Cisco, major banks, and critical infrastructure operators.

But exactly that is what makes what happened instructive.

Reports emerged this week that an unauthorized group accessed Mythos Preview through a third-party vendor environment connected to the rollout.

The group – part of a private Discord community that tracks unreleased AI models gained access on the same day Anthropic announced the model.

This mechanism of access is worth sitting with. 

Supply chain security is no longer a background concern for procurement teams. It is a front-line risk for anyone deploying AI in environments that touch source code, internal systems, or critical infrastructure. 

Financial services are entering a new phase, one where AI doesn’t just analyze data, but securely interacts with regulated financial infrastructure in real time.  

At Infinum, we are fully aware of the challenges and considerations involved in connecting a ChatGPT App to live banking data. Using Model Context Protocol (MCP) and PSD2 open banking APIs, we have enabled users to authenticate once and then query balances, transactions, and spending summaries in a conversational manner, all without leaving ChatGPT. 

This post will walk you through the architecture, how authorization works, and how users can retrieve live banking data directly inside Chat GPT. We’re also going to talk about the design decisions and limitations that came up when building it. 

A Glance at the Architecture 

The ChatGPT App configuration is deliberately minimal: a public MCP server URL and an OAuth enabled flag. Everything else, auth logic, access control, data scoping, lives server-side in the MCP layer. That separation is a feature, not an oversight, and it shapes how we handle authentication and permissions. 

OAuth and PSD2 Scopes

This layer is critical for protecting access to sensitive financial data. To achieve this, we use OAuth 2.1, the industry standard authorization protocol. Once the user successfully authenticates and grants explicit consent, the provider issues a secure access token. This token allows our system to retrieve only the permitted banking data (such as balances or transactions) through the provider’s APIs. 

When initiating the OAuth flow, we explicitly declare which PSD2 permission scopes the token should cover. Depending on the action the user want to make In our implementation, we request only three: 

Narrower scopes mean a cleaner consent screen and a smaller blast radius if a token is compromised. This maps directly to the principle of least privilege: request only what the feature actually needs. 

90-day re-authentication (PSD2 requirement) 

PSD2 mandates re-authentication every 90 days. Our implementation satisfies this by design: tokens are short-lived and tied to individual sessions. Users re-authenticate each time they start a new session, which in practice happens far more frequently than every 90 days. No special tracking or forced re-auth flow is needed. 

What happens when a user withholds a scope? Currently, the initial token grants all three read scopes together. We don’t issue per-resource tokens. If a scope is not granted, we simply don’t return that data. We don’t surface an error or attempt to call the API without permission. 

Taken together, this approach mirrors the security model used by many mobile banking and FinTech applications, where OAuth based authorization ensures that access is controlled, permission-based, and revocable at any time. 

But once a user is authenticated, how does ChatGPT know which banking actions it can perform on their behalf? 

That’s where the MCP server comes into play. 

MCP Server: Tool Definitions as the Security Boundary

This is where access control lives. Every capability the model has is an explicitly defined tool. There is no freeform API access, if a tool for initiating payments doesn’t exist, the model has no mechanism to trigger one. The tool definitions are the boundary. 

We’ve specified a list of actions and what each action does: 

The Auth Check Gate

The `auth-check` tool acts as a gate for all other tools. Before any data-fetching action is invoked, the model is instructed to first verify that the user has an active, valid session. This dependency is structural: in the tool descriptions themselves, we explicitly specify that balance, transaction, and account tools should not be called unless the auth-check has returned a confirmed authenticated state. The model cannot bypass this because it has no alternative path to the data.

The Audit Trail

Every tool invocation is logged at the MCP server level, producing a structured audit trail.  

Each log entry captures: 

This gives us a complete operational record for debugging and figuring out if the model is calling the right tools. 

The UI Components

UI components are served through the MCP layer and have no independent access to provider APIs. UI components are served through the MCP layer and have no independent access to provider APIs. When a component needs user-specific data (a balance card, a transaction list), it receives a pre-fetched payload passed through the tool response that triggered it. The JWT token and granted scopes are held server-side and never forwarded to the component directly. The component renders only what the MCP server explicitly provides.  

The entire implementation is based on the new Apps SDK.

A note on Infobip’s model

The same MCP pattern applies to Infobip’s communication infrastructure, SMS, WhatsApp, RCS, Voice, Viber, 2FA. Each channel is exposed as a dedicated MCP tool with its own scope and constraints. The enforcement mechanism is identical: tools as the boundary, least-privilege by design. 

Provider Agnosticism

One decision worth calling out explicitly: the architecture is Open Banking provider-agnostic.  

Without an Open Banking API provider the system cannot function. The whole idea is dependent on the providers. All banking information is provided by them, so we need to connect with such a provider and extract the information in a secure way. 

The MCP server communicates with the provider through a standardized PSD2 interface, which means the underlying provider can be swapped without changes to the MCP layer or the ChatGPT App. 

In practice, providers vary in how faithfully they implement the PSD2 spec, so some adaptation at the integration layer is expected. But the core architecture has no single-provider dependency baked in. 

Dynamic Client Registration (DCR) 

Since we integrate through a single Open Banking API provider rather than directly with individual bank authorization servers, DCR is handled at the provider level. It’s not something our architecture needs to address directly. 

LLM Limitations Worth Knowing 

With the architecture in place, there are a few model-level constraints that affect how far the current implementation can stretch. 

Rapidly changing financial data (exchange rates, stock prices)  

The model doesn’t have live financial context by default. The correct approach is a dedicated MCP tool that fetches current data before any function that needs it. We haven’t implemented this yet, but the pattern is straightforward: add a get-market-context tool and instruct the model to call it first. 

Local regulation and terminology outside the training set 

For the use cases this app targets — consumer-facing, non-specialist — the base model’s training data has been sufficient. For regulated or jurisdiction-specific deployments, a RAG layer or a context-injection tool would be the right extension point. 

Keeping Financial Data Out of the LLM Context 

Beyond model limitations, there’s a broader question about data handling that’s directly relevant to PSD2 compliance. 

We control what we can on our side: MCP tools return lean, structured payloads (not raw API objects), and no financial data is stored server-side beyond the lifetime of the request. What happens inside OpenAI’s platform is governed by their data policies, and those policies vary by account type. 

For any financial use case operating under PSD2, users should access the app through a ChatGPT Team or Enterprise account, or at minimum disable training in their data controls settings. 

The End-Result: Conversational Open Banking 

Once a user connects their bank account through the OAuth flow, they can interact with their financial data conversationally inside ChatGPT. 

Instead of opening a banking app and navigating through menus, the user can ask: 

The experience feels like messaging a financial assistant who already understands your question and knows where to look. Behind the scenes, everything remains secure and permission-based, but from the user’s perspective, it’s effortless. 

This article was originally published on the Infobip Developer Blog. Learn more about Infinum and Infobip’s integration partnership.

Anthropic just launched Project Glasswing – a major initiative to hunt vulnerabilities in critical open-source software using its most capable AI model. The implications for defenders and attackers alike are significant, and most organisations are not ready for either.

On 7 April 2026, Anthropic launched Project Glasswing – a coordinated effort to give key technology providers early access to Claude Mythos Preview with one goal: find and fix long-hidden vulnerabilities in critical open-source software before attackers do.

It is the clearest signal yet that frontier AI has crossed a threshold. It is no longer just a productivity tool bolted onto existing security workflows.

That is worth taking seriously. Not because of the marketing, but because credible institutions are paying attention.

The AI Security Institute and the UK National Cyber Security Centre have both documented measurable progress in AI agents completing multi-step cyber attack scenarios. The NCSC has called on defenders to prepare for a world in which frontier AI amplifies attacker capabilities at pace.

Glasswing is a concrete attempt to tilt that balance back toward defence. The early findings suggest it is working.

The two-sided ledger of AI-assisted security

For most of computing history, finding and exploiting software vulnerabilities required rare expertise.

The people who could do it reliably numbered in the thousands globally. That constraint mattered – it was a practical limit on how fast attackers could operate and how broadly they could target. 

Over the past year, that constraint has eroded sharply. 

AI models have become increasingly effective at reading and reasoning about code, showing a particular ability to spot vulnerabilities and work out how to exploit them. The cost, effort, and level of expertise required have all dropped dramatically.

Claude Mythos Preview, Anthropic’s unreleased frontier model behind Glasswing, has reached a level of coding capability where it can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.

That is not a marketing claim – it is the assessment Anthropic has published alongside the initiative. The AISI’s evaluation of Claude Mythos Preview’s cyber capabilities tracks the same capability curve and reaches similar conclusions.

And it is not only expert hands that can wield it.

An AI that can read a codebase, reason about execution paths, and identify edge cases in authentication logic can do that work for a defender running a bug bounty programme or for an attacker building an exploit chain. The model does not care which side of the firewall it is on. And given the rate of AI progress, these capabilities will not remain confined to actors committed to deploying them safely.

The question for security teams is not whether to engage with this shift. It is – how fast.

What Glasswing tells us about where this is heading

Anthropic’s approach with Glasswing is instructive beyond the specific initiative. A few things stand out.

The focus on open-source infrastructure is deliberate

Open-source software underpins almost every critical system in operation today – cloud platforms, financial infrastructure, healthcare systems, industrial controls.

Vulnerabilities in widely used libraries do not stay contained. When one surfaces, the blast radius is enormous and the window between disclosure and exploitation has compressed to hours in many cases. 

The Axios npm supply chain attack in March 2026 – where two malicious versions of one of JavaScript’s most-used libraries were quietly published – is a recent example of exactly how fast that window closes.

The results are concrete 

Mythos Preview has already found thousands of zero-day vulnerabilities –  flaws previously unknown even to the software’s own developers – including some in every major operating system and web browser.

Some of the specific findings illustrate just how significant the capability leap is:

The gap between Mythos Preview and the previous generation of models is also stark.

When tested against known vulnerabilities in Mozilla’s Firefox JavaScript engine, the previous best model – Claude Opus 4.6 – turned those vulnerabilities into working exploits twice out of several hundred attempts. Mythos Preview did it 181 times.

These are not theoretical weaknesses. They are exploitable flaws that survived decades of human review and millions of automated tests. The model found them.

The initiative is coordinated by design 

Early access, structured disclosure, defined scope – Glasswing is built to funnel findings into responsible remediation rather than onto a paste site. 

That framing is worth taking at face value, because the alternative – waiting for these capabilities to proliferate without a coordinated defensive response – is considerably worse.

For organisations watching from the outside, the implication is direct: if a frontier model can find vulnerabilities in your dependencies that survived decades of human review and millions of automated tests, you cannot rely on existing scanning and review processes to give you confidence that your attack surface is clean.

The attacker’s advantage – and how to close it

Defenders have always operated at a structural disadvantage.

The realistic near-term threat is not yet a fully autonomous AI attacker operating without human direction. But it is human attackers using AI to operate faster, at a greater scale, and with less specialised knowledge than was previously required. 

A moderately skilled attacker with access to a capable model can accelerate reconnaissance, generate targeted phishing content, identify patch-gap windows, and synthesise public vulnerability research into working attack chains.

We explored a version of this problem in our analysis of security gaps in vibe-coded applications.

AI-generated code introduces vulnerabilities not because the model is careless but because it optimises for functional correctness, not security depth. An attacker using the same models to probe those applications has a natural advantage over a developer who did not think adversarially when prompting.

The answer is not to avoid AI in development.

It is to apply deliberate security discipline at every stage – including to the AI-generated output itself. That means combining automated scanning with human-led testing rather than assuming one replaces the other.

What organisations should do before the surge hits

Glasswing is likely to accelerate vulnerability disclosures across the open-source ecosystem. Organisations that are unprepared for a sudden increase in security advisories affecting their dependencies will struggle to respond at pace.

Martin Walsham, Director of Cybersecurity at AMR Cybersecurity – Part of Infinum, has been tracking this shift closely: “Frontier AI models are progressing at pace, and the same technologies that defenders can use to increase overall security posture can equally be used by attackers to amplify their capabilities. This heightens the need for organisations to implement strong security baselines, defence in depth, and robust secure code, and to patch at pace to make them less susceptible to attacks.”

The precautionary steps below are not dramatic departures from good security hygiene. They are the foundations that make rapid response possible when it is needed.

Review and test your incident response plan now. 

Not the version that was written two years ago and has not been touched since. Run a tabletop exercise against a realistic scenario – a critical CVE in a dependency you cannot patch immediately, combined with active exploitation attempts.

Prepare for increased advisory volume. 

If AI-assisted vulnerability research delivers on its promise, the rate of disclosures in widely used open-source libraries will increase. Security and engineering teams need the capacity to triage and prioritise that volume without dropping everything else. Build that capacity before the surge, not during it.

Get your asset management list accurate. 

You cannot patch what you do not know you are running. This is the most consistent gap we see in organisations that have otherwise mature security programmes. A dependency buried four levels deep in your supply chain is still your problem when a CVE drops against it. Our step-by-step software supply chain security framework covers how to map and manage that exposure systematically.

Monitor updates and advisories actively. 

Subscribe to feeds for the libraries and platforms you depend on. Automated dependency scanning tools have improved significantly – if you are not running one, start.

Review third-party agreements with critical suppliers. 

If a vulnerability surfaces in a service you depend on and your contract does not specify patching SLAs, you have no lever to apply. Review those agreements and open conversations with suppliers about their response posture before you need to have that conversation under pressure.

Test your external perimeter. 

If your last penetration test was more than twelve months ago, you do not have an accurate picture of your exposure. This is especially true for organisations that have made infrastructure changes, onboarded new services, or shipped significant product updates since the last test.

Have a plan for enhanced monitoring at short notice. 

Not all threats give you advance warning. Know what elevated monitoring looks like for your environment and how quickly you can activate it.

Security baselines matter more, not less

There is a temptation to frame AI-powered threats as something categorically new that requires a categorically new response. 

In some respects, that is true – the speed and scale at which AI-assisted attacks can operate does change the calculus. But the vulnerabilities being exploited are mostly the same ones that have always existed: missing input validation, broken access control, insecure defaults, and unpatched dependencies. 

Our cybersecurity trends outlook for 2026 covers how AI-driven attacks, stricter compliance requirements, and supply chain exposure are converging into a single pressure point for security teams.

The NIS2 and DORA frameworks that came into force across the EU reflect this same reality. The technical requirements they mandate – multi-factor authentication, incident reporting, supply chain risk management, regular penetration testing – are not responses to AI-powered threats specifically. They are the baseline hygiene that makes an organisation resilient regardless of what the attacker is using. 

If your organisation is not meeting that baseline, the sophistication of the threat is almost beside the point.

Strong foundations beat reactive firefighting

Project Glasswing is a meaningful development in the responsible use of frontier AI for defence.

The AISI and NCSC assessments confirm what security practitioners have been observing in practice: capability is advancing faster than most organisations have adjusted for.

The right response is not to wait and see how the landscape settles. It is to invest in the defences that reduce exposure across the board – sound architecture, secure development practices, regular testing, and the operational readiness to respond when something goes wrong.

Infinum’s penetration testing and cybersecurity services are built around exactly that kind of proactive posture. If you want to understand your current exposure before the next wave of disclosures hits, talk to our security team.

Most GRC programs fail not because the framework is wrong, but because it’s built to satisfy auditors, not protect businesses. Here’s what that costs you – and how to do it differently.

Most organisations have some version of GRC in place. Policies exist. Compliance boxes get ticked. A risk register lives somewhere in a shared drive, last updated before anyone currently on the team joined. And then a breach happens, or an audit goes badly, and everyone is surprised.

They shouldn’t be.

The most common GRC failure isn’t ignorance of the framework – it’s treating it as an administrative exercise rather than a decision-making system. You end up with documentation that describes security rather than delivers it.

That distinction matters more than most security conversations acknowledge.

Why GRC exists – and why it usually gets implemented wrong

GRC – governance, risk, and compliance – is a system for making security decisions that support a business rather than obstruct it. Not rules imposed from above, but a framework built around what the organisation is actually trying to achieve.

GRC connects governance, risk, and compliance into a single decision-making system. Here’s what each pillar means, how they interact, and how businesses apply them in practice.

Most organizations already manage governance, risk, and compliance in some form – they just do it in separate silos, with different teams, different tools, and no shared language. GRC formalizes that into a single, connected system.

When governance, risk, and compliance operate independently, decisions get made without context.

An IT team patches vulnerabilities without knowing which ones actually threaten business-critical systems. A compliance team checks boxes without understanding the underlying risk. Leadership approves budgets without visibility into what they’re actually protecting.

GRC fixes that – not by adding process overhead, but by aligning security decisions with business goals.

And in an environment where the regulatory landscape keeps expanding, the number of threat vectors keeps growing, and senior leadership is increasingly held personally accountable for security failures, that alignment is no longer optional.

Many organizations now want full ownership of their AI infrastructure. The motivation for self-hosting ranges from data ownership requirements and contractual obligations to maintaining the highest level of system security.

This post covers the infrastructure decisions, model selection tradeoffs, and performance optimization techniques we encountered while building a self-hosted multi-model inference stack. Security architecture and model licensing are out of scope here as both deserve their own deep dives. Still, everything about building the infrastructure and making it perform is fair game.

Here’s what our stack looked like:

vLLM as an inference engine

There are several open-source inference engines to choose from, including LMDeploy, SGLang, and TensorRT-LLM.

We chose vLLM for its performance, broad model support, extensive documentation, and built-in multi-model type routing.

Their production stack ships with an infrastructure diagram you can extend for your own setup, but the core components are:

Simplified end-to-end flow

The request router analyzes the incoming prompt’s prefix and directs it to a worker that already holds that context in memory. The worker processes the request with optimized block-based memory management, pulling previously computed states from a per-node or cluster-wide cache, and generates the response.

Choosing the right hosting environment

The AI hosting landscape is competitive. The vLLM production stack has cloud deployment support for AWS, Azure, and GCP, and project velocity matters a lot at this stage.

This is why we chose AWS EKS. The cost savings from alternative providers did not justify the increased setup complexity.

Specialty cloud hosting providers are cheaper, but they often offer unmanaged environments. That means you handle all the heavy lifting yourself, like networking, orchestration, GPU scheduling, the lot.

On-premise considerations

Buying hardware immediately is an operational risk. This is true even if you have predictable workloads.

We recommend a phased approach:

Choosing the right model

To simplify the equation: the two factors that drive infrastructure cost are model size (parameter count) and model context (the active memory window containing your conversation and retrieved data).

The LLM is your main challenge. Embedding and reranking models require comparatively little GPU power.

Here are three scenarios to illustrate the range. Note that these are rough on-demand estimates, and be sure to check current pricing and consider reserved or spot instances where applicable.

Small: chatbot with basic interactions

Customer support, simple Q&A. No complex reasoning or large context required.

Medium: reasoning over a knowledge base

Internal knowledge bases where the model reads retrieved company documents, follows strict instructions, and needs to minimize hallucinations.

Large: high accuracy, high reasoning, high context

Complex code refactoring, massive document analysis, predictions, and advanced agents. Maximum accuracy and minimal hallucinations are non-negotiable.

These are rough single-environment estimates. Multi-environment, highly available enterprise setups multiply these figures quickly.

Benchmarking your setup

Although there are fast general benchmarking tools available, like LLMfit, you should measure model performance in your own environment. This also reveals hardware traps that generic benchmarks won’t surface.

For example, adding more L40S GPUs may not increase performance. These GPUs communicate over the PCIe bus instead of NVLink, and the communication overhead can cancel out the compute gains.

vLLM has a native benchmarking option via the bench serve command. The key metrics to watch:

Optimization techniques

There is extensive documentation on optimization techniques. Here’s a summary of those that made the biggest difference for us.

Quantization

Reduces weight precision (e.g., from 16-bit to 8-bit or 4-bit) to shrink the model’s memory footprint. This has a direct impact on what model you can fit on your available hardware.

Automatic prefix caching

Worker/Node level memory management. Caches the KV state of existing queries. If you’re querying the same long document multiple times, the document is processed once and subsequent queries pull from cache. The result is higher throughput and lower latency.

Distributed caching via LMCache

Automatic prefix caching is limited to a single worker’s GPU VRAM — extremely fast, but expensive. LMCache enables cluster-wide offloading to cheaper storage (CPU memory, disk, or Redis) at the cost of some latency. Use both in a tiered memory hierarchy for the best balance.

Tensor parallelism

Workload distribution. Splits tensors across multiple GPUs. Effectively a requirement for larger models. Performance depends heavily on fast interconnects like NVLink.

Speculative decoding

There are multiple methods. One approach pairs a large model with a tiny, fast model. The fast model guesses the next tokens, and the large model verifies them in a single pass. This multiplies token generation speed.

Disaggregated prefilling

Separates the prefill and decode stages onto different GPUs or nodes. Since the two tasks have different computational profiles (compute-bound vs. memory-bandwidth-bound), you can scale each independently — either to improve responsiveness or to prevent long prompts from stalling active generation.

What’s ahead for self-hosting

There will always be demand for on-premise self-hosted AI in systems that require maximum control over their data.

The barrier to entry is dropping. Inference engines are maturing, optimization techniques are compounding, and models are getting better with fewer parameters and lower VRAM requirements. The recent Gemma 4 release is a good example: judging by the benchmarks, it delivers strong performance for a modest hardware investment. Stay tuned for a deep dive on that one.

In conclusion, enterprise-grade self-hosting remains expensive, but the trajectory is clear: organizations will be able to do significantly more with significantly less hardware.

The phased approach we outlined here is designed to let you start proving value now, without committing to infrastructure you don’t yet understand.

An AI-driven Knowledge Hub is an intelligent system that acts as an organization’s ‘internal GPT’, turning raw, scattered data into actionable insights through a chat interface. We’ve delivered them across industries to solve real business problems for our clients.

The modern enterprise is built on vast amounts of data, yet turning that data into actionable insights remains one of the most persistent and costly challenges organizations face. 

At Infinum, we’ve worked with clients across industries to bridge this gap by developing AI-powered Knowledge Hubs: centralized, intelligent repositories that aggregate and analyze your organization’s data and surface new insights through a seamless chat interface. Think of them as an internal GPT — one that knows your business, speaks your language, and has access to everything your teams need to make faster, more confident decisions.

From streamlining complex workflows for insurance firms to centralizing intelligence for global tech companies and premier fitness networks, these knowledge hubs are the connective tissue between big data and better decision-making. Here are a few examples of the work we’ve done to harness the power of data.

Helping insurance professionals cut through the noise of data

Risk is at the heart of every decision insurance professionals make. Underwriters navigate enormous volumes of data, claims history, actuarial tables, regulatory changes, weather events, market trends, competitor pricing, and their ability to accurately assess and price that risk directly impacts the business. The problem is that this data is rarely in one place, and pulling it together manually is slow, error-prone, and expensive.

We built an insurance intelligence solution that combines data engineering, risk modeling, and competitor and market data to support underwriting and risk assessment decisions. The system gathers claims data, actuarial tables, regulatory filings, and publicly available sources, and makes all of it accessible through a conversational chatbot.

The star feature is source citation. Every recommendation comes with a reference to the underlying data used to generate it. This significantly reduces the risk of AI hallucination, which is especially critical in heavily regulated sectors like insurance, where decisions are subject to strict auditing and compliance requirements.

Streamlining the flow of information for a global tech leader

Decision-makers at global tech companies are bombarded with news from every direction, but most of it isn’t relevant to their business. The real challenge is isolating the specific tech, environmental, and geopolitical shifts that actually impact their operations. For our client, the manual effort required to monitor these risks was leading to delayed reactions and missed opportunities. So we built an internal knowledge hub that turns that flood of global content into focused, actionable intelligence, using advanced data engineering and custom API integrations.

Rather than handing leadership a pile of raw articles, the system distills complex global events into concise daily and weekly briefs, filtered by pre-defined criteria unique to the client’s industry. Every brief that lands is directly relevant to the company’s long-term strategic goals and risk management.

A distinct advantage of this hub is its multi-dimensional filtering logic. By applying pre-defined criteria unique to the client’s industry, the system eliminates ‘noise’ and ensures that every brief delivered is directly relevant to the company’s long-term strategic goals and risk management.

Business intelligence platform for a premium fitness brand

Despite having large volumes of operational and financial data, teams across fitness clubs struggled with hard-to-use systems, missing metrics, and fragmented reporting. This made it difficult to get a clear picture of performance, align teams, and make timely, data-driven decisions.

We designed and built a centralized BI platform that integrates data from across the organization into a single, intuitive interface. By combining robust data modeling with user-centered design, the platform turns complex data into accessible, actionable insights for everyone – from frontline staff to executives.

Turning ‘hidden’ email data into a tool for cost reduction

Procurement teams are often buried under a lot of unstructured data, RFQs, and vendor price lists trapped in email threads and PDF attachments. Without a way to aggregate this data, it is impossible to compare vendor performance, track price volatility, or identify cost-saving opportunities in real-time. Manual data entry is slow, prone to error, and prevents strategic decision-making.

We built a sophisticated procurement automation solution that bridges the gap between raw communication and executive-ready analysis. Using Azure Document Intelligence, the system reads incoming vendor emails and complex attachments, automatically extracting and structuring critical data points. An Automated Extraction Layer then identifies and categorizes that data by vendor, product, and price, storing it in a high-performance structured database. This replaces manual tracking with a real-time repository of market intelligence.

From there, the platform performs deep-dive analyses, including vendor valuation and historical price benchmarking, and surfaces them through custom dashboards for real-time decision-making. Procurement teams walk into negotiations backed by data instead of gut feel, turning what was once hidden in an inbox into a genuine competitive advantage.

The transition from ‘data-rich’ to ‘insight-driven’ is no longer a luxury

As demonstrated across the insurance, tech, consulting, and fitness sectors, the challenge was never a lack of data. The organizations we worked with were sitting on everything they needed. They just couldn’t find it, validate it, or act on it fast enough. An AI-powered Knowledge Hub closes that gap. The right answer stops being buried in a database and becomes one question away. At Infinum, we don’t just build interfaces. We build the cognitive infrastructure that allows your team to stop searching and start leading. If that sounds like something your organization needs, check out what we can do.

Pen testing and red teaming are often used interchangeably. Both probe your defences. Both find what’s broken. But they ask fundamentally different questions, and the one you choose shapes how wide you assess your business security.

Penetration testing and red teaming both start from the same premise: hire someone to break in before the bad guys do. But they’re different tools for different problems, and conflating them is one of the more common mistakes organisations make.

Two approaches, similar goal

Penetration testing is focused.

You define the scope – a specific application, a network segment, a set of systems – and testers use the penetration testing methodology step by step in an attempt to find and exploit vulnerabilities within it.

Most engagements use a gray box approach: testers are given enough context to work efficiently. Credentials, access, scope. Enough to find what matters within a fixed timeframe.

The approach changes depending on who you are – a red team targeting a bank crafts different phishing emails, chooses different attack vectors, and pursues different objectives than one targeting a logistics company.

The whole exercise is shaped by what real threat actors are actually doing to organisations like yours.

Penetration Testing vs Red Teaming: Key Differences

The simplest way to tell them apart: pen testing answers “is this system secure?”, red teaming answers “could a determined attacker get into our organisation?”

Scope is the biggest practical difference. Pen testing is bounded — a specific application, network segment, or set of APIs. The tester works within those limits, finds what’s exploitable, and reports it. Red teaming has no such boundary. The adversary simulation can move across applications, people, and physical premises, using whatever combination of vectors a real attacker would.

The objectives differ, too. Pen testing produces a list of technical vulnerabilities with severity ratings and remediation steps. Red teaming produces something more like a case study: here is how an attacker targeting your organisation could move from initial access to their end goal, and here is what your people, processes, and technology did, or didn’t do to stop them.

Cost and time reflect this. A pen test might run for a week or two. A red team engagement is typically measured in weeks to months, and requires significantly more planning on both sides.

When Do You Need Pen Testing vs Red Teaming?

Pen testing is right for checking specific systems — after a new build, before a release, or as part of a compliance cycle. TIBER-EU and DORA both require it. If you’re running one annually and after major changes, you’re doing the basics right.

Red teaming is for organisations that have already done the basics. You need mature security processes in place first — incident detection, response playbooks, trained staff — otherwise a red team engagement mostly finds that your foundations are weak, which a pen test would have told you for a fraction of the cost. When that foundation is there, red teaming stress-tests the whole picture: not just whether systems are patched, but whether your people, processes, and assumptions hold up under a realistic attack.

The other factor is the threat model. If you handle sensitive data, operate critical infrastructure, or are the kind of target sophisticated threat actors actively pursue, red teaming answers a question pen testing can’t: not “is this system secure?” but “could a determined adversary get into our organisation?”

If you’re not sure which fits, start with a pen test. And if you want to understand what a red team engagement actually involves, explore our red team services.

Technical depth isn’t enough

The best pen testers and red teamers share two things: deep technical expertise and genuine creativity.

The technical side is obvious – you need to understand how systems behave under pressure, and how to adapt when a vector doesn’t work as expected. But creativity is what separates good from exceptional.

Testing isn’t a checklist. When a system reacts unexpectedly, the question isn’t “what does the tool say next?” – it’s “what does this tell me, and where does it lead?” That kind of thinking can’t be scripted. It has to be developed.

The second half of that matters as much as the first.

A brilliant technical finding is worthless if it can’t be translated into plain language. The job isn’t just to find vulnerabilities – it’s to help the organisation understand what they mean and what to do about them.

Why no scanner replaces this

Our research into AI-generated code security found that automated tools are good at cataloging CVEs, misconfigured headers, and outdated libraries.

They’re fast, they’re consistent, and they’re useful. But they operate on fixed logic. They flag what they’re programmed to flag, and they stop there.

A skilled tester doesn’t stop there.

They notice how a system reacts, chain together findings that no single tool would connect, and pursue lines of attack that require judgment – not just pattern matching.

Nine times out of ten, real attackers get in through people, not ports. A scanner has nothing to say about that. Manual testing does.

This is why organisations that rely on automated tools as their primary security layer end up with a false sense of coverage. The scanner ran clean – but that’s only true for the things the scanner knows how to look for. The cost of finding out too late is well-documented in our breakdown of the real cost of a cyberattack, which shows what’s actually at stake.

Attackers aren’t limited by that constraint.

A vendor with a quiet network connection into your environment, a help desk employee who clicks the wrong attachment – these don’t show up on a dashboard. They show up when it’s too late.

So, the question isn’t whether to test.

It’s whether you’re testing the right things, in the right way, with people who can tell the difference. Automated tools have their place – but they’re a floor, not a ceiling.

On March 31, attackers compromised axios — a JavaScript library downloaded roughly 100 million times a week. Here’s what happened, who’s affected, and what to do now.

If you’ve never heard of axios, here’s the short version: it’s the library that most JavaScript applications use to talk to the internet.

Fetching data from an API, submitting a form, making a request to a backend service – axios handles it. It’s in frontend apps, backend services, CI pipelines, and internal tools. Chances are it’s somewhere in your stack right now, possibly several places.

On March 31, 2026, axios—with roughly 100 million weekly downloads—became the vector for one of the most significant npm supply chain attacks in recent memory.On March 31, 2026, axios—with roughly 100 million weekly downloads—became the vector for one of the most significant npm supply chain attacks in recent memory.

You don’t need to have installed axios directly to be at risk.

Any package in your dependency tree that lists axios with a floating version range (^1.x) and was rebuilt during the exposure window may have pulled in the malicious version automatically. This also includes AI coding assistants and automated tooling — anything that ran npm install on your behalf yesterday should be treated the same as a manual install.

We’ve written before about software supply chain security and the systemic risks that come with modern dependency management. This attack is exactly the scenario we described – not a theoretical edge case, but a live incident affecting one of the most widely used libraries in the JavaScript ecosystem.

Google’s Threat Intelligence Group has attributed the attack to UNC1069, a North Korean group previously active in cryptocurrency theft.

Here’s what happened, how it worked, and what you should check right now.

What happened

The attacker didn’t touch a single line of axios source code.

Instead, they compromised a long-lived npm access token belonging to jasonsaayman, the project’s lead maintainer. With that token, they published two new releases – one for the 1.x branch and one for the legacy 0.x branch – 39 minutes apart, covering both release lines simultaneously.

Both releases modified exactly one file: package.json. The only substantive change was adding plain-crypto-js@4.2.1 as a runtime dependency. That package was pre-staged 18 hours earlier, under a separate attacker-controlled account, with a clean version first to build registry history before the malicious update was pushed.

plain-crypto-js contains a full copy of the legitimate crypto-js library – every source file identical, bit-for-bit. The only difference is a postinstall hook: “node setup.js”.

When npm resolves the dependency tree and runs that hook, the dropper fires. It contacts the attacker’s command-and-control server, delivers a platform-specific payload for macOS, Windows, or Linux, then deletes itself and replaces package.json with a clean stub reporting version 4.2.0.

By the time npm install finishes, there’s no error, no warning, no obvious trace. The directory node_modules/plain-crypto-js/ exists, but npm list shows version 4.2.0 – not the malicious 4.2.1 that actually ran. Standard npm audit finds nothing.

Why this specific attack is worth studying

Most supply chain incidents involve obvious red flags – a zero-history package, a suspicious name, a sudden maintainer change.

This one was deliberately engineered to avoid all of them.

That’s what makes it worth paying attention to, even if axios isn’t in your stack – the technique will be reused.

The attacker published a clean decoy package 18 hours before activating the payload – long enough to avoid “brand new account” alerts from registry scanners. The malicious axios releases were signed by the legitimate maintainer’s account. No corresponding commit or tag appeared on GitHub (that gap is the forensic signal, in hindsight), but most CI systems don’t verify OIDC provenance on pull.

This is the attack pattern that NIS2 and CRA regulations are increasingly focused on: not a breach of your perimeter, but a compromise of the supply chain your code depends on.

Your code didn’t have a vulnerability. Your tooling did.

The OIDC misconfiguration that made it possible

Axios had OIDC Trusted Publishing configured for its release workflow.

In theory, this should have made a token-based publish impossible – OIDC ties releases to specific GitHub Actions runs, and the ephemeral token can’t be stolen.

In practice, the GitHub Actions workflow passed both the OIDC credentials and a classic NPM_TOKEN environment variable. When both are present, npm defaults to the token. The long-lived token – which can be exfiltrated – was effectively the only authentication method that mattered.

This is a common misconfiguration. Many projects enable OIDC Trusted Publishing and consider the job done, without removing or rotating the classic token that overrides it.

Check if you’re affected – right now

Step 1 – Check your lockfile for the malicious versions

Step 2 – Check for the malicious dependency in node_modules

The presence of this directory – regardless of what version package.json now reports – means the dropper executed.

Step 3 – Check for persistent artifacts

If you find any of these

The response depends on where the install ran.

For ephemeral CI runners (e.g. GitHub-hosted), the runner is destroyed after each job — rotate any secrets that were injected during the affected run and move on.

For developer machines and self-hosted runners, treat the system as fully compromised: isolate it from the network immediately and re-image it or restore from a verified clean backup taken before March 30.

Once you have a clean machine, rotate everything that was accessible from it: npm tokens, SSH keys, cloud credentials (AWS, GCP, Azure), CI/CD secrets, and any values in .env files present at install time.

To downgrade cleanly

What to change in your CI/CD configuration

Beyond the immediate incident, this attack exposes a few controls worth auditing across your pipelines.

The broader pattern

This isn’t an isolated incident.

The axios attack follows the same playbook as the CrowdStrike npm compromise, the IoliteLabs VSCode extension backdoor, and the fake ClawdBot VS Code extension we documented earlier this year — all incidents where a trusted-looking package or installer was used to deliver a credential stealer to unsuspecting developers.

That model is under sustained attack.

The attacker here invested 18 hours of prep time, built platform-specific payloads for three operating systems, and designed the dropper to self-destruct. This is not someone experimenting – it’s operational tradecraft applied to the JavaScript supply chain.

As we covered in our supply chain security framework, the highest-risk entry points are often not your own code but the tools and processes you depend on to build and deploy it.

The question isn’t whether your perimeter is secure, it’s whether your CI pipeline would have caught this before it ran.

For teams with third-party risk exposure

If you’re managing a product that runs JavaScript in CI and you have compliance obligations – PCI DSS, NIS2, ISO 27001 – this incident is worth documenting even if you weren’t affected.

Our third-party cyber risk management work often starts with incidents like this one: not after a breach, but as a trigger to audit what dependency hygiene actually looks like in practice across an engineering org.

The controls that would have caught this – OIDC provenance checks, version pinning, –ignore-scripts in CI, outbound network monitoring – aren’t difficult to implement. They just tend not to exist until something goes wrong.

If you want to review your current posture, get in touch.

Indicators of compromise

Many modern Android applications are highly advanced and operate in sensitive domains like banking, money transfers, and other critical services people rely on daily. A rooted environment gives attackers elevated access to the device, which they can abuse in order to bypass the app’s restrictions, extract sensitive data, and interfere with the app’s behavior.

To counter these threats, many apps implement protections against common tools and techniques used in reverse engineering. These include anti-root, anti-hook, and anti-debug mechanisms, which are designed to make an attacker’s job significantly more difficult—often requiring considerable effort and creativity to bypass.

A practical look at protection mechanisms

This article provides other security researchers with a practical look at how some of these protection mechanisms are implemented and how they can be bypassed during penetration testing or security research.

Additionally, by understanding how these protections work, developers can build stronger, more resilient security mechanisms into their apps and even extend these ideas to develop more advanced and effective techniques.

Furthermore, during this research, an application called TamperLab was created. It includes various protection mechanisms to detect whether a device is rooted, whether any hooking is in place, or whether the application is being debugged. The project is fully open-source, and contributions are welcome.

It can be found on the following GitHub page for you to check out:

Anti-Root Protections

In this section, we will look at some commonly used root detection techniques and their implementations, and immediately follow each one with an example of how it can be bypassed during testing or reverse engineering.

The “One Function” Folly

The most common way of implementing protection measures such as anti-root, anti-hook, and anti-debug is by placing all checks inside a single function. This is a common mistake, as it gives attackers the opportunity to bypass all protections within seconds.For example, in the following scenario, the RootBeer library is used to quickly demonstrate why placing all checks in a single function can be problematic. As shown in the code snippet below, the isRooted() function is called.

Such a function includes various methods to detect if the device is rooted.

Although the function includes many ways to detect if the device is rooted, it is not sufficient because the isRooted() function itself can be hooked, allowing an attacker to bypass all detections with a single hook.

Using the following simple Frida script, we can do exactly that. We obtain a reference to the RootBeer class and hook the isRooted() function, immediately returning false.

Using the following command, the targeted application can be started with the hook applied.

As shown in the following image, the previously created script successfully bypasses all the checks because they are contained within a single function.

Testing this inside TamperLab shows that we successfully bypass the protection measure, and a green checkmark is displayed.

SU Binary Check (Shell)

All rooted Android devices contain the su binary, and any application requiring root access must use su to elevate privileges and perform privileged actions on the device.

When present on a device, applications can detect the existence of the binary and conclude that the device is rooted. A quick way to check for it is by programmatically executing the which su system command.In my application, I created a simple HelperClass that contains various functionalities and detection methods. One of its purposes is to execute system commands.

The executeCommand() function essentially passes the given command as an argument to the exec() function, which executes it on the device.

If the su binary exists, the command will return its full system path, otherwise, an error code will be returned.

Using Frida, we can bypass this technique by hooking the exec() function itself. If we detect a command such as which su, we can replace it at runtime with another non-existent command.

As demonstrated, by using this technique, we can target specific exec() parameters after reverse engineering the application and bypass the detection mechanisms in place.

SU Binary Check (Native C/C++)

Another way developers may check for the su binary or for rooted devices in general is by writing native C/C++ code using JNI. In case you are unfamiliar, JNI (Java Native Interface) is a framework that allows Java code running on the Android platform to interact with native applications and libraries written in C or C++.

For example, we can check for the su binary by iterating through common system paths where it might exist, and then using the std::ifstream function to check if the file can be opened.

A small Java class is then created to serve as a bridge between the Java code and the native C/C++ code in the application. It uses JNI (Java Native Interface) to perform the native task.

Under normal circumstances, you wouldn’t have access to the source code. However, a common way to reverse engineer the application is by decompiling it using JADX, which can be done with the following command.

Once decompiled, your application may contain various libraries. You can easily filter through them by searching for files with the .so extension, which indicates native libraries.

To reverse engineer the library, tools such as Ghidra or IDA Pro can be used. In this case, Ghidra was used.

The decompiled code shows that ifstream is first used (1) to check whether the file exists. Based on this check, the function returns \x01 (JNI_TRUE) (2) if the su binary is found, otherwise, it returns \x00 (JNI_FALSE) (3).

Since this is a JNI function and is exposed using extern “C”, it appears in the symbol table with the exact name observed in Ghidra.

Bypassing such checks is relatively straightforward. To hook a native function using Frida, we use Interceptor.attach() and specify the target function using Module.findExportByName().

Since we are intercepting a function from the native library, we need to attach to the process while it is already running by using the -n parameter with the following command.

As shown in the script’s output, we successfully bypass the check even though it resides within JNI code.

Another clever approach is to hook the open() function instead of the entire native function implemented in the application.

Since std::ifstream() ultimately invokes the open() system call, we can hook open() to intercept any attempt to access a binary whose path contains “su”. We can then substitute that path with a fake one to bypass the check.

As shown in the image, this technique effectively bypasses native checks early by using the -f flag to hook before execution, unlike the -n flag, which attaches the hook while the process is already running.

Spoofing /proc/mounts

Nowadays, many Android devices are commonly rooted using Magisk, which comes with a variety of built-in features.

The /proc/mounts file contains a list of all currently mounted filesystems on the device. Additionally, when a device is rooted using Magisk, it modifies the boot image and mounts partitions dynamically by default, so you may find traces of Magisk there as well.

An implementation to detect this might look like the following, where an application reads the contents of /proc/mounts in search of Magisk.

To bypass this, we can create a script like the following, where we define a list of mounts that don’t contain Magisk traces or any other suspicious entries, for that matter.

The first interceptor hooks the open() system call to capture the file descriptor used when accessing /proc/mounts.

The second interceptor hooks read(), checks if the file descriptor corresponds to /proc/mounts, ensures the content hasn’t already been spoofed (to prevent repeated modifications and potential crashes), and finally replaces the buffer with our fake mount data defined at the top.

By running the hook, we successfully spoof the contents of /proc/mounts with our fake data, effectively bypassing the detection check.

It’s important to note that these techniques can be implemented and bypassed in various ways. Consequently, multiple solutions and countermeasures exist to address them.

Anti-Hooking Protections

Hooking is a powerful technique used during mobile penetration tests because it allows intercepting, modifying, and monitoring an application’s behavior at runtime. It provides direct access to function calls, arguments, return values, and the internal logic of methods.

To perform such attacks, Frida is a widely used tool that enables pentesters and attackers to bypass security controls or extract potentially sensitive data.

Frida Port Detection

A common way to detect Frida is by checking for open frida-server ports, since Frida communicates using WebSockets. Simple checks often look for ports like 27042 or 27043, which are the default ports used by Frida.

Such checks can be easily bypassed by simply starting the Frida server on a different port using the following command.

A more advanced detection method involves scanning all ports by sending specific HTTP requests and checking for a 101 Switching Protocols response, which indicates the presence of a Frida server.An example of such native code would involve sending a WebSocket upgrade request to every open port on the device. If the response contains 101 Switching Protocols, it confirms that a Frida server has been successfully detected.

This check can be bypassed by hooking the read() calls and inspecting the buffer content after the call completes. If the buffer contains 101 Switching Protocols, indicating a Frida server query, we can modify the response to something benign such as HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n to evade detection.

As demonstrated, once the hook is executed, the check is successfully bypassed.

Frida Threads Detection

In Linux-based environments (including Android), each process has a task directory located at /proc/self/task, containing a subdirectory for each thread within the process. Each of these subdirectories includes a comm file that holds the name of the corresponding thread.

When Frida is injected into a process, it typically creates several threads for its internal operations. These threads often have distinctive names such as frida, gum-js-loop, gmain, gdbus or some other which can be used to detect Frida’s presence.

To better understand this, we can run the following command on the device to retrieve the names of all threads for a specified process.

As shown in the following snippet, this is the output of the thread list when no Frida hooks are active.

When a Frida hook is applied to the process, threads named gmain and gdbus appear both associated with Frida’s runtime. This allows us to detect Frida based on the presence of these thread names.

To detect this, we can use C++ code like the following, which loops through each comm file in the /proc/self/task directory to retrieve thread names and checks them against a list of common thread names used by Frida.

One intriguing approach to evade detection is to patch the entire frida-server binary by replacing all occurrences of strings like gmain. By searching for gmain in Ghidra, we can observe the following results.

By selecting one of the instances, we can examine the disassembled code to pinpoint its exact location.

We can now use Ghidra’s built-in hex editor to modify these strings, replacing gmain with another string, such as hackr.

After injecting the Frida hook, we can see that we have successfully bypassed the detection, as it no longer identifies Frida’s threads.

If we loop through the thread names again for the application we are attacking, we can see that it now successfully contains the hackr thread name.

Of course, there are other detectable strings, but this simple example demonstrates one way to bypass detection by directly patching the frida-server binary yourself. This way you could build an entirely different frida-server to avoid detections or modify the original source code as well.

Anti-Debug Protections

Anti-debug protections are another way to protect your Android application from reverse engineering. These mechanisms aim to detect or prevent debugging attempts, stopping attackers from stepping through the app’s code instruction by instruction to understand its internal logic.

Like most security measures, anti-debug mechanisms can also be bypassed using Frida hooks. However, I want to show you how you can defeat these protections using a debugger itself.

Defeating Anti-Debug using Debugger

isDebuggerConnected()

This is a simple, ready-made function that checks if a debugger is connected to the application. It returns true if a debugger is detected, otherwise, it returns false.

Implementing such a function is straightforward, and you can call it as follows:

To use the debugger and bypass this check, we can utilize JADX’s integrated debugger. Before launching it, ensure the application is already running.

Another way to start an application is by using the following ADB command, which will launch the app but pause and wait for the debugger to attach.

As shown, when you launch the application, it will display a message indicating that it is waiting for a debugger.

In my case, it doesn’t work, but I can open the application without it waiting for the debugger. However, your application might require this behavior, so it’s important to test both methods.

Additionally, whenever you’re done or close the application, make sure to run the following command to remove the app from waiting for a debugger.

Once ready, you can open JADX and load the APK file of the target application. You can also pull the APK from your device using ADB.

Once loaded into JADX, select the green bug icon, which opens a dialog prompting you to choose the application to debug along with its process ID.

After the debugger attaches, the application’s execution is automatically paused inside the MainActivity. You can then press the green play button to continue running the application.

Once you find the correct position to set a breakpoint, you can do so by pressing the F2 key. For this example, I set the breakpoint exactly where the isDebuggerConnected() function is called.

The following instruction essentially calls the isDebuggerConnected() function using the invoke-static opcode.

Then, the move-result instruction moves the return value of the function (either true or false) into the v0 register.

By stepping over these two instructions, we can observe that the v0 register contains the value 1, indicating that a debugger has been detected.

To bypass this check, we can simply set the value to 0 using the debugger, as shown below:

Continuing the application’s execution, we successfully bypass the check by manipulating the variables during debugging.

Detection via USB & ADB

Another interesting way to detect debugging is by checking if the device is connected via USB with ADB enabled. While this isn’t a direct debugger detection method, it remains a useful check nonetheless.

A simple implementation might look like the following, where the app dynamically listens for the USB_STATE broadcast and parses the connected and adb boolean extras from the received intent.

We can also bypass this check by using the debugger to place breakpoints at the appropriate locations.

In this case, I set a breakpoint on the if-eqz instructions, which checks whether the values in registers v0 and v2 are equal to zero. These registers correspond to the connected and adbEnabled flags.

When the breakpoint is hit, we observe that both values are set to 1 (true), indicating that USB is connected and ADB is enabled.

We can now simply set these two values to 0 (false), causing the check to fail and allowing the app to continue execution.

Conclusion

We have explored several common anti-root, anti-hook, and anti-debug techniques and demonstrated how each can ultimately be bypassed. However, it is important to recognize that these protections still play a critical role in Android security.

No protection is entirely foolproof. Given enough time and the right tools, a determined attacker can often find a way around most defenses. However, the goal of these mechanisms isn’t to create an unbreakable application, but rather to increase the complexity of attacks. This raises the time, effort, and skill required for an attacker to compromise the application, which can deter casual attackers and slow down more advanced ones.

In short, while these security checks can be bypassed, they remain a valuable part of a defense-in-depth strategy. Labs like TamperLab that we have created, provide a practical environment where you can practice implementing these detection mechanisms and learn how to bypass them. It’s about making it hard enough that breaking the security is no longer worth the effort.

At Infinum, we help you stay ahead with tailored cybersecurity services, including penetration testing and security assessments. Whether launching new products or protecting existing ones, we identify weaknesses before attackers do so you can focus on what matters. Learn more about how we keep your digital world secure on our cybersecurity page.