Is OpenHuman Safe? Privacy and Security Review

At a Glance

OpenHuman stores your data locally in SQLite and Markdown — a genuine privacy advantage over cloud-only assistants. But the OAuth exchange routes through a TinyHumans proxy, chat tasks go to cloud providers by default, and voice TTS uses ElevenLabs. Local storage reduces cloud breach risk but does not eliminate local attack surface. No independent security audit exists as of June 2026.

• Local: memory, tokens (after initial exchange), embeddings, summary tree.
• Cloud: OAuth proxy, chat/reasoning/vision, ElevenLabs TTS, web search, Meet API.
• Biggest risk: OAuth aggregation — one app holding tokens for email, calendar, code, payments.
• No published security audit yet. Empty CVE history means youth, not proven safety.
• Action: use the signed installer, start with test accounts, audit OAuth scopes, and re-evaluate quarterly.

Data Flow: What Stays Local vs What Hits the Cloud

Understanding the data flow is the first step to making an informed trust decision. Below is a step-by-step breakdown of where your data goes during each phase of using OpenHuman.

• Step 1 — Install: you download the signed installer or run a script. The script comes from GitHub. The app installs to your local machine.
• Step 2 — OAuth Exchange: you click Connect and authorize via the service's consent screen. The token routes through a TinyHumans-hosted proxy app, then forwards to your local machine. The proxy only handles the initial exchange — never ongoing API calls.
• Step 3 — Token Storage: your local OpenHuman instance encrypts the token with AES-256 and stores it in the local vault. The token never leaves your machine after this point.
• Step 4 — Data Sync: OpenHuman fetches data from connected accounts every ~20 minutes. Raw data canonicalizes to Markdown, chunks into scored segments, and folds into the Memory Tree — all locally.
• Step 5 — Memory Storage: the Memory Tree lives in local SQLite and an Obsidian-compatible Markdown vault. You can open, read, edit, or delete any chunk.
• Step 6 — Inference: by default, chat, reasoning, vision, and voice TTS route to cloud providers via the bundled subscription. With local AI enabled, embeddings, summaries, and lightweight tasks run on Ollama or LM Studio instead.
• Step 7 — Output: the assistant's responses display in the desktop app. No conversation history is sent to a remote backend unless you explicitly enable cloud features.

What Is Genuinely Local

These components stay on your machine by design. This is OpenHuman's core privacy advantage.

• Memory storage: SQLite database plus Markdown files in an Obsidian-compatible vault, both on the user's machine.
• OAuth tokens: described as AES-256 encrypted in the local vault after the initial exchange.
• Auto-fetch output: data canonicalized to Markdown and written locally rather than sent to a remote backend.
• Optional fully-local inference: memory embeddings, summary-tree building, and background reasoning loops can be driven by Ollama or LM Studio.
• Inspectability: the Obsidian vault lets users read, edit, or delete what the assistant is carrying forward.

What Is Not Purely Offline

These components still reach the cloud. Local-first does not mean local-only.

• The initial OAuth exchange is brokered through a TinyHumans-hosted proxy app.
• Chat, reasoning, and vision tasks route to cloud providers by default via a bundled subscription.
• Voice TTS uses ElevenLabs, which is a cloud service.
• Web search and web scrape call external sources.
• Google Meet participant mode depends on the Meet platform API.
• Cross-agent shared memory (agentmemory backend) requires running a separate service that you self-host or accept as remote.

OAuth Aggregation Risk

This is the single biggest risk. An agent holding OAuth tokens for your email, code, calendar, payments, and communications has assembled a high-value target in one place. Local storage reduces cloud breach exposure but does not eliminate risk from local attackers, compromised dependencies, or malicious plugins.

• One install can hold access to email, calendar, drives, repos, trackers, notes, payments, CRM, and design tools.
• 118+ integrations means 118+ permission surfaces. Every connector adds attack surface.
• Treat this as a high-value target: minimize connectors, audit scopes, and revoke what you do not use.

Install-Path Risk

The quick-start commands execute remotely hosted code before you have read it. macOS and Linux: curl-to-bash. Windows: PowerShell remote-invoke. Both are convenient — and both run code sight unseen.

• Use the signed installer from tinyhumans.ai/openhuman on primary machines.
• If you use the terminal installer, read the script before you run it.
• The source is GPL-3.0 and auditable — but audit it or trust the signed build, not blind execution.

Pre-Connection Security Checklist

Run through this checklist before connecting any account. Print it, check each box, and only then proceed.

• Inventory the accounts you plan to connect. Drop everything non-essential.
• Start with a low-risk test account before connecting production data.
• Read every OAuth scope screen. Reject broader permissions than the use case needs.
• Inspect the install script, or use the signed installer from the official page.
• Record where each task runs: local model, bundled subscription, or external provider.
• Test memory deletion: delete a synced item and confirm it leaves the vault, SQLite store, and index.
• Test token revocation: revoke a connector token at the source and confirm OpenHuman handles it gracefully.
• Get explicit consent from all participants before adding the agent to a call or meeting.
• Skip banking, legal, health, and primary corporate accounts until an independent audit is published.
• Re-evaluate quarterly: beta software changes fast, and new integrations may introduce new risks.

Related Guides