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:

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

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:

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 all-MiniLM-L6-v2 (22M parameters, 384-dimensional vectors, ~23 MB), 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 JSONL logs with correlation IDs and per-operation metadata (daily rotation, configurable retention)
• 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.

Network Authentication

phorvec's primary transport is stdio — process-local, no network surface. When you run it on a network with serve --transport sse or serve --transport http, bearer-token authentication kicks in.

Authorization: Bearer <api_key>

API Keys

API keys are managed by the apikey.rs subsystem. Each key:

• is stored as an Argon2 hash — the plaintext value is shown only once at creation
• maps to a ClientId used for RBAC and audit attribution
• can be revoked instantly; revocation takes effect on the next request

Rate Limiting

When configured, the middleware/rate_limit.rs layer enforces per-key request limits using a sliding window. Limits are set per key at creation time. Requests exceeding the limit get a 429 Too Many Requests.

TLS

phorvec does not terminate TLS itself. Run it behind nginx, Caddy, Traefik, or a cloud load balancer that terminates TLS, and bind phorvec to localhost on the LB host.

License Validation

phorvec licenses are signed with Ed25519 asymmetric signatures. Two formats ship:

• Compact V2 — PHORVEC-LICENSE-V2.<base64_payload>.<base64_signature> for online activation. Carries licensee, tier, max_projects, issued_at, expires_at, license_id. Place in ~/.phorvec/license.key or point quotas.license_file at it.
• File V1 — JSON envelope bound to a host identifier (VIN, device serial, hostname). For air-gapped industrial / embedded deployments. Supports not-before dates, grace periods, and feature flags.

Validation behaviour

• Offline. Validation runs locally against the embedded Ed25519 verifying key. No network request is made.
• No phone-home. phorvec never contacts an external service to check license status.
• Tamper-evident. A modified payload fails signature verification.
• Graceful fallback. An absent, invalid, or expired key drops to Community tier — phorvec still starts and serves Community-tier tools.
• Tier hidden, not just rejected. Tools above the validated tier are removed from tools/list and return -32003 if called directly.
• Config string ignored. Setting tier = "enterprise" in config.toml without a valid signed license has no effect — the license engine is the sole tier authority.

Security model

• The private signing key never ships in any released phorvec binary — it lives off-device in Teressoft Pty Ltd's licensing service.
• Reverse-engineering the binary exposes only the public verifying key, which cannot forge licenses.
• Production builds override the default dev verifying key via the PHORVEC_LICENSE_PUBLIC_KEY compile-time environment variable. Licenses signed with the dev seed (phorvec-dev-license-DO-NOT-USE!!) only verify against debug builds.

For the full license-key and license-file format specifications, contact support@phorvec.com.