Pulse: hardware-attested presence proofs against AI voice fraud

Financial institutions and government agencies still lean heavily on “trusted phone numbers” and one-time passcodes for critical transactions. When a high-risk event happens, whether that means a large transfer, an account recovery, or a benefits change, something gets sent to a phone and the system assumes that if the phone responded, the right human must be in the loop.

That assumption has been getting weaker every year.

Pulse is an iOS and Android app plus an attestation backend that tries to move the trust anchor away from voice and phone number alone and toward a different question: is there a live human, using a bound device, that can produce a hardware-attested proof right now? The code is not open source yet, but there is a live production demo and public challenge at gate.kenshikilabs.com.

The rest of this article explains the problem we see, how we are approaching it, and where the design can still fail.

Phone numbers are often sourced from software products that ingest data from credit reporting agencies and other KYC data providers. Those systems invest enormous effort in getting the “link a human to a credit file” problem right: name, SSN, address, date of birth, and search algorithms tuned so that false positives and false negatives are both rare.

For legitimate users, this works very well. The industry is good at finding a file for a human. Fraudsters simply stand on top of that success.

Once an attacker has control of the phone number attached to a real identity, whether through SIM swap, account hijack, or a synthetic identity that has been grown over time, every protection that assumes “code delivered to that phone equals correct person” starts to break. The attack surface now includes:

• SIM swap and number porting fraud.
• OTP interception through malware or call-center scripts.
• Synthetic identities that look clean in bureau data.
• AI-assisted voice impersonation and deepfake audio used against call-center agents or IVRs.

There has been a lot of work to mitigate these patterns: SIM swap detection, device fingerprinting, phone-age and ownership signals, velocity checks, and sometimes voice biometrics. Those controls help, but they do not change the deeper issue. Because AI has made convincing synthetic artifacts cheaper, institutions need a way to verify that the person behind the interaction is real and present, not just attached to a believable record or a believable voice.

Kenshiki Labs is working on a product called Pulse. The basic idea is simple. Stop treating voice, or a phone number by itself, as the primary proof. Start treating “live human plus bound device plus attested sensor stack” as the thing you rely on.

At a high level, Pulse is a smartphone application and corresponding verification flow. The app runs on the user’s device. It collects and validates evidence locally, including device binding, biometric unlock, and optionally identities that the user has chosen to register. The evaluation happens inside a hardware-attested environment on the device, such as a secure enclave, trusted execution environment, or integrity framework, so raw biometric and sensor data do not need to leave that phone.

The server side receives a signed, privacy-preserving claim that says, in effect: a live person is present now, this is their bound device, and optionally this device is associated with a previously registered identity.

That claim can be checked during high-risk online flows like a credit application, account recovery, or large transfer. It can also be checked during an interaction with a call center, where the institution can say: before we proceed, we need a live presence proof from your Pulse app.

In other words, instead of asking whether the caller sounds like the customer, the system asks whether there is a live human controlling the expected device and whether that device can produce an attested presence proof for this exact action.

AI voices and cloned speech make it much harder to trust what a human agent hears. But a cloned voice cannot, by itself, produce a hardware-attested proof from a specific device. A remote proxy answering calls cannot safely pass a presence check that is bound to a device and biometric on the legitimate user’s phone unless that attacker has already compromised that device more deeply.

This does not magically solve all fraud. It shifts the trust anchor from “voice plus phone number” to “attested presence on a bound device,” and in doing so it makes several attacks more expensive:

• Pure voice-based deepfake becomes insufficient.
• Social engineering a call-center agent without controlling the victim’s device gets harder.
• Ghost workers and proxies behind remote identities become easier to detect when presence proofs are required on an ongoing basis, not only at onboarding.

That change in attacker economics matters. Fraud systems often fail not because a single signal is bad, but because the cheapest path for the attacker is still good enough. The goal here is to make “good enough” require deeper compromise, more cost, and more operational exposure.

Some design choices follow naturally from that model. First, on-device evaluation keeps raw biometrics and sensor streams local. The backend should only see derived signals and signed claims. Second, hardware attestation relies on platform-provided primitives to prove that checks ran in a trusted environment, not in a random app on a rooted phone. Third, the relying party should get something closer to an evidence record than an opaque score, so a decision can be explained, reviewed, and audited later.

There are still hard questions. How robust is the trust model across different Android vendor stacks versus iOS? What realistic attacker paths remain once a device is compromised through malware, screen sharing, or OS-level access? How do we avoid becoming another centralized honeypot for identity data while still giving institutions evidence they can rely on?

Those are not edge questions. They are the system questions. Any serious deployment has to answer them directly.

Pulse is still early. We are piloting with institutions that have felt AI voice fraud and remote-worker fraud directly, and we expect the system to be stress-tested by real deployments and by security researchers. If you are working on identity, fraud, remote work integrity, or high-risk action controls, critique is useful. A design like this gets better by being challenged, not by being treated as finished.