Security at PlanVault™

1. Our approach

PlanVault™ is currently software for customer-controlled deployment. Our security model centers on per-organization cryptographic isolation, minimizing secrets and personal data processed by the application (including BYOK for AI), and describing only controls that exist in shipped code or documented deployment configuration. Where a capability is missing or customer-operated (for example third-party certification, a published penetration-test report, SIEM integration, ingress hardening, or backup policy), we say so explicitly. See Sections 9, 10, and 15.

2. Deployment model and data boundary

There is no PlanVault™-operated hosted environment for customer production data at this stage. Customer production deployments run inside infrastructure selected and controlled by the customer, such as the customer VPC, private cloud, on-premise environment, or a managed environment operated on the customer's behalf.

Typical deployment components include Keycloak or another OIDC-compatible identity provider, LiteLLM or an equivalent internal AI-routing proxy, PostgreSQL, Redis, object / artifact storage where configured, and nginx or another reverse proxy / ingress layer. The customer decides where those components run, which infrastructure providers are used, and which logs or telemetry leave the environment.

Data residency and international-transfer posture are therefore deployment-specific. If a customer connects external AI providers, email systems, monitoring tools, object stores, or managed databases, those vendors are part of the customer's operating model and should be assessed under the customer's procurement and data-protection process.

3. Encryption in transit and at rest

In transit. External HTTPS traffic should be terminated at the customer-managed ingress with TLS 1.2+ and modern cipher suites. The admin console, Runtime API, inbound webhook triggers, and outbound lifecycle webhooks are designed to run over HTTPS. Internal service-to-service traffic should stay inside the customer network boundary and can be further protected by the customer's service mesh or private-network controls.

At rest — tenant data. Sensitive tenant data is encrypted with AES-256-GCM using a per-organization Data Encryption Key (DEK). Each encryption operation uses a fresh 12-byte nonce and produces a 16-byte authentication tag; tampered ciphertext is rejected on decryption rather than silently returning corrupt data. The encrypted classes include: organization secrets, project secrets, session-scoped secrets, stored AI provider credentials, session event payloads (chat content and tool results; tool-start parameter telemetry is minimized to bounded keys/counts with secret/PII-like key names redacted), and encrypted PII columns on the membership table.

At rest — storage layer. Application-level ciphertext should be backed by customer-managed storage encryption for databases, disks, object stores, snapshots, and backups. The exact infrastructure encryption controls depend on the customer deployment target.

Policy acknowledgement evidence. When a customer-controlled deployment asks a console user to acknowledge the Privacy Policy, Public Terms, or a deployment-specific policy notice, the product records the acknowledged versions, timestamp, client IP as resolved from trusted ingress headers, and a truncated User-Agent string. This evidence is visible in the user's own data export where available and is deleted on account erasure.

4. Key management

Envelope encryption. Application-level encryption uses the envelope pattern: each organization has its own Tink AES256_GCM keyset (DEK), wrapped by a Key Encryption Key (KEK) provided via Google Tink. In customer deployments the KEK is supplied by the deployment operator, commonly as a local Tink keyset injected via the `TINK_LOCAL_KEYSET_JSON` environment variable or through a customer KMS integration. The operator is responsible for protecting that value using a secrets manager, sealed env injection, or equivalent control. Plaintext keyset material exists only in application memory; per-organization AEAD primitives are cached with a short TTL to minimize re-derivation overhead.

DEK caching. For performance, the plaintext DEK is held in a per-organization in-memory cache keyed by its wrapped ciphertext so that repeated KMS Decrypt calls are avoided; invalidation happens on DEK rotation.

DEK rotation. Each organization DEK has a version counter. An authorized organization administrator (OWNER or ADMIN role) can trigger rotation through the admin API; a background worker re-encrypts dependent rows in batches, after which the old DEK is retired. During a healthy in-progress rotation, new encrypted writes use the pending DEK version; if rotation metadata is inconsistent and the pending key is unavailable, those writes fail closed with HTTP 409 rather than falling back to stale key material.

HMAC key. A dedicated 32-byte HMAC signing key is required and used for deterministic pseudonymization of external user identifiers (see Section 14); it is never the same value as the KMS CMK material.

