Security and Vulnerability Disclosure

1. Purpose and Limits

This page describes security controls in the current Kanvify Service operated by Plus Ultra Industries, LLC. It is informational and does not create a warranty, service-level agreement, certification, or guarantee that an incident cannot occur. Controls may differ for experimental or third-party features.

2. Architecture and Tenant Boundaries

• Production sandbox workloads run in isolated Linux micro-VMs on compute infrastructure in Germany.
• Account- and workspace-scoped PostgreSQL tables use row-level security to help enforce tenant boundaries.
• Sandbox creation applies a per-sandbox outbound-network policy with a default-deny setting. A saved policy change may require the relevant sandbox lifecycle action before the backend applies it.
• Processes configured as services run inside the sandbox. Kanvify does not currently provide public Internet ingress or a public service URL for those processes.
• Application endpoints use authorization checks and rate limits. Rate limits may vary by endpoint or account and do not eliminate all abusive traffic.

3. Credentials and Authentication

• User API keys are stored using bcrypt, a one-way password hash, and are verified against that hash.
• OAuth client secrets are hashed. Short-lived execution-token identifiers are stored so tokens can be revoked.
• Recoverable integration credentials, including registry and customer-provided LLM provider credentials, are encrypted because the Service must use them on the customer’s instructions.
• Sessions are rejected and swept after 14 days of inactivity or 30 days from creation, whichever occurs first.
• OAuth token records are revoked through scheduled lifecycle sweeps.
• Customers are responsible for protecting account email access, credentials, provider keys, and the devices and software that use the Service.

4. Data Protection

• Service traffic uses encrypted network transport. We do not publish a blanket minimum TLS-version claim for every external and vendor-managed path.
• Sandbox isolation, row-level database security, scoped customer roles, and credential controls provide layered access boundaries.
• Selected administrative and security-relevant actions are logged with actor, action, time, and IP address. Session records separately include browser user agent.
• Operational access is limited by function for support requested by a customer, maintenance, security and abuse investigation, and legal compliance.
• No method of transmission, storage, or isolation is completely secure. Customers should keep independent copies of important data.

5. Data Lifecycle Controls

• Checkpoint records and their backend snapshots are pruned daily after the account-configured operational period, which defaults to 90 days.
• LLM response-cache entries stop being served at their workspace-configured time-to-live and expired request and response rows are purged by a recurring sweep.
• Sessions are swept at the 14-day idle or 30-day absolute limit.
• OAuth access and refresh-token records are revoked on scheduled thresholds.
• Processed Stripe webhook payloads are swept after 30 days.
• Minimized, de-identified billing records are retained according to tax, accounting, audit, and legal needs.
• Deleted data may remain in restricted backups for no more than 30 days before aging out, unless a legal hold applies.

Checkpoints are not a backup service. Customers must export data they need to preserve.

6. LLM Proxy Security Boundary

The optional LLM proxy is bring-your-own-provider only. The customer supplies an Anthropic or OpenAI credential, contracts with and pays the provider directly, and chooses the route. Kanvify encrypts the recoverable credential and is designed to keep it out of the sandbox while using it for routing.

Prompts, context, and responses leave Kanvify when transmitted to the selected provider and then fall within that provider account’s security and privacy terms. Workspace caching, if enabled, stores eligible request and response data until its configured time-to-live. Plus Ultra does not provide or bill an LLM and does not use Customer Content to train its own models.

7. Spend and Abuse Controls

Spend caps are best-effort. Usage can arrive with delay, so a cap is not a guaranteed maximum. When recorded usage breaches a cap, the Service suspends running sandboxes and blocks supported running or billable actions; delayed or already-started usage may still be chargeable.

We monitor for and may investigate and act on suspected abuse using proportionate account, usage, rate-limit, network-policy, operational, and report data. We do not claim automated cryptomining or attack detection, and no monitoring detects every event. See the Acceptable Use Policy.

8. Incident Response and Notifications

We maintain procedures to assess, contain, investigate, and mitigate suspected security incidents and to coordinate with affected providers and customers.

When Plus Ultra acts as a Processor and becomes aware of a Personal Data Breach affecting Customer Personal Data, it notifies the Customer Controller without undue delay. The Controller is responsible for notifying a Supervisory Authority within 72 hours after awareness where the GDPR risk threshold requires it and for notifying affected people without undue delay where the breach is likely to create a high risk, subject to applicable exceptions. When Plus Ultra acts as Controller, it provides notices as required by applicable law based on the applicable role and risk.

9. Vendors and Locations

Our Subprocessor List identifies infrastructure, database, storage, billing, email, customer-provided LLM routes, analytics, measurement, font, sign-in, and GitHub runner vendors, the data categories they receive, and their processing locations. We provide 30 calendar days’ advance notice of additions or replacements, subject to the urgent-replacement exception described there.

10. Reporting a Vulnerability

Report a suspected vulnerability to security@plusultra.industries. Include the affected asset, a clear description, reproduction steps, impact, and any request or event identifiers. Do not send live credentials, malware, exploit payloads containing another person’s data, or unnecessary personal information by ordinary email; ask for a safer transfer method if needed.

This page does not authorize security testing. Before scanning, penetration testing, sandbox-escape testing, load testing, or any activity beyond ordinary use, request written authorization and wait for an approved scope. Stop immediately if you access another person’s data, gain unintended access, or affect availability. Do not conduct denial-of-service, social engineering, persistence, lateral movement, or data exfiltration.

We may acknowledge and investigate good-faith reports, but we do not promise a bounty, a particular response time, public credit, or authorization outside an express written scope.

11. Customer Responsibilities

Customers should apply least privilege; rotate and revoke credentials; review workspace membership; configure network rules, quotas, and spend caps; patch their own software; avoid placing secrets in code or prompts; verify LLM outputs; and keep independent backups. Report suspected account compromise promptly.

12. Changes and Contact

We may update this page as controls or risks change. We post changes with an updated effective date and make reasonable efforts to notify affected users of material changes.

Security reports: security@plusultra.industries

Abuse reports: abuse@plusultra.industries

Privacy incidents and requests: privacy@plusultra.industries