Keys that expire, not keys under the mat

Think of access as a house key. You can leave a copy under the doormat where anyone who looks can grab it, or you can carry a key that only works for a short while and only for the front door. Kovalent is built around the second kind of key in two places: how your browser proves who you are, and how a running node proves it may touch AWS.

When you sign in, the dashboard and admin console do not hand your session token to JavaScript to stash in the browser. It is set as an HttpOnly, Secure, SameSite=Lax cookie: the browser sends it on your requests, but page scripts cannot read it, it travels only over HTTPS, and it is held back from cross-site subrequests such as a form POST or an embedded frame on another site. That combination closes the common paths by which a session gets stolen or replayed. Sustained guessing is met with rate limits and lockouts rather than unlimited attempts.

The same instinct applies to the nodes. Instead of baking a permanent AWS access key into a container, where a single leak would be a lasting liability, workloads use IAM Roles for Service Accounts (IRSA). A pod presents a signed identity token to AWS through OIDC and receives short-lived credentials scoped to just the role it needs. There is no static secret to exfiltrate, and access expires on its own.

The platform also refuses to start unsafe. On boot in a production context, the API panics if it detects development defaults such as a stock signing secret; a misconfiguration fails loudly at startup rather than serving traffic with a known-weak key.

Short-lived credentials shrink the blast radius of a leak; they do not make a compromised browser or a mis-scoped role harmless. A role granted more permission than it needs is still over-privileged for the window it is valid, so least-privilege scoping still matters. These are strong defaults, not a substitute for careful configuration on your side.