Security & Data Protection

How we protect your data

The data we handle

The platform works with a small, well-defined set of data categories, whether SpartanX generates the information through red teaming or you import it from your existing tools. All of it is protected the same way.

Tenant isolation and your workspaces

Each organization operates in one or more isolated workspaces. You can create independent workspaces as you need them, for example one per business unit or branch, or separate workspaces to track your vendors, and each is isolated from the others. The context you provide is kept siloed to its workspace and retrieved only for that workspace. Execution environments are single-tenant for each task, and any model trained on your engagements runs on a dedicated basis assigned to your organization, never in a shared environment.

Connected code repositories

When you connect a repository for white-box testing, SpartanX does not copy your source code. The platform builds a structural map of the codebase and uses it only when needed. Temporary working copies used for analysis are held in memory and deleted as soon as the work completes. The structural map exists only while the repository is connected, is isolated to your workspace, and is permanently deleted when you disconnect the repository.

Credentials and secrets

Credentials you provide for authenticated testing, and any secrets the platform discovers during an engagement, are held in an encrypted secret store with role-based access. Every retrieval records who requested it and why, preserving a complete chain of custody over sensitive material. Secrets the platform discovers are protected to the same standard as those you provide.

Findings and evidence

SpartanX produces exploit-validated findings, each backed by evidence. We practice data minimization, capturing only what is needed to demonstrate an issue rather than exfiltrating your systems. Evidence is encrypted at rest, treated as the most sensitive data we hold, and redacted at the point reports are generated. Inside the product it is visible only to authorized administrators on your side, with the most sensitive material restricted to your highest-permission security administrators. Evidence is never used in platform learning.

How the platform learns

The platform improves over time by learning reusable technique, not your data. A few principles govern this:

• Your raw data never trains any model. Learning draws only on abstracted attack patterns that capture how a technique works, not where it ran or whom it affected.
• Those patterns pass through multiple independent, automated redaction steps before they can be used. The process is fail-closed, so anything that looks sensitive is blocked rather than allowed through.
• Your evidence is never used for learning.
• There is no cross-customer data flow. Your data is never used to train a model for another customer.
• Any model trained on your engagements is dedicated to your organization and destroyed when your contract ends.
• Where we rely on third-party AI providers, they are contractually prohibited from training on or retaining your data.

Ephemeral execution

Platform actions, including any custom tooling the agents build, run inside isolated, single-use environments that hold no persistent state and are torn down after each task. Outbound access is restricted, and nothing from one task carries into another.

Testing inside your network

For testing inside your network, SpartanX deploys a lightweight connector. It connects outbound only, opens no inbound ports, and authenticates with a unique, customer-generated token over a mutually authenticated channel. It holds no models and no sensitive data: the reasoning stays in the cloud and only tool execution runs locally. If the connector were ever compromised, it would yield only standard tooling, with no models and no proprietary logic.

How we govern and operate security

Governance and ownership

SpartanX operates a formal information security program with clear executive accountability. Our Chief Technology Officer serves as the accountable security officer, supported by a dedicated DevSecOps function that coordinates controls, policy, access decisions, and incident response, with oversight from senior management including the CEO and COO. Security roles and responsibilities are documented and assigned. Our policies are version-controlled, reviewed at least annually, and approved by management before changes take effect, and every employee and contractor is responsible for reading, acknowledging, and following the policies relevant to their role.

Risk management

We manage information security risk through a documented methodology. Risks are recorded in a risk register, scored on a consistent likelihood-by-impact scale, and treated through mitigation, transfer, acceptance, or avoidance, each with a named owner. Risk inputs include security assessments, vulnerability findings, and operational signals, and assessments are refreshed at least annually and when significant changes occur.

People and personnel security

Security starts with the people we hire. We perform background verification, including criminal history checks where permitted by law, for personnel with access to production systems or confidential information, proportional to the role. Before access is granted, employees and contractors acknowledge our security policies and sign confidentiality, intellectual-property, and code-of-conduct agreements. Personnel complete security awareness training at onboarding and on an ongoing basis, with role-appropriate training for privileged access. On departure, we promptly revoke access and recover company equipment.

Access control and identity