Two-layer key hierarchy. Customer ciphertext at the application layer is protected by the per-organization DEK; the DEK itself is wrapped by the customer deployment's KEK. On organization deletion, only the DEK is destroyed — the KEK continues to exist and protect other organizations. Ciphertext previously written under the destroyed DEK becomes mathematically unrecoverable, including any copies in short-rotation backups once the key material is gone.

Routine DEK rotation is not the same as destruction. When an authorized administrator triggers organization-DEK rotation through the admin API, the previous DEK version is marked retired and remains available to decrypt legacy ciphertext while the background re-encryption worker progresses; this is required for correctness and does not, by itself, provide crypto-shred. Only organization-level deletion (Section 11) — which deliberately and permanently destroys the organization-scoped DEK material — yields the crypto-shred guarantee. Rotation and destruction are deliberately separate operations.

5. Authentication and access control

Admin console (humans). Interactive admins authenticate through Keycloak using OpenID Connect. Our API verifies JWT signatures against the Keycloak JWKS endpoint with a short (5-minute) cache and automatic refresh on unknown key IDs; signature, expiration (exp), and not-before (nbf) claims are checked on every request. MFA, password policies, and session lifetime are enforced at the Keycloak realm and are configurable by the operator.

Runtime API (services). Machine clients authenticate with Project API Keys issued per project. The plaintext key is shown exactly once at creation (with a short four-character preview retained for console display) and is stored only as a Base64-encoded SHA-256 hash. Authentication therefore cannot be recovered from a database backup alone.

Scoped authorization. Every Project API Key row stores an explicit scope list in HRN format (for example hrn:project:session:create, hrn:project:session:*, hrn:project:*). Each secured Runtime route declares the scope it requires; the server allows the call only if a stored scope on the matching key covers that requirement via left-to-right segment comparison with * wildcard support. A key that belongs to a different project is rejected (403) before the business logic runs.

Session-level provenance. Runtime session rows record their creator (API key id or console user id). A project API key may use only sessions it created. JWT callers with organisation role MEMBER may use only sessions they started themselves. JWT callers with OWNER, ADMIN, or DEVELOPER may access any session in the project via Runtime routes (including legacy rows where provenance metadata is absent). Owner/Admin-only Admin API operations (for example deleting all sessions in a project, audit exports, or certain DSAR tooling) remain separately gated. Sensitive administrative actions are recorded in the organisation audit log where the product emits them.

Key lifecycle. Admin endpoints expose create, rotate, patch (name / scopes), and delete for non-primary keys; rotation of any key returns the new plaintext exactly once. Revocation (deletion) is immediate — revoked keys no longer authenticate, even for sessions they previously started.

Org RBAC. Organization membership has four roles: OWNER (full control; last-owner protection prevents lock-out), ADMIN (manage resources, members, secrets, models; cannot delete the organisation), DEVELOPER (engineering and catalog surfaces — tools, LLM, integrations, scenarios, spend reads, org secrets — aligned with the product; cannot manage org membership, primary API-key lifecycle, audit-log listing, or other Owner/Admin-only controls), MEMBER (read-only org resources in the console; Runtime JWT HRN scopes are a subset). Role transitions that would remove or demote the last OWNER are rejected.

Automation and integrations. Every `/admin/v1/*` call uses the same contract as the interactive console: a verified Keycloak access JWT in `Authorization: Bearer`. For CI or scripts, obtain a token from your realm (for example the OAuth2 token endpoint) under your organization's security policy. There is no separate static “admin secret” that replaces a JWT for these Admin routes. Cross-organization platform operations should use deployment-operator controls rather than the shared product Admin API.

Client-side secret storage (the browser). PlanVault™ does not write authentication secrets or API-key plaintext to browser persistent storage in the admin console. Keycloak JWTs are held in `keycloak-js` in-memory state; Keycloak session cookies are HttpOnly. Runtime API keys used in the built-in console stay in React in-memory state unless stored in server-side UI preferences gated by the same JWT. Legacy pre-2026-Q2 local-storage auth keys are force-cleared on page load. The public planvault.ai website stores only non-secret display preferences in Local Storage; see https://planvault.ai/cookies. XSS mitigation (Content-Security-Policy, output sanitization, strict React rendering) is covered in Section 9.

