Trust Center
We handle your targets, source code, credentials, and reports with the same rigor we use to break into everyone else's systems.
Our security philosophy
Vulnary is an offensive-security company. Our whole business is finding the ways systems fail, so we hold our own platform to the standard we test others against. Trust is not a feature we bolt on — it is the product. When you engage us, you hand over some of the most sensitive material an organization has: in-scope targets, source code, live credentials, and existing pentest reports. Everything below describes how we protect it.
We build for a simple assumption: assume an adversary is watching, and design so that a single mistake — ours or an attacker's — cannot cascade into your data. That means encryption everywhere, strict isolation, technical (not just contractual) scope enforcement, and least privilege by default.
Data protection
- Encryption in transit. All traffic to and from Vulnary is protected with TLS. There are no unencrypted endpoints.
- Encryption at rest. Stored data is encrypted at rest at the storage layer.
- Encrypted secrets. Sensitive secrets — including any AI-provider key you bring — are encrypted with AES-256-GCM. Where you supply your own provider key, it is decrypted only host-side, only to run your own engagement, and is never written to logs.
- Isolation per engagement. Each engagement runs in its own isolated sandbox. Your data does not share a runtime with another customer's.
Scope safety
The single most important promise in offensive security is that testing stays strictly in-bounds. We enforce that technically, not just on paper.
- Authorization-first. The Resident, our autonomous offensive engine, only acts against targets you have explicitly authorized for a given engagement.
- Netjail / scope firewall. Each engagement runner is wrapped by a scope-enforcement firewall (netjail) that blocks network access to anything outside the authorized scope. This is enforced in the runner itself — a control that constrains what the engine can reach, not merely what it is asked to reach.
- Fail closed. If a target is not in scope, the engine cannot reach it. Out-of-bounds is a technical impossibility for the run, not a policy someone has to remember.
Access control & least privilege
- Passwordless authentication. Sign-in uses emailed magic links. There are no reusable passwords to phish, guess, reuse, or leak.
- Least privilege. Access to customer data is limited to the minimum needed to operate an engagement and support you. Internal access is scoped and granted on a need-to-use basis.
- Segregation. Engagement data is partitioned by customer and by engagement, so access is naturally bounded to the work at hand.
Credential & source-code handling
Credentials and source code you provide are used only to perform the engagement you requested. They are scoped tightly to that engagement's isolated environment, are never used to train models, and are removed under our retention policy once the engagement is complete. Credentials are treated as secrets throughout — encrypted at rest and kept out of logs.
Infrastructure & isolation
Vulnary is a managed, SaaS platform — there is no on-prem agent to deploy or maintain. Engagements execute in per-engagement, ephemeral sandboxes: a fresh, isolated container is stood up for the run and torn down afterward. This gives each engagement a clean, contained blast radius and ensures one customer's testing cannot observe or affect another's.
Vulnerability management of our own platform
We apply the same offensive discipline inward. We monitor our dependencies and platform surface, patch on a risk-prioritized basis, and continuously exercise our own controls — including the scope and isolation guarantees above — so they hold in practice and not just in design.
Responsible disclosure
If you believe you have found a security issue in Vulnary, we want to hear from you. Email [email protected] with enough detail to reproduce the issue. We will acknowledge your report, investigate, and keep you informed through remediation. Please give us a reasonable opportunity to fix the issue before any public disclosure, and do not access, modify, or exfiltrate data that is not yours while testing.
Data retention & deletion
We retain engagement data — targets, source, credentials, findings, and reports — only as long as needed to deliver and support the engagement and to meet legal and billing obligations. Ephemeral engagement environments and their working data are destroyed when the engagement completes. On request, and subject to any legal retention requirements, we will delete the customer data associated with your account. Contact [email protected] for a deletion request.
Subprocessors
We use a small set of trusted providers to operate the platform. We share only the data necessary for each provider's function.
| Provider | Purpose | Data |
|---|---|---|
| Cloud hosting infrastructure | Compute and storage for the platform and engagement sandboxes | Encrypted engagement data, application data, and platform logs |
| Resend | Transactional email delivery, including passwordless magic-link sign-in | Recipient email address and message content |
| Payment processor | Billing and subscription management | Billing contact and payment details (handled by the processor) |
| Anthropic | AI model provider that powers the Resident engine (a bring-your-own-key option is available on some plans) | Engagement prompts and context sent to run the engine |
Compliance posture
We want to be honest about where we are. SOC 2 and other formal certifications are on our roadmap — we do not claim a certification we do not hold. Today we operate to the controls described on this page: encryption in transit and at rest, AES-256-GCM secret encryption, per-engagement isolation, technical scope enforcement, least-privilege access, passwordless authentication, and a defined retention and deletion policy. As we formalize our audit program, we will update this page and make attestations available to customers.
Questions?
Security questions, diligence requests, or vulnerability reports are all welcome at [email protected].