Access follows the principle of least privilege: users receive only the access their role requires, and anything not expressly granted is denied by default. Authentication is centralized, with multi-factor authentication enabled by default and enforced for all users; enterprise customers can federate their own identity provider for single sign-on under their existing controls. Access is provisioned only on documented, approved request, reviewed quarterly and on any role change, and removed within 24 business hours of departure. Conflicting duties are separated to reduce the risk of error or misuse, and access to source code is granted on business need and logged.

Secure development and change management

Security is built into how we develop and operate our software. All code is version-controlled, with repository access restricted by role, and significant changes must be reviewed and approved before they are merged and deployed, so no single individual ships to production without oversight. Changes are documented, assessed for impact, and tested in environments separated from production; emergency changes are expedited but receive retrospective review. We apply secure-by-design and privacy-by-design principles, including least privilege, secure defaults, defense in depth, separation of duties, and failing securely, and confidential production data is not used in development or test environments without explicit approval. As a company whose core discipline is offensive security, we apply the same adversarial rigor to our own platform that we bring to customer engagements.

Operations, monitoring, and vulnerability management

We operate our production environment to defined standards. Endpoint protection, including anti-malware, endpoint detection and response, and mobile device management, is required on all company devices and configured to update automatically and monitor continuously. We identify and remediate technical vulnerabilities on a risk-prioritized schedule, with target timelines that scale to severity. Security-relevant events are logged and monitored, and logs are retained for at least one year to support investigation and review.

Incident response

We maintain a documented incident response plan that defines how events are detected, triaged, contained, eradicated, recovered, and reviewed. Incidents are assigned a severity, and a root-cause analysis is required for every critical incident. Where notification is required, we commit to notifying affected customers within 48 hours of determining that a reportable incident or breach has occurred, unless a shorter period is required by law or contract.

Business continuity and resilience

SpartanX runs on resilient cloud infrastructure rather than offices or on-premises hardware. Our business continuity and disaster recovery program sets recovery objectives for our critical systems and includes restoration testing at least annually to validate that recovery performs as designed. Because our workforce is distributed and our systems are cloud-hosted, continuity does not depend on any single location.

Third-party and vendor risk

We hold our suppliers to the standard we set for ourselves. Before a third party is granted access to confidential data or production systems, we perform due diligence and execute a written agreement setting out its security responsibilities. We assess vendors across control areas including governance, access control, operations security, secure development, human resources, and physical security, and we may rely on independent attestations such as SOC 2 reports or ISO certifications. Supplier security and service delivery are reviewed at least annually. Our current subprocessors are published at trust.spartanx.ai.

Physical and remote-work security

SpartanX is remote-first and operates no offices, data centers, or on-premises infrastructure. Our platform runs in a private cloud environment in the United States, where physical and environmental security is provided by the cloud platform under its shared-responsibility model and independent audits. For our distributed workforce, endpoints must lock automatically, run endpoint protection, and have access removed on departure, and confidential data may not be stored on removable media.

Encryption, hosting, and data residency

Customer data is encrypted in transit and at rest using strong, industry-standard encryption: AES-256 at rest and TLS 1.3 in transit. Encryption keys are managed separately from the data they protect. Customer data is hosted in a private cloud environment in the United States. Our authoritative, up-to-date list of subprocessors is maintained at trust.spartanx.ai.

Data retention and deletion

We retain customer data only for as long as it is needed to deliver the service. The context you share, engagement telemetry, findings, and evidence are retained for the duration of the engagement and the contract, and connected assets follow their own lifecycle, so a repository's structural map, for example, exists only while the repository is connected. On termination of the contract, customer data, including any personal data held in context or evidence, is deleted from the platform, and any model trained for your organization is destroyed. You may also request deletion of specific records during an engagement.

Compliance and assurance

SpartanX operates a formal security program and is pursuing SOC 2 attestation, beginning with a SOC 2 Type 1 examination and followed by SOC 2 Type 2, supported by continuous control monitoring. Our internal control framework is organized around the same trust principles a SOC 2 examination evaluates, with a focus on security, availability, and confidentiality. The SOC 2 report will be made available under NDA on completion.

Our policy framework

SpartanX maintains a formally governed policy library: version-controlled, reviewed at least annually, and approved by management. Fifteen policies span the domains below. Individual policies are available to customers under NDA on request.