Privacy Policy

This policy explains what Vultkey processes when you create an account, store keys in your vault, publish a public link, or claim a code through a public link. Vultkey is designed for digital keys, licenses, API credentials, coupon codes, game keys, and similar records.

Vultkey is currently in beta. Security behavior, public-link rules, claim logs, and the data model may change as the product is hardened. When behavior changes in a meaningful way, this policy should be updated to match the product.

When you create an account, Vultkey stores your email address, Supabase Auth session state, and profile record. Your email is used for sign-in, account ownership, member allowlists, and account settings.

If OAuth providers such as Google or Discord are enabled, Supabase may use the basic account data returned by those providers to create a session. Vultkey does not control the privacy practices of those providers.

Vultkey stores metadata such as title, platform, category, tags, source, notes, status, expiration date, and timestamps so the vault can list, filter, archive, audit, and publish records.

Raw key material is not stored as plain text. Key values are encrypted server-side with AES-GCM. A HMAC-SHA256 fingerprint may be stored for duplicate detection. That fingerprint is used for comparison and is not intended to recover the original key.

A public link stores its target, type, claim limits, recipient limits, visible fields, raw reveal permission, copy-button visibility, expiration date, and related access settings. Link lookup uses a HMAC token hash. The owner can copy the link again because token material is stored encrypted.

When a recipient claims a code, Vultkey creates a claim record. If the recipient enters an email or note, that information is stored with the claim. If the link is restricted to Vultkey members, the signed-in member email may be shown to the link owner. Raw keys are only shown after claim when the owner allowed raw reveal.

Vultkey may use a server-set device cookie, browser fingerprint, request fingerprint, user-agent hash, IP hash, and signed-in member account to reduce repeat claims from the same recipient. These signals help enforce per-recipient limits and reduce abuse.

Raw IP addresses, raw user agents, and raw browser fingerprint payloads are not stored as claim history. They are converted to HMAC hashes for comparison. These signals are not perfect identity proof. VPNs, browser settings, privacy extensions, and different devices can affect them.

The link owner can see public-claim logs. Those logs may include the key title, platform, masked key snapshot, claim time, redemption confirmation time, recipient-entered email, recipient note, Vultkey member email, country code, device type, operating system, browser, language, and timezone.

Country data depends on geo headers from the production hosting provider. It may be empty in local development or on infrastructure that does not forward geo headers. If the recipient uses a VPN, the country may reflect the VPN exit location. Browser and operating-system names are inferred from browser-provided signals and may be approximate.

Vultkey uses Supabase cookies for authentication. Public-claim protection may use an additional httpOnly device cookie. That cookie does not contain the raw key and exists to help recognize a device or session for claim-limit enforcement.

The public claim page does not store raw codes in sessionStorage. It may keep claim metadata during the same browser session; if the page is closed before the code is copied and the owner disabled repeat raw reveal, the raw code may not be shown again.

Vultkey may record audit events for creating, updating, deleting, revealing, copying, public-link creation, public claims, public redemptions, and sign-ins. Audit metadata is intended for owner visibility, troubleshooting, and security review. Raw keys, tokens, secrets, and passwords should not be written into audit metadata.

Vultkey uses Supabase for authentication and database storage. Upstash Redis may be used for rate limiting and short-term abuse protection. In self-hosted deployments, the operator is responsible for environment variables, database access, backups, retention, and provider configuration.

Account deletion is designed to remove application data. Some technical, audit, backup, or infrastructure records may remain for a limited time depending on deployment and retention settings. When a key is deleted, claim history may keep limited metadata or snapshots so repeat-claim protection and audit integrity continue to work.

Vultkey is built to avoid storing raw keys in plain text and to keep sensitive actions server-side. It is still a beta product. You should evaluate your own risk before storing high-value production credentials or regulated secrets.