Security

This chapter is the customer-facing security overview. It’s not the full architecture document (which lives in our security white paper for customers who request it), but it covers what you actually need to know.

Isolation

Your Jootle instance is a single-tenant virtual server. That means:

Your data is in a database that no other customer’s instance can read.
Your filesystem is on a virtual disk only your instance can mount.
Network traffic between your instance and the broader Jootle control plane goes over a private VPC; no other customer’s traffic touches it.

The other side of single-tenancy: the operational team at Jootle can SSH to your instance for support and updates (with audit logs). If that’s not appropriate for your compliance posture, we can configure consent-gated access on Business/Enterprise plans.

Authentication

Customers sign in to their Jootle instance with:

Email + password. The default. Passwords are hashed with bcrypt.
OAuth (Google). Available if you’ve enabled it. The user signs in with their Google account.
SSO (SAML / OIDC). Available on Business and Enterprise plans. Configure under Settings → SSO.

We strongly recommend multi-factor authentication (MFA). MFA is configured per-user under Settings → Security. Options:

TOTP (authenticator apps like Google Authenticator, 1Password, Authy).
WebAuthn / hardware keys (YubiKey, etc.).

MFA can be enforced instance-wide (an Owner / Admin setting) so all users must enable it.

Sessions

When you sign in, you get a session that’s valid for a configurable duration (default 30 days, can be shortened in Settings).

You can:

See all active sessions for your account under Settings → Security → Sessions.
Sign out of a specific session if you don’t recognize it.
Sign out of all sessions (forces re-login on every device).

If a device is lost or stolen, sign out of all sessions and rotate any credentials that may be on that device.

API keys and credentials

Several places store credentials inside your instance:

AI provider keys (Anthropic, OpenAI, etc.). Encrypted at rest with your instance’s encryption key.
Integration credentials (Google OAuth tokens, Slack tokens, etc.). Encrypted at rest.
Channel credentials (Telegram bot tokens, SMS provider tokens). Encrypted at rest.

The encryption key for your instance is held by us. We do not transmit it to the AI providers; we use it only to decrypt-and-call-provider-on-your-behalf.

If you’d prefer customer-held encryption keys (BYOK at the encryption layer, not the AI provider layer), that’s a Business/Enterprise option called “customer-managed keys”. Talk to us.

Audit logs

Every significant action in your instance is logged:

User logins (with IP, timestamp, user agent).
Approval gates (what was approved, by whom, when).
Outbound actions (emails sent, calendar events created, etc.).
Permission changes (user added, role changed, etc.).
Integration changes (connected, disconnected, credential rotated).

The audit log is visible under Settings → Audit log. You can filter by user, action type, or time range.

The audit log itself is append-only. Entries cannot be edited or deleted from inside the instance.

Transport security

All traffic between your devices and your instance is TLS-encrypted. The certificate is issued by Let’s Encrypt and rotates automatically.

Traffic between your instance and AI providers is also TLS to the provider’s API.

Internal traffic on our VPC (between your instance and the control plane) is TLS plus VPC-private routing. It does not traverse the public internet.

Network exposure

Your instance exposes:

HTTPS on port 443 for the web app.
HTTPS on the API endpoint for any integrations you’ve configured to call in (webhooks, etc.).

It does NOT expose, by default:

SSH to the public internet (SSH is VPC-only from our operational network).
Database ports (PostgreSQL is local-only).
Any other administrative ports.

If you have a specific firewall posture, we can adjust. Talk to us.

Patching and updates

We push security updates to your instance automatically as they become available. Patches happen during a low-traffic window and are usually invisible (no downtime).

Major upgrades (operating system upgrades, database major-version upgrades) are scheduled with you, and we test them in our staging environment before rolling out.

You don’t have to do anything to stay patched. If you want notification when a patch is applied, enable update notifications in Settings.

What to do if you suspect unauthorized access

Steps, in order:

Sign out of all sessions (Settings → Security → Sign out all). This invalidates active sessions.
Rotate your password. And enable MFA if you haven’t.
Check the audit log for the past 30 days. Look for unrecognized logins (IP, user agent), unrecognized actions.
Rotate any sensitive credentials that might be on a compromised device (AI provider keys, integration credentials).
Email support@jootle.com with what you found. We’ll help investigate.

Don’t delete the instance or wipe data in the immediate aftermath. The audit log and existing data are essential for understanding what happened.

Bug bounty and responsible disclosure

If you (or your security team) find a vulnerability in Jootle, please disclose it responsibly:

Email security@jootle.com.
Include reproduction steps.
Give us a reasonable window to fix before publishing.

We have a bug bounty program (rewards for valid reports). Details at jootle.com/security.

Compliance

SOC 2 Type 2. Attestation available under NDA for customers on Business plans and above.
GDPR. Customer-facing flows for access, deletion, and portability are documented in Data, privacy, and exports.
HIPAA. Available as a Business add-on with a BAA. Configures your instance for compliant operation.

Where to learn more

The security architecture white paper (technical, detailed) is available to customers on request. Email security@jootle.com.

For day-to-day operations, this chapter and Data, privacy, and exports cover what most customers need.