# Understanding the Privacy Model for Agent Data Within agentsview

> Discover the agentsview privacy model. Explore local cleartext SQLite archives, trust boundaries, authentication flags, and TLS for secure agent data.

- Repository: [Kenn Software/agentsview](https://github.com/kenn-io/agentsview)
- Tags: architecture
- Published: 2026-06-20

---

**agentsview implements a workstation-first privacy model that stores all agent data in local cleartext SQLite archives with strict trust boundaries, requiring explicit authentication flags for network exposure and mandatory TLS for remote database synchronization.**

The kenn-io/agentsview repository defines its privacy and security architecture as a single-user application with explicit trust boundaries documented in [`SECURITY.md`](https://github.com/kenn-io/agentsview/blob/main/SECURITY.md). Its design assumes the local authenticated user is fully trusted while treating all external data sources as potentially untrusted input.

## Core Privacy Architecture: Single-User Workstation-First Design

agentsview assumes deployment on a **single-user workstation** such as a developer laptop. The application is not designed for multi-tenant or shared-server environments without explicit configuration changes. According to the threat model defined in [`SECURITY.md`](https://github.com/kenn-io/agentsview/blob/main/SECURITY.md), the system considers the local authenticated user accessing their own archive via UI, CLI, or API as trusted, while network attackers who cannot execute code as the local user are considered in-scope threats.

To mitigate network-based threats, the HTTP server binds to `127.0.0.1` by default, utilizing loopback-only binding combined with host-header allowlists, strict CORS policies, Content Security Policy (CSP) headers, and `X-Frame-Options: DENY`.

## Trust Boundaries and Data Handling

The privacy model establishes explicit trust boundaries between components:

- **Session files → parser**: Untrusted. Session files are parsed but never executed or evaluated.
- **Imports → parser**: Untreated as untrusted structured data.
- **SSH remote sync**: Treated as untrusted data; pulled files undergo local parsing without execution.
- **Parser → SQLite/FTS5**: Trusted boundary where content is stored verbatim in the database.
- **HTTP server → caller**: Loopback-trusted by default, though API routes can enforce authentication via `--require-auth`.
- **agentsview → PostgreSQL**: Requires TLS for remote connections unless `allow_insecure` is explicitly set.

## Data at Rest: Cleartext Storage Model

All session text is stored **in cleartext** within the SQLite archive, including the FTS5 full-text search index. File permissions follow the user's umask, meaning no application-level encryption or secure wiping is performed. When deleting rows, agentsview removes entries from tables and the FTS5 index, but this does **not** guarantee OS-level shredding of the underlying storage blocks.

Users should treat the agentsview data directory with the same security precautions as shell history files or SSH keys, as the application relies on filesystem permissions rather than cryptographic protection.

## Data in Transit: Network Protections

### Local UI and API Binding

By default, the HTTP server binds exclusively to localhost. Exposing the API requires starting the server with the `--require-auth` flag, which enables Bearer token protection for all `/api/` routes:

```bash

# Default loopback-only binding

agentsview serve

# Require authentication for API access

agentsview serve --require-auth --auth-token="my-secret-token"

```

The server implementation in [`internal/server/server.go`](https://github.com/kenn-io/agentsview/blob/main/internal/server/server.go) enforces browser-facing hardening including host-header validation, strict CORS, CSP headers that pin the origin, and `X-Frame-Options: DENY`.

### Remote PostgreSQL Sync

The `pg push` command synchronizes the local archive to a remote PostgreSQL instance. For non-loopback hosts, **TLS is mandatory** and plaintext connections are rejected unless the user explicitly enables insecure mode:

```bash

# TLS-protected connection (default)

agentsview pg push --dsn "postgres://user:pass@db.example.com/agentsview?sslmode=require"

# Insecure connection (requires explicit opt-in)

agentsview pg push --dsn "postgres://user:pass@db.example.com/agentsview" --allow-insecure

```

This logic is implemented in [`internal/postgres/push.go`](https://github.com/kenn-io/agentsview/blob/main/internal/postgres/push.go), which parses the connection string and validates TLS requirements before transmitting data.

### SSH and Import Handling

SSH synchronization utilizes the user's existing SSH keys to pull remote archives. These files are treated as untrusted data and parsed locally without execution. Similarly, any imported data passes through the untrusted parser boundary before entering the trusted SQLite storage layer.

Additional outbound connections include an optional LiteLLM pricing request (HTTPS only, no session data transmitted) and an update check that can be disabled:

```bash

# Disable automatic update checks

agentsview serve --no-update-check

```

## Secrets Detection and Redaction

The secrets subsystem provides defense-in-depth through pattern detection rather than encryption. Implemented in [`internal/sync/engine.go`](https://github.com/kenn-io/agentsview/blob/main/internal/sync/engine.go) and [`internal/service/secrets.go`](https://github.com/kenn-io/agentsview/blob/main/internal/service/secrets.go), the system scans session content for API keys and tokens, storing findings in the database with the following behaviors:

- Findings are **redacted by default** in the UI and CLI output.
- Revealing secrets requires accessing localhost-gated endpoints.
- No encryption is applied to secrets at rest.
- The detector is best-effort and not a comprehensive Data Loss Prevention (DLP) solution.

To query detected secrets via the API:

```bash
curl -H "Authorization: Bearer my-secret-token" \
    http://127.0.0.1:8080/api/v1/secrets?has_secret=true

```

## Optional Privacy Controls and Configuration

Privacy-related flags parsed by [`internal/config/config.go`](https://github.com/kenn-io/agentsview/blob/main/internal/config/config.go) allow users to modify default behaviors:

- **`--require-auth`**: Enforces Bearer token authentication for API routes.
- **`--no-update-check`**: Disables the outbound HTTPS release check on startup.
- **`--allow-insecure`**: Permits plaintext PostgreSQL connections (only via explicit CLI flag).

These options provide flexibility for development environments while maintaining secure defaults for production data handling.

## Summary

- agentsview operates as a single-user workstation application with cleartext SQLite storage following the user's umask permissions.
- Trust boundaries treat external data (imports, SSH sync, session files) as untrusted while considering the local user and SQLite storage as trusted.
- Network exposure requires explicit opt-in via `--require-auth`, with localhost binding enforced by default in [`internal/server/server.go`](https://github.com/kenn-io/agentsview/blob/main/internal/server/server.go).
- Remote PostgreSQL synchronization mandates TLS encryption unless `--allow-insecure` is explicitly set in [`internal/postgres/push.go`](https://github.com/kenn-io/agentsview/blob/main/internal/postgres/push.go).
- Secrets detection provides UI redaction but does not encrypt sensitive findings at rest.

## Frequently Asked Questions

### Does agentsview encrypt agent data at rest?

No. According to the [`SECURITY.md`](https://github.com/kenn-io/agentsview/blob/main/SECURITY.md) specifications and implementation in the storage layer, all session data resides in cleartext within the SQLite archive. The application relies on filesystem permissions and the user's umask rather than cryptographic encryption. Users should secure the data directory using operating-system-level controls equivalent to protecting shell history or SSH keys.

### How does agentsview protect data when syncing to PostgreSQL?

The `pg push` command implemented in [`internal/postgres/push.go`](https://github.com/kenn-io/agentsview/blob/main/internal/postgres/push.go) enforces TLS encryption for all non-loopback remote connections by default. Plaintext transmissions are explicitly rejected unless the user provides the `--allow-insecure` flag, which overrides the security check. This ensures that remote synchronization does not expose data to network eavesdropping without explicit user consent.

### Can I run agentsview on a shared server securely?

While agentsview supports running with `--require-auth` to enforce Bearer token protection on API routes, the architecture assumes a single-user deployment model. The cleartext storage model and lack of row-level encryption make shared server deployments inadvisable for sensitive data. If deploying to a shared environment, ensure the data directory has strict filesystem permissions and always use `--require-auth` with strong authentication tokens.

### What happens to detected secrets in the database?

The secrets subsystem in [`internal/service/secrets.go`](https://github.com/kenn-io/agentsview/blob/main/internal/service/secrets.go) stores detected API keys and tokens in the database without encryption. These findings are redacted by default in both the web UI and CLI outputs, and can only be revealed through localhost-restricted API endpoints. This provides a best-effort safeguard against accidental exposure, though it does not constitute a fully secure secrets management solution.