6. Tenant isolation

Logical isolation. All tenant-scoped tables carry an organization identifier, and every admin query is scoped by the authenticated caller's organization membership before execution. Cross-organization reads are rejected at the API boundary; the database layer uses parameterized queries throughout so user-supplied identifiers cannot alter query shape.

Cryptographic isolation. Because each organization has its own DEK, ciphertext written for one tenant is unreadable by any code path that has not explicitly loaded that tenant's DEK. Where a customer KMS integration is used, decrypt permission should be gated by the IAM / service-account policy attached to the application runtime.

Project-level isolation inside an organization. A Runtime request authenticated by a Project API Key carries its project id in the URL path; the server refuses to serve data outside the project that issued the key, even when the caller is a member of the owning organization.

7. Secrets management

Layered vault. Secrets are stored at three scopes — organization, project, and session — each encrypted with the organization DEK. At execution time they are merged in that order (session overrides project, project overrides organization) and combined with synthetic entries derived from verified AI provider credentials.

Never sent to the LLM. Secret values are never placed into the prompt sent to the language model. The planner receives only each secret's name, type, and description; the model is instructed to reference configured secrets by variable name in tool arguments (for example apiKey=OPENAI_API_KEY). At execution, the FSM resolves names to plaintext and injects them into tool HTTP headers, query strings, or bodies.

Never logged, never exported. Decrypted secret material does not appear in session events (which are themselves stored encrypted), application logs (values are masked), API responses, or the GDPR data export.

Session-scoped lifecycle. Ephemeral per-session secrets are stored in a dedicated table whose foreign key to the session row carries ON DELETE CASCADE: when a session is deleted (by retention job, DSAR erasure, or explicit admin action), its session-scoped secrets are removed in the same transaction, so there is no window in which orphaned ciphertext can persist after the owning session is gone.

8. Bring Your Own Key (BYOK) for AI providers

You supply the credentials. Customers who want to use AI features configure their own supported AI provider/model and provider credentials in their PlanVault™ organization. Without a verified provider credential in your own organization, chat is blocked — we do not silently route your traffic through any shared or platform-operator provider account.

Storage of your provider credentials. Each provider credential you add is encrypted at the application layer with your organization's DEK (AES-256-GCM, 12-byte nonce + 16-byte authentication tag) and stored in `organization_llm_providers`. The plaintext credential exists in application memory only for the duration of a single LLM call and only in the request that originated in your organization; it is never written to logs, never included in session events, never returned by the admin API after creation (the UI returns only the last four characters for operator recognition), and never exported by the GDPR export endpoint.

Scoped to your org, never shared. Your provider credentials are scoped to the organization that added them. We do not have a code path that reads provider credentials belonging to one organization while serving a request from another organization, and every call from the planner / executor to a provider happens inside an organization-scoped context that carries exactly that organization's DEK. We do not maintain a shared AI-provider account for customer traffic; if your credentials are revoked or exhausted your AI features stop working, and PlanVault™ does not silently fall back to any other account.

What the LLM actually sees. When we call the provider, we send the prompt, the tool-specification metadata (names, types, descriptions — not secret values; see Section 7), and the contents of the conversation that the planner needs to resolve the current turn. We do not attach other organizations' data, and we do not attach platform-operator credentials or platform-internal identifiers that would be meaningful to the provider.

Customer-selected provider relationship. Because AI providers are called using your credentials from your deployment, the provider's terms, data-processing terms, and privacy policy apply directly to that processing. Your organization decides which provider to use, whether traffic may leave your network boundary, and which no-training / enterprise options are required.

No training on your content. Customer runtime content (prompts, tool calls, session events) is not used to train any model that PlanVault™ operates. Whether any on-provider training occurs is governed by your agreement with that provider; we recommend you select a no-training / enterprise tier at the provider and we will honor whatever configuration your provider account enforces.

