Singapore AI Safety Hub

<h2>The team</h2>Some of the most consequential decisions of the AI era will depend on answering one question: can we verify what is happening inside AI datacenters? Answering it could unlock international cooperation, help countries protect their sovereignty, and enable trustworthy adoption of AI in high-stakes industries. Building tools that can earn trust across borders is an urgent technical and political challenge.SASH’s Verification team builds and tests tools to verify agreements about AI. We prototype new verification mechanisms, lead international research collaborations, and work with policymakers around the world to show what these tools can do and inform how they’re used.You’d join a small team combining technical expertise with international AI policy experience. Our technical team is led by Pascal Berrang, an Associate Professor at University of Birmingham, and brings experience from the Singapore Government. Our policy team brings experience from Oxford and the Centre for the Governance of AI, while our partners include experts from the Future of Life Institute and the University of Oxford.<h2>The problem</h2>The hardest question in verification is not whether a datacenter is running the model it says it is. It is whether it is also running something else. A cluster can serve declared inference all day and train an undeclared model on the capacity left over.We are interested in software-only approaches to this problem. If a verifier can keep a cluster's accelerators demonstrably occupied (i.e., their high-bandwidth memory holding the state they claim to hold, their compute answering challenges that cannot be faked or precomputed in advance), then there is no spare capacity for an undeclared training run. Physics supplies the lever: information cannot travel faster than light, and some computations cannot be performed faster than the hardware allows, so the time a cluster takes to answer is itself evidence about what hardware it has and what that hardware is doing.The nearest concrete version is a memory-state challenge protocol. The prover commits frequently to workload checkpoints, the verifier fires N unique nonces simultaneously, and each device must return a function of its claimed memory state within a deadline (a function designed to demand serious memory bandwidth and matrix multiplication). Round-trip times are recorded and a random sample is proven genuine. A related family, proof of useful work, pushes further: the declared workload's own computation becomes the evidence, so the accounting costs almost nothing to produce.Compression is one of the open questions: weights or a KV cache engineered for fast lossless decompression would let a prover reconstruct state it was not actually holding, freeing the hardware for whatever else it wanted to do. Showing that workload state cannot be decompressed inside the challenge window, or modifying workloads so that it cannot, would unlock the approach. Beyond that, a prover may hold secret memory capacity in error-correcting-code cells or overprovisioned regions; the challenge has to be designed so honest response time stays feasible; and the deadline has to be short enough to block cheating while surviving network latency and kernel launch times.<h2>Your work</h2>You would own the question of how much of a cluster can be accounted for from outside it, and how little room can be left over.Concretely, that means designing challenge protocols and then measuring whether real accelerators can satisfy them: microbenchmarking, writing challenge kernels, characterising what high-bandwidth memory can and cannot do under adversarial conditions, and deciding whether the numbers support a claim someone could stake an agreement on. The work sits between two disciplines: measurement is GPU performance engineering, the rest is constructing a hardness assumption and then trying to break it. We expect most candidates to be strong on one side and curious about the other. You'd work alongside cryptographers and hardware-security colleagues, and you'd be expected to publish, including when the answer is that something does not work.<h2>Representative projects</h2><ul><li>Implement a candidate challenge function and characterise honest-response latency across real cluster topologies.</li><li>Establish how much spare capacity a cluster could retain while still passing every challenge, then design that margin down.</li><li>Run the adversarial compression study: how much of a frontier model's weights or KV cache can be losslessly decompressed inside a realistic challenge window, and how much hardware does that free up?</li><li>Design and evaluate post-training that measurably raises the cost of compressing weights, without measurably hurting the model.</li><li>Quantify how much memory a prover could plausibly hide, and what protocol changes make hiding it useless.</li><li>Extend the approach from memory occupancy to compute, through proof-of-useful-work schemes where the declared workload's own computation carries the evidence.</li><li>Take the protocol end to end against a live inference cluster and write up what broke.</li><li>Design a red-team/blue-team competition for the protocol: cheap to run, because they need no new hardware.</li><li>Red-team our own timing assumptions.</li></ul><h2>About you</h2>We are hiring this role at a range of levels. We care more about ability and trajectory than years of experience.You may be a good fit if you:<ul><li>Have GPU performance or systems measurement experience (kernels, microbenchmarks, memory hierarchies, distributed timing) or a cryptographic background and a real appetite for getting your hands on hardware.</li><li>Are rigorous about measurement, including about the ways your own measurement can be fooled.</li><li>Can hold an adversary in your head while you optimise something.</li><li>Are comfortable working on a protocol that may turn out not to work, and saying so in public if it does not.</li><li>Thrive in ambiguous, early-stage environments where defining the problem is part of the job.</li></ul>Strong candidates may also have:<ul><li>CUDA or equivalent low-level accelerator programming.</li><li>Compression, information theory, or model quantisation experience.</li><li>Background in timing-based protocols, proofs of space or time, or distance bounding.</li><li>Experience characterising hardware you don’t have documentation for.</li><li>Familiarity with LLM inference internals: batching, KV cache management, scheduling.</li></ul><h2>Role Logistics &amp; Benefits</h2><h3>Location:</h3><ul><li>This is a remote role that can be based in Singapore, the UK, or remotely.</li><li>For candidates interested in relocating, SASH can provide visa sponsorship in the UK.</li><li>Our team is globally distributed, so remote team members should be comfortable maintaining some working-hour overlap with colleagues across regions.</li></ul><h3>Compensation:</h3>Our compensation takes location, experience, and level into account. Our compensation takes location, experience, and level into account. Salaries above the stated range may be available for exceptional candidates.<div> </div><h3>Benefits:</h3><ul><li>Competitive benefits and leave policies.</li></ul>

