Account Security

Password and two-factor

Settings → Security holds your password and two-factor authentication.

Turn on two-factor. This is the single highest-value security action available to an individual user, and it defends against the attack that actually happens — credential reuse from a breach somewhere else.

Store the recovery method somewhere you will still have access to if you lose your device. The common failure is not being compromised; it is being locked out because the recovery codes were saved on the phone that broke.

For admins: encourage it, and consider whether your organization's identity provider should be the authentication path instead, which is Lesson 11.4.

Sessions

The Security page shows active sessions. Review them occasionally and revoke anything you do not recognize or no longer use — the laptop you replaced, the browser on a machine you no longer have.

This is the control that matters after a device is lost, and it is worth knowing where it is before that day rather than searching for it while anxious.

Linked accounts

Settings → Accounts manages linked sign-in providers — the identities you can use to sign in with — and, separately, connected device accounts for the account switcher.

The thing worth thinking about: each linked sign-in provider is another way into your account, which means your Kavanah security is the security of the weakest one. Linking an account you do not protect as carefully as this one lowers the floor.

Unlink providers you do not use.

Blast radius

An admin should think about this at workspace level, not just personally.

A compromised member account reaches their projects and their connected personal accounts.

A compromised admin account reaches the workspace configuration: the integrations, the agent's autonomy ceiling and action policies, the API keys, the permissions.

And an API key minted by an admin reaches whatever that admin could reach — which is why Lesson 10.5 argues for minting keys as the least-privileged user who can do the job.

The practical implications: keep the admin list short, insist on two-factor for admins, and rotate API keys on a schedule since nothing expires them for you.

The agent angle

One consideration specific to a product with an acting agent.

The action policies are a security control as well as an operational one. A workspace where external sends require approval is a workspace where a compromised account cannot immediately mail your entire client list, because the send parks for a human.

That is not a reason to leave everything on approve forever. It is a reason to keep the irreversible categories there, which Lesson 8.2 recommends anyway for different reasons. The two arguments converge on the same setting.