How PulseKit secures your data and credentials

No Account Means No Honeypot

The most common way API keys and tokens leak from a SaaS product is a breach of the central user database: one compromised query, millions of rows, every stored credential exposed at once. PulseKit sidesteps this category of risk entirely because there is no account.

When you install PulseKit and connect a service, the identity in the system is your device, not a profile tied to an email address and password. There is no signup form, no password store, and no shared pool of user records sitting behind a single login. There is nothing to phish and no credential database to exfiltrate. This is not a UX shortcut. We have deliberately made it as a foundational architectural decision that eliminates an entire class of breach surface before any other control is needed.

That said, connecting a service does mean you are granting PulseKit read access to a provider key or token. The rest of this article explains the concrete mechanisms that keep that access scoped, isolated, and low-blast-radius.

Per-Device Credential Isolation

Every set of credentials you connect is scoped to your device alone. The API key or OAuth token you grant on your iPhone is associated with that device's identity and is never shared with, or accessible to, any other device. Two devices with the same provider connected hold entirely separate credentials, and neither can see the other's.

This matters because it bounds the blast radius of any incident. A compromise of one device exposes only the credentials on that device. No other user's keys and no other device's keys are in scope. Contrast this with a pooled-credential model, where one lateral move through a shared service can surface tokens belonging to thousands of users.

Encryption at Rest with AES-256-GCM

Provider credentials are never stored in plaintext. Before a key or token is written to persistent storage, it is sealed with AES-256-GCM, a modern authenticated encryption scheme. The database holds ciphertext only.

The "authenticated" part of AES-GCM deserves attention. Authenticated encryption does not just scramble data; it produces a cryptographic tag that covers the ciphertext and any associated context. If stored data is tampered with, decryption does not silently return garbage, it fails with a verifiable error. This means an attacker who can write to the storage layer cannot substitute a forged ciphertext and have it accepted as authentic.

In practice: even if someone extracted the raw storage from a device, they would have ciphertext that is not usable without the correct key material, and any modification to that ciphertext would be detected before any decryption result is returned.

Signed, Replay-Proof Requests

Every request that PulseKit makes on your behalf is cryptographically signed with an elliptic-curve key using P-256 and the ES256 signature scheme. Two properties of this design prevent a captured request from being useful to an attacker.

Nonces. Each request carries a nonce, a one-time value generated for that request alone. The server rejects any request whose nonce has already been seen.

Timestamp binding. Requests are valid only within a tight time window. A request captured in transit cannot be replayed hours or days later because the timestamp check will reject it.

A conceptual sketch of the components of a signed request looks like this:

1{
2  "nonce": "8f3a1c09b24e",
3  "issued_at": "2026-06-04T12:00:00Z",
4  "payload": { "integration": "github", "metric": "open_prs" },
5  "signature": "ES256(device_private_key, header + payload)"
6}

This is a principles sketch, not a wire format. The point is that forgery requires the device's private key, and replay requires defeating both the nonce store and the timestamp window simultaneously.

Least Disclosure at Runtime

A decrypted credential exists in memory only for the duration of the call it is needed for. Once the call to your provider completes and the metric value is returned, the plaintext key is not retained, cached beyond that moment, or written to any log.

Two practical consequences follow from this. Secrets never appear in logs, so they cannot leak through log aggregators, retention policies, or misconfigured log levels. And PulseKit fetches your number, not your data: the integration makes a scoped read call to your provider, retrieves the metric value (a count, a status, a rate), and that is what surfaces on your widget. Provider data is not aggregated, warehoused, or resold.

Revocability: You Stay in Control

Because credentials are per-device and you granted them through the provider's own OAuth or API key flow, revocation works exactly as the provider designed it. Go to GitHub, Stripe, Vercel, or whichever service you connected, rotate or delete the key or token, and PulseKit's access is gone immediately. No support ticket, no waiting for a deletion pipeline.

This is the correct mental model for the access you are granting: PulseKit holds a delegated credential that you issued. You can un-issue it at any time through the issuing authority. The architecture does not create a situation where your credentials outlive your intent.

The Architecture in Practice

Each of these properties reinforces the others. There is no central account database to breach. Per-device scoping means a compromise of one device is not a compromise of all devices. Credentials at rest are ciphertext sealed with AES-256-GCM, so raw storage access is not usable key access. Requests are signed with ES256 and bound by nonce and timestamp, so network interception yields nothing replayable. Plaintext credentials exist only in memory for the lifespan of a single call and never appear in logs. And the keys are yours to revoke at the provider whenever you choose.

This is the architecture that lets you put a live metric on your home screen without taking on a new security liability. Isolated, encrypted, signed, revocable.