Research Engineer / Research Scientist, Remote Compute Accounting

<h2>The team</h2>Some of the most consequential decisions of the AI era will depend on answering one question: can we verify what is happening inside AI datacenters? Answering it could unlock international cooperation, help countries protect their sovereignty, and enable trustworthy adoption of AI in high-stakes industries. Building tools that can earn trust across borders is an urgent technical and political challenge.SASH’s Verification team builds and tests tools to verify agreements about AI. We prototype new verification mechanisms, lead international research collaborations, and work with policymakers around the world to show what these tools can do and inform how they’re used.You’d join a small team combining technical expertise with international AI policy experience. Our technical team is led by Pascal Berrang, an Associate Professor at University of Birmingham, and brings experience from the Singapore Government. Our policy team brings experience from Oxford and the Centre for the Governance of AI, while our partners include experts from the Future of Life Institute and the University of Oxford.<h2>The problem</h2>Verifying what happens inside a datacenter running large AI models is the bottleneck on almost every serious agreement about AI — between states, between a regulator and a lab, between a company and the customers it wants to reassure. The obstacle is always the same shape: the party with something to prove cannot hand over its model weights, and the party doing the checking cannot simply take its word.One solution to this problem puts its trust in hardware: a trusted execution environment isolates a computation and attests to what ran inside it, so a claim about what happened becomes a claim you can check against a chip. Confidential computing exists on current accelerators and runs near production speed.That unlocks several problems. An audit tells you something about a model, but nothing connects that result to the weights actually being served — attesting the deployed model by weight hash closes the gap between "this model was evaluated" and "you are talking to the model that was evaluated." The most valuable evaluations are built by people who cannot publish their test set, against models whose weights cannot leave the developer; inside an enclave, neither side has to give way. Logs can be attested where they are produced, making usage auditable after the fact without being readable.<h2>Your work</h2>You would own the question of what a chip's word is actually worth, and then build the systems that are worth building on top of it.Concretely, that means establishing what attestation on current accelerators does and does not prove, designing a registry that lets an outsider check an attested claim without anyone's permission, and making attested pipelines that hold together when someone hostile pulls on them. "It works" and "an adversary cannot make it lie" are different bars, and only the second one counts here. You'd work alongside cryptographers and hardware-security colleagues on the team and with external partners, and you'd be expected to publish since the whole approach depends on other people being able to check it.<h2>Representative projects</h2><ul><li>Establish what a GPU confidential-computing attestation guarantees on current hardware, and publish where it breaks.</li><li>Design and build the registry: the attested-result format, the submission path for third-party auditors, and a verification client someone outside the trust chain can actually run.</li><li>Build attested logging inside an enclave, and work out what a privacy-preserving audit over those logs can and cannot establish.</li><li>Run an evaluation end to end under mutual secrecy, with an attestation recording whose code and whose weights were involved.</li><li>Chain attestations across a pipeline so a claim about a final output stays checkable back to its inputs, then find where that chain breaks under production load.</li><li>Get a confidential-computing stack running on accelerators from more than one supply chain.</li><li>Combine hardware attestation with the team's cryptographic work, so a verifier does not have to trust the chip alone.</li><li>Red-team our own attestation chain.</li></ul><h2>About you</h2>We are hiring this role at a range of levels. We care more about ability and trajectory than years of experience.You may be a good fit if you:<ul><li>Have built something real with confidential computing or hardware enclaves (SGX, TDX, SEV-SNP, Arm CCA, GPU confidential computing) or have strong systems security fundamentals and want to learn them on the job.</li><li>Understand attestation chains well enough to know where they carry weight and where they are decoration.</li><li>Are hard to reassure: you read a security claim and look first for what it does not say.</li><li>Can ship an integration across organisational boundaries, which is as much about people as about code.</li><li>Thrive in ambiguous, early-stage environments where defining the problem is part of the job.</li></ul>Strong candidates may also have:<ul><li>ML inference serving experience and the operational scars of production deployment.</li><li>Background in audit, certification, or PKI: the registry is a certificate authority with unusual requirements.</li><li>Privacy-preserving computation experience beyond enclaves: secure computation, differential privacy, federated setups.</li><li>Familiarity with the AI evaluations landscape and what safety institutes actually need.</li><li>Experience explaining a hardware guarantee to someone who will never read a datasheet.</li></ul><h2>Role Logistics &amp; Benefits</h2><h3>Location:</h3><ul><li>This is a remote role that can be based in Singapore, the UK, or remotely.</li><li>For candidates interested in relocating, SASH can provide visa sponsorship in the UK.</li><li>Our team is globally distributed, so remote team members should be comfortable maintaining some working-hour overlap with colleagues across regions.</li></ul><h3>Compensation:</h3>Our compensation takes location, experience, and level into account. Salaries above the stated range may be available for exceptional candidates.<div> </div><h3>Benefits:</h3><ul><li>Competitive benefits and leave policies. </li></ul>