Semantic Routing Cache (tenant embeddings). Separately from LLM generation calls, where the Semantic Routing Cache feature is enabled for the organization, PlanVault™ derives vector embeddings from workflow queries through the customer-configured BYOK embedding provider using your credentials, then stores the resulting vectors only in your tenant's PostgreSQL data under your organization DEK. Raw workflow queries are not stored as `scenario_query_vectors`; stored vectors are not shared across tenants and are not used to train any foundation model. They exist solely to optimize routing and latency inside your tenant; the organization owner can disable the feature at any time, which triggers immediate deletion of stored vectors. Details and legal bases are in the Privacy Policy (Sections 5 and 14).

Rotation and revocation on your side. You can rotate or revoke your provider credentials inside your provider's console at any time; we do not need to be notified. The next call after the provider rejects the old credential simply fails, and you can upload the new one in the PlanVault™ admin console.

9. Application security and secure development

Supply chain. The backend is a JVM service (Scala, Apache Pekko) and the frontend is a Vite + React + TypeScript app. Dependencies are pinned at build time; dependency vulnerability scanning and an SBOM pipeline are part of our release workflow.

Public SBOM (CycloneDX). We publish a CycloneDX Software Bill of Materials (1.5+) for the API runtime image at https://planvault.ai/sbom/latest.json, with an immutable per-release archive published alongside it (files named YYYY-MM-DD-git-sha.json under the same /sbom/ path) and a machine-readable index (filename, SHA-256 hash, components count, age) at https://planvault.ai/sbom/manifest.json. The index is also discoverable via /.well-known/sbom and a <link rel="alternate" type="application/vnd.cyclonedx+json"> tag in the homepage <head>. SBOMs are regenerated on every release and additionally on a weekly schedule (so a freshly disclosed CVE in an unchanged pinned dependency surfaces within 7 days, not at the next release). Each entry in the manifest carries a content_hash that is stable across re-scans of the same image, so procurement can verify byte-level integrity. Frontend SBOM is generated for internal vulnerability scanning but is not currently published; per-tenant data never lives in the browser bundle.

Vulnerability gating. Our SBOM workflow (which runs after every release and on a weekly schedule) fails on any CRITICAL or HIGH severity finding from Trivy against the API Docker image. A failed scan triggers either remediation (dependency bump and new release) or a documented exception in our internal vulnerability register before the next release proceeds. MEDIUM and LOW findings are reviewed manually within 7 business days and not published on this page to avoid noise from non-exploitable transitive findings.

Parameterized data access. All database access uses typed, parameterized queries; string concatenation is not used to build SQL. ORM-style joins and paginated lists are bounded by explicit per-route limits.

Safe error responses. API error responses follow RFC 7807 (application/problem+json). An allow-list of safe internal messages is mapped to stable client strings; everything else is collapsed to a generic "internal error" message with a correlation id, while full stack traces stay in server logs. Public webhook endpoints in particular use a single uniform 404 so unauthenticated callers cannot infer whether a trigger exists, is disabled, or failed HMAC verification.

Webhook integrity. Inbound public webhook triggers require HMAC-SHA256 by default (the "none" auth method is rejected); signatures are computed over the raw JSON body and compared before any session is created. Outbound lifecycle webhooks are signed with HMAC over the raw body (X-Signature header) and must be delivered over HTTPS.

Rate limiting. Edge limits (nginx) bound per-URI request rates; optional Redis sliding-window limits back replay protection (Idempotency-Key) and guard pool exhaustion. With Redis disabled, idempotency is not enforced — see the production runbook for the required config.

Code review. Every change is reviewed before it reaches main; CI runs unit, integration, and end-to-end tests (Scala + TypeScript) before merge and before production release.

Penetration testing. We do not currently publish results of a third-party penetration test. Planned once we have enterprise customers or accelerator funding to commission one; see Section 15.

10. Logging, monitoring, and audit

Application logs. The API emits structured JSON logs including a request identifier, optional correlation / trace identifiers (X-Request-Id, X-Correlation-ID, W3C traceparent), and role-relevant metadata. Secret values, request bodies that could contain secrets, and decrypted session payloads are not logged.

