---
title: "Security Hardening"
description: "Security measures in ZeroMemory — input validation, injection prevention, SSRF blocking, and data integrity."
canonical: "https://docs.ainative.studio/docs/zeromemory/security"
last-updated: "2026-10-03T21:47:10.764Z"
---

# Security Hardening

Source: https://docs.ainative.studio/docs/zeromemory/security

> Security measures in ZeroMemory — input validation, injection prevention, SSRF blocking, and data integrity.

# Security Hardening

ZeroMemory implements defense-in-depth security measures at every layer of the memory pipeline.

## Input Validation

All API inputs are validated via Pydantic models at the API boundary:

- **Content length**: Maximum content size enforced before processing
- **Namespace format**: Must match `global`, `session:<id>`, or `project:<id>`
- **Importance range**: Clamped to 0.0–1.0
- **Chunk size**: `max_chunk_size >= 1` enforced (prevents zero-division in chunker)
- **Entity types**: Validated against allowed ontology when provided

Invalid inputs return a structured `422 VALIDATION_ERROR` response with field-level error details.

## HTML Sanitization

The document ingestion pipeline strips dangerous content from HTML inputs:

| Removed Element | Reason |
|----------------|--------|
| `<script>` | XSS prevention |
| `<style>` | CSS injection |
| `<iframe>` | Clickjacking |
| `<svg>` | SVG-based XSS |
| HTML comments (`<!-- -->`) | Hidden content injection |

Sanitization runs before chunking — no unsanitized content reaches the embedding pipeline or storage.

## Graph Integrity

The knowledge graph enforces referential integrity:

- **Phantom edge prevention**: Both source and target entities must exist before an edge can be created. Attempts to create edges with non-existent endpoints raise `ValueError`.
- **Duplicate deduplication**: Graph extraction deduplicates nodes by ID before the referential integrity check, preventing duplicate entity creation.
- **Confidence bounds**: Edge and node confidence scores are clamped to [0.0, 1.0].

## SSRF Prevention

Subscriber webhook URLs and external API calls block private IP ranges:

```
10.0.0.0/8        (RFC 1918)
172.16.0.0/12     (RFC 1918)
192.168.0.0/16    (RFC 1918)
127.0.0.0/8       (loopback)
::1/128           (IPv6 loopback)
fc00::/7          (IPv6 unique local)
```

Attempts to register webhooks pointing to internal infrastructure are rejected with `400 BAD_REQUEST`.

## Webhook Verification

Stripe webhook events are verified using `construct_event` with the `STRIPE_WEBHOOK_SECRET`:

- Signature is validated against the raw request body
- Requests are rejected if `STRIPE_WEBHOOK_SECRET` is not configured
- Replay attacks are prevented by Stripe's built-in timestamp validation

## Command Injection Prevention

All subprocess execution uses `create_subprocess_exec` (not `create_subprocess_shell`), preventing shell metacharacter injection in:

- Sandbox code execution
- Git operations
- Build processes

## Path Traversal Protection

Deployment and file access paths block directory traversal sequences:

- `..` segments are rejected before any file system access
- Paths are resolved and validated against allowed directories
- Symlink traversal is prevented

## Memory-Specific Security

- **Namespace isolation**: Memories in one namespace are invisible to other namespaces unless `allow_cross_namespace` is explicitly set
- **User isolation**: All memory operations are scoped to the authenticated user's ID
- **Embedding isolation**: Each user's vectors are stored in user-scoped partitions
- **Consolidation isolation**: Reflection only processes memories belonging to the authenticated user