title: Security & Compliance description: Audit trails, secret detection, access control, and air-gapped operation in phorvec.
Security & Compliance
phorvec is designed to run entirely inside your trust boundary. Every feature that touches sensitive data — storage, retrieval, team sharing — has a corresponding security control. This page describes the security architecture and the compliance posture it supports.
Audit Trail
Every operation that writes, reads, or deletes data is recorded in an append-only audit log stored inside the agent's .avdb file. The log is written in JSONL format (one JSON object per line) and cannot be modified after the fact — only appended to.
Per-Operation Metadata
Each audit record contains:
| Field | Description |
|---|---|
timestamp | ISO 8601 UTC timestamp |
operation | Tool name (e.g., memory_store, context_retrieve) |
agent_id | The agent that performed the operation |
correlation_id | A UUID linking related operations in a single request chain |
status | success or failure |
metadata | Operation-specific details (query hash, item count, error code) |
Correlation IDs make it possible to trace a complete request through Nexus, HandleManager, and the storage layer even when multiple operations are composed in a single MCP tool call.
Daily Rotation
Audit logs rotate daily. Each rotated file is named with the date it covers (e.g., audit-2026-03-28.jsonl). Rotated logs are kept for the duration specified by the audit_retention_days setting in config.toml. The current day's log remains in the .avdb file; rotated logs are written to the audit export directory.
Security Tools
| Tool | Purpose |
|---|---|
security_audit | Query the audit log with filters (time range, agent, operation, status) |
failure_summary | Aggregate failed operations by type and agent over a time window |
security_scan | Run a point-in-time scan of stored content for secrets and policy violations |
security_scan is distinct from the pre-storage scanner (described below): it scans content that is already in the database, useful for retroactive policy enforcement after a policy change.
Secret Detection
phorvec scans all content before it is written to disk. If a write operation contains a recognized secret pattern, phorvec applies the configured policy before any data is persisted.
Detected Patterns
The scanner recognizes common secret formats including:
- API keys (OpenAI, Anthropic, AWS, GCP, Azure, GitHub, Stripe, and others)
- OAuth tokens and refresh tokens
- JWT tokens
- Private key blocks (PEM format)
- Connection strings containing credentials
- Personally Identifiable Information (PII): email addresses, phone numbers, Social Security Numbers, credit card numbers
The pattern library is updated with each phorvec release.
Policies
Two policies govern what happens when a secret is detected:
| Policy | Behavior |
|---|---|
reject | The write operation is aborted and an error is returned to the caller. Nothing is stored. |
redact | The secret value is replaced with a placeholder (e.g., [REDACTED:api_key]) and the sanitized content is stored. |
Set the policy in config.toml:
[security]
secret_policy = "reject" # or "redact"
Denied Path Patterns
You can configure glob patterns for file paths that should never be indexed by the RAG pipeline, regardless of content:
[security]
denied_path_patterns = [
"**/.env",
"**/.env.*",
"**/secrets/**",
"**/credentials/**",
"**/*.pem",
"**/*.key"
]
Any rag_index_file or rag_index_directory call that would index a file matching a denied pattern is rejected before the file is read.
Access Control
Per-Agent Isolation
The foundational access control mechanism in phorvec is per-agent isolation at the file level. Each agent's .avdb file is only accessible through that agent's authenticated session. An agent cannot open, read, or write another agent's database file through the MCP interface.
At the OS level, .avdb files inherit the permissions of the directory they live in. For sensitive deployments, restrict the data directory to the user account running phorvec:
chmod 700 ~/.phorvec/data
Team Sharing Modes
When agents collaborate through the team features, sharing is governed by the team's configured mode. See Core Features — Team Collaboration for the full description of FULL, PROTECTED, and ISOLATED modes.
The key security property: even in FULL mode, the team shared pool is a separate database artifact from any individual agent's private store. Joining a team does not give a member access to the private memories of other members.
Project Scoping
Teams can be scoped to a project, which limits which agents can join and which operations are permitted within the team context. Project scoping is set at team creation time and cannot be widened without owner authorization.
Air-Gapped Operation
phorvec is designed to operate with zero network egress. All embedding and search computation runs locally.
Local ONNX Embeddings
The embedding model ships as an ONNX file bundled with the phorvec binary. Embedding generation runs in-process using the ONNX Runtime. No API call is made to an external embedding service. The model used is nomic-embed-text (137M parameters), chosen for the quality/size tradeoff appropriate for local use.
To use a different model, place an ONNX-format embedding model in the configured embedding.model_path directory and update config.toml. phorvec will load any ONNX model that produces a fixed-dimension float32 embedding vector.
Zero Cloud Dependency
phorvec has no telemetry, no license server, no analytics beacon, and no required external service. Once installed, it operates indefinitely without any outbound network access.
.vlbrain Bundles
Context snapshots exported as .vlbrain files are self-contained and include pre-computed embeddings. Transferring knowledge between air-gapped environments requires only copying a file — no re-embedding and no network access at the destination.
No Mandatory Sync
There is no sync mechanism in the Community or standard deployments. Agent databases live where you put them. Enterprise deployments can opt into a sync server (see Enterprise Features), but sync is always opt-in and configurable to stay within a private network.
Compliance Posture
SOC 2 Readiness
phorvec supports the technical controls commonly required for SOC 2 Type II audits:
- Audit logging: Append-only, tamper-evident JSONL logs with per-operation metadata
- Access control: Per-agent isolation, team sharing modes, project scoping
- Secret detection: Pre-storage scanning with reject/redact policies
- Retention policies: Configurable retention windows, sweep, and purge with grace periods
- Local-only operation: No third-party data processors in the default configuration
HIPAA Readiness
For deployments where agents handle protected health information (PHI):
- PII detection in the secret scanner catches common PHI patterns (names in combination with identifiers, medical record references)
- Audit trails provide the access logging required by the HIPAA Security Rule
- Retention policies enforce the minimum-necessary and data-lifecycle requirements
- Air-gapped operation eliminates the need for Business Associate Agreements with embedding providers
- Enterprise tier adds AES-256 encryption at rest and RBAC (see Enterprise Features)
GDPR Considerations
- The
memory_exportandmemory_gctools support the right of access and right to erasure workflows - Retention policies with defined purge windows support data minimization
- PII detection and the
redactpolicy reduce inadvertent PII storage - Local-only operation means data does not cross jurisdictional boundaries by default
Note: phorvec provides technical controls that support compliance. Whether a specific deployment meets a regulatory requirement depends on how those controls are configured and the broader organizational context. Engage your compliance and legal teams to assess your specific situation.
API Authentication
When running phorvec in server mode, all REST API requests are authenticated with API keys passed as Bearer tokens.
Authorization: Bearer pv_sk_live_xxxxx
Per-Key Rate Limiting
Each API key carries its own rate limit enforced with a sliding window algorithm. The default limit is 1,000 requests per minute. Limits can be customized per key at creation time or updated at any point without key rotation.
Auth Rate Limiting
Authentication failures are rate-limited separately from authenticated requests: a maximum of 5 failed authentication attempts per IP address per minute are permitted. Attempts exceeding this threshold are rejected with a 429 Too Many Requests response. This limit cannot be disabled in production mode.
Request Security
Request Size Limits
Incoming request bodies are capped at 10 MB by default. The limit is configurable via the MAX_REQUEST_SIZE_MB environment variable. Requests exceeding the limit are rejected before any processing occurs.
CORS Configuration
Cross-Origin Resource Sharing is controlled by the CORS_ORIGINS environment variable, which accepts a comma-separated list of allowed origins. In production mode, an empty or wildcard CORS_ORIGINS value is rejected at startup. In development mode, a permissive default is applied.
HTTPS Redirect
When FORCE_HTTPS=true, all inbound HTTP requests are redirected to HTTPS with a 301 permanent redirect. Enable this when phorvec is deployed behind a TLS-terminating reverse proxy.
Security Headers
The server injects the following HTTP response headers on every request:
| Header | Value |
|---|---|
X-Content-Type-Options | nosniff |
X-Frame-Options | DENY |
X-XSS-Protection | 1; mode=block |
Content-Security-Policy | Restrictive policy; script-src limited to self |
Strict-Transport-Security | max-age=31536000; includeSubDomains (when HTTPS is active) |
Environment-Based Strictness
phorvec's server applies different levels of security enforcement depending on the PHORVEC_ENVIRONMENT value.
| Environment | Behavior |
|---|---|
production | Strong JWT_SECRET_KEY is required (32+ characters); weak secrets cause a startup failure. CORS and HTTPS settings are validated strictly. |
staging | Weak configuration emits warnings in the log but does not block startup. Useful for pre-production validation. |
development | Insecure defaults (permissive CORS, no HTTPS requirement) are allowed. Never deploy to production with this setting. |
Setting PHORVEC_ENVIRONMENT=production is the recommended first step in the production security checklist.
License Validation
phorvec licenses are JWT tokens signed with RS256 (asymmetric RSA).
- Offline validation — the public key is bundled with the phorvec binary; no network request is made to validate a license. This supports air-gapped deployments and removes any dependency on an external license server.
- No phone-home — phorvec never contacts an external service to check license status, even on the initial activation.
- Graceful fallback — if a license key is absent, invalid, or expired, phorvec falls back to Community Edition limits (3 agents maximum, limited audit log) rather than refusing to start. Operations continue without interruption; only the features gated to higher tiers become unavailable.