Tenant-safe OpenTelemetry. Customer-operated deployments can export infrastructure traces, logs, and bounded metrics through OTLP over mTLS to the operator's collector or observability stack. Runtime correlation uses W3C trace context (`traceparent` / `tracestate`) plus `trace_id`, `span_id`, and a pseudonymous `organization_hash` derived with a separate observability HMAC key. Raw organization ids, project ids, session ids, user ids, email addresses, JWT claims, and payload values should not be used as telemetry attributes or metric labels.

Retention. Application / ingress / request logs are rotated according to the customer deployment's container, host, and SIEM policies. PlanVault™ does not require a dedicated external SIEM, but production deployments should define log retention, access controls, and redaction review before go-live.

Admin audit. Organization and project audit endpoints expose security-relevant operations for administrator review: member role changes, API-key issuance / rotation / revocation, DEK rotation, provider-credential changes, secret create / update / delete, retention-cutoff changes, organization or project deletion, DSAR export / erase actions, scenario and tool-catalog edits, and any other change with a tenant-wide or project-wide security or billing impact. Audit webhook payloads include `trace_id` when a request trace is available so SIEM or compliance pipelines can correlate the audit event with the deployment operator's distributed trace.

Health and uptime. Service health is exposed through application and infrastructure signals available to the deployment operator. Customer deployments should connect those signals to the customer's monitoring, alerting, and incident-management process.

11. Data retention and deletion

Per-organization session retention. Each organization has a session-retention cutoff in days (bounded between 1 and 1461). A daily job deletes sessions older than that cutoff together with their encrypted event payloads. Administrators can reduce the cutoff at any time in settings.

Organization deletion and crypto-shred. When an authorized administrator deletes an organization, the tenant enters a 7-day grace window during which it is invisible to all users but can be restored on written customer request. At the end of the window, deletion is finalized by crypto-shred: the organization-specific DEK is permanently destroyed and tenant records are purged. Any residual content in customer-managed backups becomes unrecoverable because the key needed to decrypt it no longer exists; physical backup expiry follows the customer's backup-retention policy.

Pekko journal cleanup and tool-parameter minimization. During execution, the ephemeral FSM journal stores tool-start telemetry as a bounded audit shape (parameter keys/counts only; secret/PII-like key names redacted). Raw tool parameter values are not written to new tool-start journal events or SSE/history payloads. After FSM execution reaches a terminal outcome, intermediate persistence entries in the ephemeral execution journal are deleted by a background reconciler. The reconciler first verifies that the authoritative encrypted session event mirror exists, so transient execution state is removed from the ephemeral execution layer without racing the long-term history store.

Data-subject erasure. Individual GDPR erasure requests are processed immediately through the admin export / erase endpoints and through the console-user self-service erase endpoint — the 7-day grace window above applies only to whole-organization deletion.

12. Backups and disaster recovery

Backups are customer-operated. The deployment operator is responsible for configuring PostgreSQL backups, any object / artifact store backups, Redis persistence if enabled, snapshot retention, encryption, restore testing, and access controls for backup artifacts.

Crypto-shred interacts with backups. Because tenant data is encrypted at the application layer with a per-organization DEK, destroying that DEK makes residual ciphertext in backups unrecoverable without further bulk deletion of backup artifacts. Section 11 describes the lifecycle.

Documented restore path. Deployment runbooks should cover database, object / artifact storage, key material, Redis state where relevant, and application configuration. PlanVault™ can provide product-level restore guidance, but actual RPO / RTO depends on the customer-operated environment.

13. Incident response and breach notification

Detection. Suspected incidents (unauthorized access, data exposure, integrity compromise) are raised through our support / privacy inboxes, through customer infrastructure alerts, or through application error rates and audit anomalies.

Containment and triage. On a confirmed incident we (a) contain the scope (revoking keys, rotating DEKs, disabling affected accounts), (b) preserve forensic evidence (logs, audit rows, affected ciphertext metadata), (c) determine whether personal data was affected, and (d) identify the controllers that need to be notified.

