Overview
This series explains how Odysseus, a self-hosted AI workspace with privileged local access, is designed to keep authority attached to provenance as requests move through exposure, identity, ownership, tools, untrusted content, transports, and future tasks. It distinguishes server-enforced gates from model-facing warnings and local path controls from process isolation. The result is an evidence-bounded operating model: keep entrypoints and internal services private, scope callers and integrations, bind approvals to exact actions, match each edge's control to its effect, and treat shell access, configuration, and automation as remaining high-trust surfaces.
Learning outcomes
- Authentication identifies a caller, but ownership and live privilege checks decide which state and tools that caller may use.
- Untrusted content remains data; after it enters a run, high-impact actions may require server-side effect checks and exact approval.
- Public fetches and webhooks use transport-specific validation, pinning, redirect, and size or signing controls that do not transfer automatically.
- Odysseus is designed for trusted users on a private network, and shell access remains unsandboxed even inside a workspace.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
How does Odysseus decide what a caller may do?
Odysseus uses separate identity, ownership, role, scope, and server-side tool checks; a login alone is not sufficient. Delegated tokens retain an owner for data attribution but do not inherit the owner's interactive powers.
How does Odysseus handle prompt injection from external content?
Odysseus treats web pages, emails, memories, documents, skills, MCP descriptions, and tool results as untrusted data rather than authority. A server-owned run context tracks that provenance and can gate high-impact actions, with approval bound to the exact action and context.
Are Odysseus's file tools and shell commands sandboxed?
No: resolver-backed file tools have path and workspace protections, but Bash and Python run as the application user without a general process or filesystem sandbox.
What is the recommended exposure model for Odysseus?
The documented model is a private deployment for trusted users, not arbitrary public exposure. Keep authentication enabled, use HTTPS and a trusted proxy or private access layer for remote access, and leave raw model and internal service ports private.