# Your account & sign-in
Source: https://docs.tensormachine.ai/accounts

## Your email is your account

On Tensor Machine, **your account is your verified email address** — not the *way* you happen to
sign in. Whether you use a password, **Continue with Google**, or your company's single sign-on,
they all resolve to the **same person**: the same workspaces, the same API keys, the same usage
history, and the same wallet.

There is exactly **one account per verified email**. You can't accidentally end up with two
parallel accounts for the same address by signing in a different way — a common trap that would
otherwise split your keys and balance across look-alike profiles.

## One person, many ways to sign in

| Sign-in method | When you'd use it |
|---|---|
| **Email & password** | You signed up directly. |
| **Continue with Google** | You'd rather not manage a password — Google vouches for your email. |
| **Company SSO** ([SAML](/console-management/sso)) | Your organization routes your work email through its identity provider (Okta, Microsoft Entra ID, Google Workspace). |

All three point at the **same account** as long as they carry the same verified email. So you can
start with a password today, click **Continue with Google** tomorrow, and later sign in through
your company's SSO — and every time you land on the same place, with everything you own intact.

<Callout type="info">
  We only unify sign-in methods on an email an identity provider has **verified**. An unverified
  address never attaches to — or inherits the access of — an existing account.
</Callout>

## What "the same account" means

Because your identity is the person and not the credential, everything you own follows *you*, not
the login:

- **Workspaces** — your [personal workspace](/workspaces) and every organization you belong to
  appear in the switcher no matter how you signed in.
- **API keys** — your personal keys are yours across sign-in methods; they aren't tied to one
  login.
- **Usage & wallet** — your consumption history and balance are attached to your account, so they
  read the same whichever way you came in.

## When your company turns on SSO

A frequent moment of confusion, handled for you: you've been using Tensor Machine with a
password or Google, and later your company sets up [SSO](/console-management/sso) for your work
domain.

- You **keep the same account** — signing in through SSO lands on the *you* that already exists,
  with your existing organization seat, keys, and history. Nothing is recreated or duplicated.
- Your **personal workspace stays reachable** with your password or Google login — SSO gates the
  *organization*, never your account. See
  [When your company enforces SSO](/workspaces#when-your-company-enforces-sso).

## Adding or losing a sign-in method never strands you

Sign-in methods are just *ways to prove* who you are — they aren't your account. So:

- **Turning one on** (e.g. linking Google, or your company enabling SSO) simply adds another door
  to the same account.
- **Turning one off** (your company removes an SSO connection, you stop using Google) closes that
  door but never deletes the account behind it — your workspaces, keys, and balance remain, and
  another sign-in method still reaches them.

The one thing that *does* remove access is an admin **removing you from an organization** — and
even then only that organization's seat and keys go; your login, your personal workspace, and its
balance are untouched. Offboarding removes access to the *organization*, never to your *account*.

## Related

- [Workspaces & organizations](/workspaces) — what your account owns, and how personal vs. company
  workspaces differ.
- [Single Sign-On (SAML)](/console-management/sso) — for admins setting up SSO for an organization.
- [Authentication](/authentication) — authenticating **API requests** with keys (distinct from
  signing in to the console).