Notification timing. For incidents in customer-operated deployments, the customer is typically the first party with infrastructure logs, access records, and affected-data context. If PlanVault™ becomes aware of a product vulnerability or support-handled incident that may affect customer data, we notify affected customers without undue delay using the information available at that time. Customers remain responsible for regulator and data-subject notifications for their own deployment unless a Customer Agreement says otherwise.

Where we act as controller (for example for our own website visitors or account holders), we notify the competent supervisory authority under Article 33 GDPR and affected data subjects under Article 34 where required.

Sender domain. Breach notifications under GDPR Article 34 (where we are controller) and statements of reasons under DSA Article 17 are sent from notifications@planvault.ai. Operational support during incident handling may originate from security@planvault.ai or privacy@planvault.ai (those addresses can both receive replies). PlanVault™ never sends breach notifications from free webmail providers, third-party platforms, or domains other than planvault.ai — if you receive a message claiming to be a PlanVault™ breach notification from any other sender, do not act on it and contact security@planvault.ai to verify.

14. GDPR and subject rights

Console user self-service. Signed-in console users can export their own data through GET /admin/v1/me/data-export (a portable JSON package including policy-consent history) and request erasure through POST /admin/v1/me/data-erasure. These routes require the caller’s Keycloak-issued access token for the interactive user; they are not satisfied by credentials that do not represent that end user.

Tenant admin export and erase. For a business customer acting as controller, administrators can export all organization data and can export or erase data for a specific end user identified by externalUserId. The erase endpoint removes all sessions for that user within the organization, cascading encrypted events and session-scoped secrets.

Pseudonymization of external user ids. External user identifiers provided by your integration are hashed with HMAC-SHA256 before storage so that the original identifier cannot be recovered from the database alone. The same identifier always maps to the same hash within a given deployment, so correlation and DSAR fulfilment remain possible.

Policy acknowledgement audit. Each acknowledgement of the Privacy Policy, Public Terms, or deployment-specific policy notice produces an append-only row with the acknowledged version, timestamp, client IP, and User-Agent — supporting GDPR Article 7(1) demonstrable-consent evidence where consent is the legal basis and otherwise supporting contractual or audit evidence under the applicable Customer Agreement.

Legal bases, international transfers, controller/processor roles, and privacy rights of EEA / UK / Switzerland residents are described in our Privacy Policy at https://planvault.ai/privacy.

15. Certifications and assurance

What we hold today. PlanVault™ is operated by a single Polish JDG; we do not currently hold SOC 2 Type I or Type II attestations, ISO/IEC 27001 certification, ISO/IEC 27701 certification, HIPAA / HITRUST / PCI-DSS attestations, or an active third-party penetration-test report.

What we rely on instead. We rely on (a) the product controls described on this page, aligned with GDPR Article 32 security principles; (b) the customer's infrastructure, identity, logging, backup, and network controls for the deployment environment; and (c) vulnerability scanning, SBOM publication, code review, and release gating for the software we ship. Infrastructure-provider certifications belong to the customer-selected environment and do not substitute for PlanVault™ product assurance.

Roadmap conditions. A SOC 2 Type I engagement, a third-party penetration test, and a formal ISMS documentation pack are scoped for the year following our first enterprise customer win or admission to a pre-seed accelerator program (whichever comes first), because either trigger provides the budget and minimum team size that make those activities meaningful rather than ceremonial. We will update this page when either is in progress.

Customer-specific diligence. We respond in good faith to vendor security questionnaires (CAIQ, SIG-lite, and custom) for prospective customers under NDA; see Section 18.

16. Responsible disclosure and reporting a vulnerability

Where to send. Email security@planvault.ai (dedicated inbox for vulnerability reports and security reviews) or privacy@planvault.ai (if the report has a privacy / data-subject dimension) with a description of the issue, reproduction steps or a minimal proof of concept, and any affected account identifiers. If you need to send sensitive evidence, say so in your first message and we will arrange an encrypted channel.

What we ask. Please give us a reasonable remediation window before public disclosure (we aim to triage within 5 business days and to fix or mitigate high-severity issues within 30 days). Do not access other customers' data, do not degrade service for others, and do not perform denial-of-service testing against production. Limit automated scanning to accounts you own.

