GAIA 01
Runs in your environment
Gaia is not a hosted black box. The intended deployment is your machine or server, with your configuration, your model providers, and your connectors.
Security & Privacy
Powerful agents need boring guardrails.
Gaia is designed as a local-first, open-source agent system. It can use files, browsers, shells, memories, MCP tools, and messaging connectors, so security is not a footer detail. This page states the model plainly, including the parts still being hardened before a stable release.
open source bring your own keys local-first design early project
Operating model
02
Tools are real access
Filesystem, browser, shell, MCP, and channel connectors can touch sensitive data. Gaia should be treated like software you give permissions to, not like a chat widget.
03
Souls inherit limits
The soul-smith model is powerful only if generated agents inherit clear tool scopes, model scopes, memory rules, and action boundaries.
Data flow
| Data | Where it lives | What can leave |
|---|---|---|
| Configuration | Local project/server config by design. | Only values you explicitly send to a provider, connector, or external tool. |
| Memory | Short-term and long-term memory are intended to be stored under your Gaia environment. | Relevant memory may be included in prompts to your chosen LLM provider when needed for a task. |
| Prompts and task context | Visible in your local session and logs, depending on your setup. | Sent to whichever model provider you configure for Gaia or a specific soul. |
| Connector messages | Handled through the connected channel: CLI, Telegram, or WhatsApp. | Channel providers receive the messages required to deliver that integration. |
| Tool outputs | Available to Gaia during the run and may be persisted if memory/logging is enabled. | May be passed back into an LLM call if the active task needs the result. |
Important trust surfaces
agent runtime
ADK runs the agent loop.
Google ADK is the runtime layer Gaia builds on for agent behavior. The security boundary here is simple: prompts, tool calls, and delegated soul work must stay observable and scoped.
memory
mem0 is long-term context.
Memory is where Gaia becomes personal. It also creates risk: users need to inspect, delete, export, and disable long-term memory when the remembered context is no longer wanted.
channels
Connectors carry private messages.
Telegram and WhatsApp integrations are sensitive because they handle inbound messages, channel credentials, and outbound replies in your name.
browser tools
Browser access is real action.
Browser automation lets Gaia inspect pages and operate web flows. The default backend is Camoufox; a Playwright MCP backend is opt-in. Either way it should be treated like a powerful tool with clear permissions, visible logs, and confirmation before sensitive submissions.
Risk areas
The sharp edges are named.
Agent systems fail when they pretend broad permissions are harmless. Gaia should make those boundaries visible.
- Tool access: shell, filesystem, browser, and MCP tools can perform real actions.
- Prompt injection: webpages, emails, files, and tool outputs can contain hostile instructions.
- Generated souls: newly created agents need scoped permissions instead of inheriting everything by default.
- Third-party skills: readable does not automatically mean safe. Skills and MCP servers need review before use.
- Messaging connectors: channels can expose private conversations if tokens, sessions, or web clients are misconfigured.
Hardening checklist
Before stable release.
1
Permission profiles for tools, souls, and MCP servers.
2
Confirmation gates before destructive filesystem, shell, outbound messaging, or credential-touching actions.
3
Readable audit log showing who acted: Gaia, a named soul, or an external tool.
4
Memory controls: inspect, delete, export, and disable long-term memory.
5
Connector isolation so Telegram, WhatsApp, and CLI sessions do not silently share more than intended.
6
A security reporting path and documented threat model in the public repository.
Security reports
Gaia is early. Until a dedicated security email is published, please report issues privately through the GitHub repository owner rather than posting exploitable details publicly.