Docs/Security & Compliance

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:

FieldDescription
timestampISO 8601 UTC timestamp
operationTool name (e.g., memory_store, context_retrieve)
agent_idThe agent that performed the operation
correlation_idA UUID linking related operations in a single request chain
statussuccess or failure
metadataOperation-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

ToolPurpose
security_auditQuery the audit log with filters (time range, agent, operation, status)
failure_summaryAggregate failed operations by type and agent over a time window
security_scanRun 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:

PolicyBehavior
rejectThe write operation is aborted and an error is returned to the caller. Nothing is stored.
redactThe 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_export and memory_gc tools support the right of access and right to erasure workflows
  • Retention policies with defined purge windows support data minimization
  • PII detection and the redact policy 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:

HeaderValue
X-Content-Type-Optionsnosniff
X-Frame-OptionsDENY
X-XSS-Protection1; mode=block
Content-Security-PolicyRestrictive policy; script-src limited to self
Strict-Transport-Securitymax-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.

EnvironmentBehavior
productionStrong JWT_SECRET_KEY is required (32+ characters); weak secrets cause a startup failure. CORS and HTTPS settings are validated strictly.
stagingWeak configuration emits warnings in the log but does not block startup. Useful for pre-production validation.
developmentInsecure 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.