Research Engineer / Research Scientist, Confidential Computing

<h2>The Team</h2>Some of the most consequential decisions of the AI era will depend on answering one question: can we verify what is happening inside AI datacenters? Answering it could unlock international cooperation, help countries protect their sovereignty, and enable trustworthy adoption of AI in high-stakes industries. Building tools that can earn trust across borders is an urgent technical and political challenge.SASH’s Verification team builds and tests tools to verify agreements about AI. We prototype new verification mechanisms, lead international research collaborations, and work with policymakers around the world to show what these tools can do and inform how they’re used.You’d join a small team combining technical expertise with international AI policy experience. Our technical team is led by Pascal Berrang, an Associate Professor at University of Birmingham, and brings experience from the Singapore Government. Our policy team brings experience from Oxford and the Centre for the Governance of AI, while our partners include experts from the Future of Life Institute and the University of Oxford. <h2>The problem</h2>An international agreement on AI is only as broad as what can be verified, and the appetite for verification is growing. In September 2026 Anthropic gave independent third-party evaluators permanent, employee-level access to its systems, and OpenAI said it would match it. Frontier developers now accept that outsiders should be able to check their work.Between states, the options are cruder: take the operator's word that a datacenter is running a declared, safety-tested model and nothing else, or put inspectors and hardware inside the building. Inspections do not scale, and installing hardware might not be acceptable to every operator.Zero-knowledge proofs are the one approach that removes both problems at once. The prover can demonstrate a claim — the committed model produced these output tokens — while revealing nothing about the weights, and the verifier's trust rests on mathematics rather than on hardware it has to manufacture, ship and guard. Progress here can be deployed immediately, because there is nothing to fabricate and nothing to install.The catch has always been cost, and the figures usually quoted for it are badly out of date: the literature still puts proving at four orders of magnitude more expensive than the computation being proved. Our own prototype proves a full conversation with an 8-billion-parameter model in about an hour and a half on a single GPU, and most of what is left is ordinary engineering rather than cryptography. Extrapolated to a 405-billion-parameter model, fifty times larger, that is 16 to 24 hours because cost grows far more slowly than the models do.Verification is also a much friendlier setting for ZKPs than the applications they were designed for. A verifier needs confidence that, say, 99% of compute is used legitimately — and sampling roughly 300 outputs is enough for 95% confidence in that claim. Better still, the sampling can go inside a single proof: preliminary work suggests blocks within a transcript can be sparsely sub-sampled, so floating-point matrix multiplication only has to be emulated exactly for a small sample of vector products. For some problems that is a 100,000x saving over a complete proof.<h2>Your work</h2>You would own the line from "this works in a paper" to "a policymaker can rely on this."Concretely, that means driving down proving cost, closing the gap between what our proofs currently explain and what a frontier inference actually does, and making the resulting system one that a sceptical adversary's technical staff would sign off on. You'd work alongside hardware-security and systems colleagues on the team and with external cryptographers, and you'd be expected to publish since the whole approach depends on other people being able to check it.<h2>Representative projects</h2><ul><li>Prove a full inference transcript from a frontier-scale model end to end, and report honestly what it cost.</li><li>Get an open prototype to parity with the best proprietary systems. The most useful thing anyone can do for this field right now is make the state of the art public and checkable.</li><li>Close out the data-preparation path that dominates our current proving time, using the reference-implementation check as a correctness oracle for AI-assisted optimisation.</li><li>Help develop the agenda for where this field goes next, including where AI-assisted research can be pointed at.</li><li>Design and analyse the sub-sampling scheme: what fraction of blocks must be checked, under what adversary model, to bound the information a dishonest prover can smuggle through.</li><li>Bring ZKPs closer to what is deployed today, integrating exact emulation of the hardware's floating-point behaviour, including its rounding, scaling and accumulation, or moving production inference to integer arithmetic with batch-invariant kernels.</li><li>Build proof circuits for low-precision formats such as NVFP4, where "just emulate the hardware" turns into numerical engineering.</li><li>Investigate compute- and memory-exhaustion schemes such as proof-of-useful-work or proof-of-space.</li><li>Hide the model architecture itself, perhaps through proof recursion.</li><li>Red-team our own constraint system.</li></ul><h2>About you</h2>We are hiring this role at a range of levels, from people early in their research career to people who have shipped proof systems in production. We care more about ability and trajectory than years of experience.You may be a good fit if you:<ul><li>Have built something real with a modern proof system (Halo2, Plonky3, STARK-based stacks, or comparable) or have deep GPU and ML systems experience and want to learn proof systems on the job. We expect to hire both profiles.</li><li>Are comfortable reasoning about soundness: what an adversary can do, what your assumption actually buys you, and where the argument is critical.</li><li>Can write code that other people will attack, and enjoy that prospect.</li><li>Are willing to do the unglamorous last mile: generalising across model architectures, chasing numerical mismatches, rather than only the interesting part.</li><li>Thrive in ambiguous, early-stage environments where defining the problem is part of the job.</li></ul>Strong candidates may also have:<ul><li>Published work in applied cryptography, verifiable computation, or succinct proofs.</li><li>Low-precision numerics experience: rounding modes, accumulation order, and why two GPUs disagree.</li><li>Formal verification experience, especially of a verifier codebase or a protocol.</li><li>Familiarity with lookup arguments, recursion, or folding schemes.</li><li>Experience explaining a cryptographic guarantee to someone who will never read the proof.</li><li>Experience using AI systems as research collaborators on problems where correctness is checkable, and a view on where that works and where it does not.</li></ul><h2>Role Logistics &amp; Benefits</h2><h3>Location:</h3><ul><li>This is a remote role that can be based in Singapore, the UK, or remotely.</li><li>For candidates interested in relocating, SASH can provide visa sponsorship in the UK.</li><li>Our team is globally distributed, so remote team members should be comfortable maintaining some working-hour overlap with colleagues across regions.</li></ul><h3>Compensation:</h3>Our compensation takes location, experience, and level into account. Our compensation takes location, experience, and level into account. Salaries above the stated range may be available for exceptional candidates.<div> </div><h3>Benefits:</h3><ul><li>Competitive benefits and leave policies.</li></ul>

Singapore AI Safety Hub

Open jobs at Singapore AI Safety Hub

Research Engineer / Research Scientist, Remote Compute Accounting

Research Engineer / Research Scientist, Confidential Computing

Research Engineer / Research Scientist, Zero-Knowledge Verification

Working for Singapore AI Safety Hub?

Featured companies