# What Are the Default Security Settings for ai-memory? A Complete Guide

> Discover ai-memory's secure-by-default settings. Learn how it protects your data by binding to localhost and requiring explicit opt-in for network access and authentication.

- Repository: [Fabio Akita/ai-memory](https://github.com/akitaonrails/ai-memory)
- Tags: security-guide
- Published: 2026-09-11

---

**ai-memory ships with a "secure-by-default" configuration that binds only to localhost (127.0.0.1:49374), accepts unauthenticated requests only from the same machine, and requires explicit opt-in for any network exposure or authentication features.** This design philosophy ensures solo developers can start immediately on a single workstation while preventing accidental exposure to external networks.

The **ai-memory default security settings** prioritize local development safety over convenience, implementing multiple layers of protection that must be deliberately disabled or configured to enable remote access. According to the akitaonrails/ai-memory repository, these defaults are enforced at the application level in [`src/bin/ai-memory.rs`](https://github.com/akitaonrails/ai-memory/blob/main/src/bin/ai-memory.rs) and documented comprehensively in [`docs/security.md`](https://github.com/akitaonrails/ai-memory/blob/main/docs/security.md).

## Default Bind Address and Network Isolation

By default, the server restricts all network access to the local machine only.

### Loopback-Only Binding

The server binds to **127.0.0.1:49374** (IPv4 loopback) unless explicitly configured otherwise. This setting ensures that only processes running on the same host can reach the HTTP endpoints, effectively isolating the memory server from any external network traffic.

### Rejection of Non-Loopback Access

If you attempt to bind to a non-loopback address (such as `0.0.0.0` or a specific LAN IP) without additional security measures, the server **rejects the configuration** and refuses to start. This fail-closed behavior prevents accidental exposure during development.

To enable external access, you must explicitly choose one of these options:

- **Set `AI_MEMORY_AUTH_TOKEN`** – Configures a static root bearer token required for all remote requests
- **Use `--allow-insecure-no-auth`** – Dangerous flag that permits plain-HTTP access without authentication (never recommended for production)

## Authentication and Encryption Defaults

The default configuration deliberately omits authentication and transport encryption, assuming these concerns will be handled externally when needed.

### No Authentication on Localhost

When bound to the loopback interface, **ai-memory requires no bearer token**. The server accepts requests without an `Authorization` header, as the network isolation provides sufficient protection for single-user development.

### No Built-in TLS Termination

The binary **never terminates TLS itself**. All traffic operates over plain HTTP, requiring an external reverse proxy (such as Caddy, NGINX, or Cloudflare Tunnel) to provide HTTPS encryption. The repository provides a complete guide in [`docs/https-via-proxy.md`](https://github.com/akitaonrails/ai-memory/blob/main/docs/https-via-proxy.md) and a working example in [`docker/compose.tls.caddy.yml`](https://github.com/akitaonrails/ai-memory/blob/main/docker/compose.tls.caddy.yml).

### Host Allow-List Protection

By default, **no hosts are allowed** when binding to non-loopback addresses. You must explicitly set `AI_MEMORY_ALLOWED_HOSTS` (comma-separated hostnames or IPs) to protect against DNS rebinding attacks. Without this setting, the server rejects requests even after authentication is configured.

## Optional Security Hardening

While the defaults optimize for local development, production deployments require explicit configuration of additional safeguards.

### Bearer Token Authentication

To expose ai-memory beyond localhost, generate a root token and set the environment variable:

```bash

# Generate a secure root token (store this securely)

export AI_MEMORY_AUTH_TOKEN=$(ai-memory generate-auth-token)

# Bind to all interfaces (requires the token to be set)

ai-memory --data-dir /data \
  --config <(printf "[server]\nbind = \"0.0.0.0:49374\"\n") \
  serve

```

Once configured, all `/mcp`, `/hook`, `/handoff`, `/workstream/*`, and `/admin/*` endpoints require the header `Authorization: Bearer $AI_MEMORY_AUTH_TOKEN`.

### Secure Cookie Configuration

When exposing the server beyond loopback—typically behind an HTTPS reverse proxy—you must enable secure cookie attributes:

```bash
export AI_MEMORY_AUTH__SECURE_COOKIE=true

```

This setting forces the session cookie to include the `Secure` flag, ensuring browsers transmit it only over HTTPS connections.

### Rate Limiting for Hooks

By default, **rate limiting is disabled** (`AI_MEMORY_HOOK_RATE_PER_SEC=0`). For shared or public hook endpoints, enable token-bucket limiting:

```bash
export AI_MEMORY_HOOK_RATE_PER_SEC=10    # Tokens per second per actor

export AI_MEMORY_HOOK_RATE_BURST=20      # Maximum burst capacity

```

## Implementation in Source Code

These defaults are enforced across specific files in the akitaonrails/ai-memory codebase:

- **[`docs/security.md`](https://github.com/akitaonrails/ai-memory/blob/main/docs/security.md)** – Canonical documentation describing the bind address restrictions, authentication handling, and TLS recommendations
- **[`src/bin/ai-memory.rs`](https://github.com/akitaonrails/ai-memory/blob/main/src/bin/ai-memory.rs)** – CLI entry point that parses `--allow-insecure-no-auth` flags and `AI_MEMORY_AUTH_TOKEN` environment variables
- **[`crates/ai-memory-mcp/src/server.rs`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-mcp/src/server.rs)** – HTTP server implementation that enforces authentication checks on protected routes based on the configuration state
- **[`docker/compose.tls.caddy.yml`](https://github.com/akitaonrails/ai-memory/blob/main/docker/compose.tls.caddy.yml)** – Reference implementation showing TLS termination via Caddy reverse proxy

The enforcement logic resides primarily in the server initialization code, where the bind address and authentication state are validated before the HTTP listener starts.

## Quick-Start Configuration Examples

### Local Development (Default Settings)

```bash

# Initialize data directory (single-user mode)

ai-memory --data-dir ~/.local/share/ai-memory init

# Start with default security (localhost only, no auth required)

ai-memory --data-dir ~/.local/share/ai-memory serve

```

Access the server at `http://127.0.0.1:49374` without any authentication headers.

### LAN Deployment with Authentication

```bash

# Generate and export token

export AI_MEMORY_AUTH_TOKEN=$(ai-memory generate-auth-token)

# Configure allowed hosts for DNS rebinding protection

export AI_MEMORY_ALLOWED_HOSTS="ai-memory.local,192.168.1.10,127.0.0.1"

# Enable secure cookies (assuming HTTPS via reverse proxy)

export AI_MEMORY_AUTH__SECURE_COOKIE=true

# Start with explicit bind configuration

ai-memory --data-dir /var/lib/ai-memory \
  --config <(printf "[server]\nbind = \"0.0.0.0:49374\"\n") \
  serve

```

## Summary

- **ai-memory defaults to localhost-only binding** (127.0.0.1:49374) with no authentication required for local development
- **External network access is blocked by default** unless you explicitly configure `AI_MEMORY_AUTH_TOKEN` or use the dangerous `--allow-insecure-no-auth` flag
- **No TLS termination is built-in**; HTTPS must be provided by an external reverse proxy such as Caddy or Cloudflare Tunnel
- **Host allow-listing (`AI_MEMORY_ALLOWED_HOSTS`) is mandatory** for non-loopback bindings to prevent DNS rebinding attacks
- **Rate limiting and secure cookies are opt-in features** configured via environment variables for production hardening

## Frequently Asked Questions

### Does ai-memory require authentication by default?

No. When bound to the default localhost address (127.0.0.1), ai-memory accepts requests without any bearer token or authentication headers. Authentication becomes mandatory only when you configure the server to listen on external network interfaces by setting `AI_MEMORY_AUTH_TOKEN`.

### How do I enable HTTPS for ai-memory?

You cannot enable HTTPS directly in ai-memory because the binary does not support TLS termination. Instead, deploy a reverse proxy such as Caddy, NGINX, or Cloudflare Tunnel in front of ai-memory. The repository provides a working example in [`docker/compose.tls.caddy.yml`](https://github.com/akitaonrails/ai-memory/blob/main/docker/compose.tls.caddy.yml) and documentation in [`docs/https-via-proxy.md`](https://github.com/akitaonrails/ai-memory/blob/main/docs/https-via-proxy.md).

### What happens if I try to bind ai-memory to 0.0.0.0 without setting an auth token?

The server will refuse to start and exit with an error. The source code in [`src/bin/ai-memory.rs`](https://github.com/akitaonrails/ai-memory/blob/main/src/bin/ai-memory.rs) enforces a safety check that prevents binding to non-loopback addresses without either `AI_MEMORY_AUTH_TOKEN` configured or the explicit `--allow-insecure-no-auth` flag (which is not recommended).

### Why does ai-memory reject requests even after I set an auth token?

If you have configured `AI_MEMORY_AUTH_TOKEN` but neglected to set `AI_MEMORY_ALLOWED_HOSTS`, the server rejects requests as a protection against DNS rebinding attacks. You must explicitly define the allowed hostnames or IP addresses in the `AI_MEMORY_ALLOWED_HOSTS` environment variable when exposing the server beyond localhost.