Security by observable boundary

Agent work has gates you can see.

Talavine does not ask a model to decide whether its own action is safe. Consequential work crosses host-enforced approval and policy boundaries, while local history and receipts show what was proposed, allowed, blocked, and completed.

Structural approval

A proposal is a persisted state, not a reassuring sentence.

When a worker wants to do something consequential, its proposal is stored as work waiting on you — it shows up as a task and stays pending until you decide. A separate send guardrail can block outbound work, and action policy records a threat assessment before a sensitive action proceeds.

Human review is a real lane

Work that needs a decision remains pending until the person resolves it. The worker cannot turn its own proposal into approval by changing its wording.

Sends have a host guardrail

Outbound work can finish in a visibly blocked state instead of being silently treated as success. Narrow user-configured rules may reduce prompts for their exact scope.

Receipts distinguish outcomes

Workers leave durable history and tool receipts, and host checks distinguish completed, unfinished, blocked, and failed work.

Prompt-injection boundary

Inbound instructions are treated as untrusted content.

Message and web content is fenced before it reaches the agent. A tool-boundary taint guard can block or escalate consequential calls whose arguments appear to have been authored by that fenced content. Sensitive pending actions also pass through deterministic threat assessment, with an optional model judge as an additional signal rather than the authority.

Persistent browser profile

A reusable login is not authorization.

The visible browser profile can retain cookies so you can sign in directly without placing passwords or MFA codes in chat. Every visit, page snapshot, click, and field fill still passes through the permission broker. You can approve once, for the conversation, or grant standing access so a worker can run while you are away. Standing browser access is intentionally broad: a website control can itself submit, purchase, or delete, so grant it only to work you trust and revoke it when that standing access is no longer needed. Dedicated Talavine send and delete tools keep their own separate gates.

Visible browser window Authorization check per operation Passwords stay in the browser Optional standing worker access
Vibes and packages

Distribution trust and runtime access are separate checks.

Signed first-party catalog

Each catalog package is checked against its SHA-256 identity and ECDSA signature using a publisher public key pinned in the desktop app. A changed web host alone cannot forge a verified first-party package.

Capability review and egress limits

Imports show executable code, web domains, file access, agents, and host actions for review. A Vibe configured with allowed web domains has those per-app limits enforced by its runtime; unrestricted web access remains visible as a broader capability.

Local-first, with named exits

Your profile is local authority—not a claim that no byte leaves.

Your Talavine profile and communication memory live on your machine. Connected providers synchronize only accounts you authorize, and cloud models receive relevant request context when you select them. Local databases rely on your operating system's device protection; Talavine does not currently claim application-level database encryption at rest.