What Google TPUs Are: Architecture, Deployment Model, and the Security Research That Exists
For executives
Google's Tensor Processing Units (TPUs) are custom AI accelerators designed and built by Google specifically for machine learning workloads. Unlike NVIDIA GPUs or AMD Instinct, TPUs are not commercially available as standalone hardware — they are accessible only through Google Cloud. The eighth generation (TPU 8t for training, TPU 8i for inference) was announced at Google Cloud Next 2026. TPU security is a limited but growing research area: there are no publicly disclosed CVEs assigned to TPU hardware, but academic research has demonstrated side-channel vulnerabilities in the broader category of ML inference accelerators that apply to TPU-class hardware.
What TPUs are and how they differ from GPUs
A GPU is a general-purpose parallel processor adapted for AI workloads. It can run arbitrary GPU-accelerated code (graphics rendering, scientific simulation, cryptocurrency mining) in addition to AI computation.
A TPU is purpose-built for matrix operations — specifically the tensor multiplications that underlie neural network computation. It has a very regular architecture (a systolic array) optimised to perform large matrix multiplications with maximum efficiency. It cannot run arbitrary GPU code; it runs only TensorFlow/JAX computation graphs (and increasingly PyTorch via XLA).
This specialisation makes TPUs fast for AI workloads and unusable for most other purposes. It also means the attack surface is narrower in scope — the workloads a TPU runs are constrained to ML computation.
TPU deployment model
TPUs are available only through Google Cloud (Cloud TPU). Google operates TPU infrastructure internally for its own AI workloads (Gemini training runs primarily on TPUs) and sells access via Cloud TPU as a managed service.
This cloud-only deployment model has security implications. The TPU hardware itself is entirely under Google's control — customers do not have physical access to TPUs and cannot modify their firmware, drivers, or software stack below the Cloud TPU API layer. The hardware-level attack surface (firmware vulnerabilities, BMC vulnerabilities like the DGX A100 series has) is entirely in Google's security scope, not the customer's.
The absence of public TPU CVEs
No CVEs have been publicly assigned to Google TPU hardware or the Cloud TPU software stack. This reflects several factors:
The closed ecosystem: the TPU software stack is proprietary and not available for external security research. Fuzzing or hardware reverse engineering is not possible without physical access.
Google's internal security research: Google's Project Zero and other internal teams conduct security research on Google infrastructure. Findings may result in internal fixes without external CVE assignment.
Limited external deployment: TPUs are not sold as standalone hardware, limiting the population of security researchers who can examine them.
What academic research reveals
While no TPU-specific CVEs exist, academic research on the broader class of ML inference accelerators has demonstrated relevant attack classes:
Bandwidth utilisation side-channels: research (Banerjee et al., 2021, "Bandwidth Utilization Side-Channel on ML Inference Accelerators") demonstrated that the bandwidth pattern between an accelerator and its weight storage can reveal ML model architecture information. This applies to Cloud TPU instances in shared multi-tenant environments where co-location creates bandwidth contention channels.
Power side-channels on Edge TPU: research on Google's Coral Edge TPU (designed for on-device inference) has demonstrated power analysis attacks that can reduce side-channel leakage (Dubey and Aysu, 2025, "Stochastic Training for Side-Channel Resilient AI"). The Edge TPU is a physically accessible hardware platform; Cloud TPU is not.
Timing channels: execution timing of inference requests on shared infrastructure can reveal information about input content, as demonstrated in the LLM inference timing research that applies to any shared inference platform.
What this means for Cloud TPU users
The absence of publicly known TPU vulnerabilities does not mean TPUs are secure — it means their hardware attack surface is not externally auditable. The architectural properties that create vulnerability potential in GPUs (complex firmware, memory management across multiple processes, shared hardware in multi-tenant deployments) exist in TPU deployments too.
The relevant security considerations for Cloud TPU users are:
Cloud TPU is a multi-tenant service — Google runs TPU pods with multiple customer workloads. The isolation between customers' TPU workloads is provided by Google's virtualisation and access control infrastructure, not by public-facing security specifications.
The Cloud TPU API is the primary interface customers interact with. API-level security (authentication, authorisation, audit logging) is the customer's primary control surface.
Model security on TPUs: models deployed on TPUs are loaded from Google Cloud Storage. The supply chain security of those model artifacts — integrity, access control — is in the customer's scope.