What you can expect. Acknowledgement within 5 business days, a triage decision (accepted / needs-more-info / not-applicable) within 10 business days, regular status updates until the report is resolved, and public credit in our release notes if you would like it. We do not currently run a paid bug-bounty program.

Out-of-scope. Reports based solely on automated scanner output without a demonstrated impact, best-practice recommendations (for example missing security headers on the marketing site) without a concrete exploit, social engineering of our staff, and denial-of-service against infrastructure you do not own or have explicit permission to test.

17. Shared responsibility

What PlanVault™ is responsible for. Secure product design and shipped software controls: authentication verification, application-level encryption, organization isolation, scoped project API keys, logging minimization, subject-rights fulfilment routes, SBOM publication, and coordinated vulnerability handling.

What the Customer is responsible for. Operating the deployment environment: identity-provider configuration, MFA and password policy, ingress TLS, network segmentation, host and container hardening, database / storage encryption, backups, monitoring, SIEM retention, role assignments, project API-key distribution and rotation, protection of KEK / secrets-manager material, AI provider account selection and terms, and what data is submitted into prompts and tool payloads.

18. Contact and requesting documentation

Security questions, vendor questionnaires, and vulnerability reports: security@planvault.ai (see Section 16). Privacy, data-subject rights, and breach notifications: privacy@planvault.ai. General support: support@planvault.ai. In practice all three addresses reach the same operator.

Upon request under a mutual NDA we share product-security documentation such as SBOM references, data-flow notes, deployment guidance, the vulnerability-management summary, and relevant runbook excerpts for backup and disaster-recovery planning.

Postal: Bohdan Matviichuk, ul. Dziewanny 21/19, 20-539 Lublin, Poland. VAT / NIP: PL7123452217.

19. OWASP Agentic Security Top 10

The OWASP Agentic Security Top 10 is a threat list for autonomous AI agents published in 2025 as part of the OWASP Agentic Security Initiative (ASI). It is distinct from the classic OWASP Web Application Security Top 10: agentic threats cover prompt injection, excessive agency, insufficient monitoring of agent actions, and lack of human oversight — not just HTTP-layer vulnerabilities.

PlanVault™ covers 9 of 10 categories through controls built into the execution pipeline (FSM tool gates, prompt-safe secrets, per-tenant encryption, HITL checkpoints) — not through a policy overlay alone. Microsoft's Agent Governance Toolkit (AGT) documents 10/10 coverage with formal RFC specs and conformance tests; we reference AGT as a complementary policy-engine benchmark, while PlanVault™ is the execution runtime where these controls are enforced.

AST-08 (Data and Model Poisoning) is honestly partial in the current release: routing vectors are stored encrypted and isolated per-tenant, and the organization owner can purge them on demand, but active adversarial vector detection (anomaly detection in embedding space, vector integrity verification) is not implemented. We do not claim full AST-08 coverage in security questionnaires.

References: OWASP Agentic Security Initiative — https://genai.owasp.org/initiatives/agentic-security-initiative/ ; Microsoft Agent Governance Toolkit (AGT) OWASP mapping — https://github.com/microsoft/agent-governance-toolkit

20. EU AI Act (Regulation (EU) 2024/1689)

Certain controls implemented in PlanVault™ may assist deployers in meeting obligations that can arise under Articles 10–15 of the EU AI Act when PlanVault™ is used as part of a high-risk AI system. Whether PlanVault™ forms part of a high-risk AI system depends on the specific use case and deployment context; PlanVault™ itself does not classify customer deployments under the Act.

Technical documentation under Article 11 is in progress but not complete at this release. No conformity assessment has been conducted. Whether a conformity assessment is required depends on the classification of the deployed AI system under the EU AI Act. The EU AI Act does not currently provide a general "AI Act certification" that can be claimed for an AI platform in the abstract; compliance obligations depend on the specific role (provider, deployer, importer, distributor) and use case.

Customers using managed cloud AI platforms should evaluate the visibility and documentation available for their specific deployment model when preparing compliance documentation.