Account Security

Authentication, sessions, password handling, and data isolation in JARVIS.

This page covers how JARVIS accounts are protected. It describes behaviour you can rely on; it does not describe internal mechanisms.

Authentication

To use JARVIS you must have an authenticated session. It is established by signing in with:

Method	What it proves
Email and password	You control the password on the registered address
Continue with Google	You control a Google account with a verified matching email
Continue with GitHub	You control a GitHub account with a verified matching email

Provider sign-in requests identity information only — never access to your repositories, files, or other content. See Sign In.

What happens with a wrong password

The sign-in form returns the same Invalid email or password message whether the address is unregistered or the password is wrong. There is no way to use the form to discover which addresses have accounts.

Repeated attempts from one address are temporarily throttled.

Passwords

8 to 128 characters, stored so they cannot be read back.
Never returned by any endpoint, never included in a reply, never emailed.
Changing or resetting a password ends every session on every device.

JARVIS does not tell you whether a password is "correct" for another service, and it will not accept, store, or act on a credential you paste into a conversation.

Sessions

Property	Behaviour
Duration	30 days, or until you sign out
Scope	One device
Sign out	Ends the session on that device only
Password change	Ends all sessions on all devices
Token exposure	Never appears in a reply, a page, or any readable output

API keys

Personal API keys grant programmatic access to chat, conversations, and tasks. See Sessions & API Keys.

A key is shown once at creation. Only a hash is stored afterwards.
Revoking a key takes effect on that key's next request.
Unknown, revoked, and malformed keys are rejected the same way, so they cannot be probed.
A key cannot be used to reach endpoints that are session-only.

Data isolation

Area	Isolation
Conversations	Readable and writable only by their owner
Messages	Follow their conversation
Memories	Scoped to your account; filtered by category and searchable
Tasks	Scoped to your account
Web lookups	Scoped to your account

Requesting an identifier that belongs to someone else returns not found rather than forbidden, so identifiers cannot be probed to discover what exists.

Note

Memory entry is filtered for credential-shaped content before anything is stored. Requests that look like passwords, keys, tokens, private keys, or credential-bearing connection strings are not saved as memories.

What JARVIS will not disclose

Even when asked directly, and even through indirect phrasing, JARVIS does not reveal:

Credentials, passwords, API keys, or tokens
Session cookies or their contents
Internal configuration or system details
Other users' data

This is enforced, not just prompted. See JARVIS Policies.

Practical advice

Use a unique password, and a long passphrase where you can.
Revoke API keys you no longer use.
Review memories and conversations periodically.
Treat a shared device as if your session stays: sign out when you are done.
If anything looks wrong, change your password first.

Global Enforcement — account-wide restrictions
Privacy — what is stored
Sessions & API Keys — managing access