Superconductor Security Policy

Last Updated: November 3, 2025

1. Our Security Commitment

At Volition, Inc., we take the security of Superconductor and your data seriously. This Security Policy outlines our approach to protecting your code, data, and privacy while using our platform to build software with AI coding agents.

2. Security Architecture

2.1 Infrastructure Security

Cloud Infrastructure

  • Hosted on Amazon Web Services (AWS) in US regions
  • Virtual Private Cloud (VPC) isolation
  • Network segmentation between services
  • DDoS protection via AWS Shield

Compute Isolation

  • AI agents run in isolated sandboxes on Modal and Runloop
  • Each execution has resource limits and timeouts
  • Network policies can restrict agent internet access
  • Container-based isolation between users

2.2 Data Protection

Encryption

  • In Transit: All data transmitted using TLS 1.2 or higher
  • At Rest: Sensitive data encrypted using AES-256
  • API Keys: Stored with additional encryption layer
  • Passwords: Hashed using bcrypt with salt

Access Controls

  • Role-based access control (RBAC) for workspaces
  • Multi-factor authentication available
  • OAuth integration with Google, Apple, GitHub
  • Session management with secure tokens

2.3 Application Security

Secure Development

  • Code review process for all changes
  • Dependency scanning for vulnerabilities
  • Static code analysis tools
  • Regular security updates and patches

API Security

  • Rate limiting to prevent abuse
  • API authentication via secure tokens
  • Input validation and sanitization
  • Protection against common web vulnerabilities (OWASP Top 10)

3. AI Agent Security

3.1 Agent Execution Environment

Sandbox Isolation

  • Agents run in isolated containers
  • Limited file system access
  • Controlled network permissions
  • Resource limits (CPU, memory, time)

3.2 Code and Data Handling

Your Code is Private

  • We do not train AI models on your code
  • Code is only shared with AI providers when you execute agents
  • We use provider privacy modes (no-training settings) when available
  • Temporary agent data is purged after execution
  • No persistent storage of agent-generated code without your action

3.3 Third-Party Agent Risks

Important Disclaimers

  • AI agents may have inherent security limitations
  • Agents can be subject to prompt injection attacks
  • Generated code may contain vulnerabilities
  • We are not responsible for third-party agent software issues

Your Responsibilities

  • Review all AI-generated code before using in production
  • Test code thoroughly for security vulnerabilities
  • Do not share sensitive credentials with agents
  • Configure appropriate network restrictions for agents

4. Data Privacy and Compliance

4.1 Compliance Status

Current Compliance

  • GDPR-aware practices for EU users
  • CCPA compliance for California residents
  • Standard contractual clauses with vendors

SOC 2 Journey

  • Working toward SOC 2 Type 2 compliance
  • This is an ongoing initiative with no guaranteed timeline
  • Compliance depends on many factors including business priorities and resource allocation
  • Actively implementing required controls and procedures
  • Conducting regular security assessments and audits

Not Compliant With

  • HIPAA (do not store protected health information)
  • PCI DSS (payment processing handled by third parties)
  • FedRAMP (not approved for government use)

4.2 Data Residency

  • Primary data storage in United States
  • Backups in geographically distributed US regions
  • No data storage in sanctioned countries

5. Security Features for Users

5.1 Account Security

Authentication Options

  • Email/password with complexity requirements
  • OAuth with Google, Apple, GitHub
  • Session timeout after inactivity
  • Account lockout after failed attempts

Recommended Practices

  • Use strong, unique passwords
  • Enable multi-factor authentication when available
  • Review account activity regularly
  • Report suspicious activity immediately

5.2 Workspace Security

Access Management

  • Granular permission levels (Admin, Collaborator, Viewer)
  • Audit logs for administrative actions
  • Member invitation controls
  • Ability to revoke access immediately

5.3 Integration Security

GitHub Integration

  • Minimal permissions requested
  • Repository access on per-project basis
  • Revocable OAuth tokens
  • No storage of GitHub credentials

AI Provider Keys

  • Encrypted storage of API keys
  • Keys never exposed in logs or UI
  • User-managed key rotation
  • Support for provider-native authentication

6. Incident Response

6.1 Security Incident Process

  1. Detection: Continuous monitoring for security events
  2. Assessment: Rapid evaluation of severity and impact
  3. Containment: Immediate action to limit damage
  4. Notification: User notification without undue delay and where required by law. Where applicable under GDPR, we will notify the supervisory authority within 72 hours where required
  5. Recovery: Restoration of normal operations
  6. Review: Post-incident analysis and improvements

6.2 Vulnerability Management

Reporting Vulnerabilities

Our Response

  • Acknowledge receipt promptly
  • Investigate and validate
  • Develop and test fixes
  • Deploy patches rapidly
  • Notify affected users if necessary

7. Monitoring and Logging

7.1 Security Monitoring

  • Real-time threat detection
  • Anomaly detection for unusual patterns
  • Failed authentication tracking
  • API abuse detection
  • Performance and availability monitoring

7.2 Logging Practices

What We Log

  • Authentication events
  • API requests (without sensitive data)
  • Error events
  • Security-relevant actions
  • System performance metrics

What We Don't Log

  • Passwords or API keys
  • Full code content in system logs (note: code is stored in our database when you connect repositories and create tickets, but is not included in operational logs)
  • Sensitive user data in logs
  • Private repository contents in logs

7.3 Third-Party Monitoring

  • Sentry: Error tracking and monitoring
  • Scout APM: Performance monitoring
  • BetterStack: Log aggregation and analysis
  • PostHog: Analytics with privacy controls (session recording disabled for EU/UK IP addresses)

8. Network Security

8.1 Network Policies

  • Firewall rules restricting unnecessary access
  • Intrusion detection systems
  • Regular security scanning
  • Secure VPN for administrative access

8.2 Agent Network Sandboxing

Every coding agent runs inside a network sandbox that controls which external domains the agent can reach. You can configure network sandboxing per project in your project settings under Network Access.

Access Modes

Each project has one of three network access modes:

  • No access — Agents cannot access any external domains. Only internal Superconductor domains required for operation are allowed. Use this for maximum isolation.
  • Custom access (default) — You define exactly which domains agents can reach. You can also include a curated list of common package registries (npm, PyPI, RubyGems, Cargo, Go modules, Docker Hub, Ubuntu/Debian apt, and others) with a single checkbox.
  • Full access — Agents can access any domain on the internet. Use with caution, as this gives agents unrestricted network access.

Custom Rules

When using custom access mode, you can add rules specifying which domains to allow:

  • Enter a domain (e.g., example.com) or use wildcards (e.g., *.example.com)
  • Mark a rule as read-only to restrict the agent to GET, HEAD, and OPTIONS requests on that domain
  • Add as many rules as needed for your project's dependencies and services

Required Domains

Regardless of your access mode, Superconductor automatically allows access to a small set of internal domains required for the platform to function (such as the Superconductor application itself and file storage). These cannot be removed.

Agent-Specific Domains

Each coding agent (Claude Code, Codex, Gemini, Amp, etc.) automatically gets access to its own provider's API domains. For example, Claude Code is allowed to reach Anthropic's API, and Codex is allowed to reach OpenAI's API. These are added automatically and do not need to be configured manually.

Default Behavior

  • New projects default to custom access with trusted package registries enabled
  • The trusted domains list includes registries for GitHub, npm/Yarn, PyPI, RubyGems, Cargo, Go modules, Docker Hub, Ubuntu/Debian apt, HashiCorp, Kubernetes, Sentry, and Playwright
  • Agents that require network access to specific services (e.g., MCP servers, external APIs) will need those domains added to the custom rules

9. Physical Security

9.1 Data Center Security

Our infrastructure providers (AWS, Modal, Runloop) maintain:

  • 24/7 physical security
  • Biometric access controls
  • Security cameras and monitoring
  • Environmental controls
  • Redundant power and cooling

9.2 Employee Access

  • Background checks for employees
  • Confidentiality agreements
  • Limited access to production systems
  • Audit trails for administrative actions

10. Business Continuity

10.1 Backup and Recovery

  • Automated daily backups
  • Geographically distributed backup storage
  • Regular recovery testing
  • Recovery Time Objective (RTO): Target of 24 hours
  • Recovery Point Objective (RPO): Target of 24 hours

Note: RTO and RPO are targets and objectives, not guaranteed commitments. Actual recovery times may vary depending on the nature and severity of incidents.

10.2 Disaster Recovery

  • Documented disaster recovery plan
  • Regular disaster recovery drills
  • Multi-region failover capabilities
  • Communication plan for major incidents

11. Shared Security Responsibility

11.1 Our Responsibilities

  • Secure platform infrastructure
  • Protect data in our custody
  • Provide security features and tools
  • Respond to security incidents
  • Maintain compliance certifications

11.2 Your Responsibilities

  • Secure your account credentials
  • Review AI-generated code
  • Configure appropriate permissions
  • Report security concerns
  • Follow security best practices
  • Ensure your code is legally compliant

12. Security Best Practices

12.1 For Developers

  1. Never commit secrets to repositories
  2. Review all AI output before using
  3. Use least privilege for permissions
  4. Enable MFA where available
  5. Rotate API keys regularly
  6. Test generated code thoroughly
  7. Monitor agent activities

12.2 For Administrators

  1. Audit workspace members regularly
  2. Remove unnecessary access promptly
  3. Review integration permissions
  4. Monitor usage patterns
  5. Establish security policies
  6. Train team members on security
  7. Plan incident response

13. Known Limitations

13.1 AI-Specific Risks

  • Prompt Injection: Agents may be manipulated by malicious inputs
  • Data Leakage: Agents might inadvertently expose information
  • Hallucinations: Agents may generate incorrect or insecure code
  • Training Data: Agents may reflect biases or outdated practices

13.2 Platform Limitations

  • Cannot guarantee 100% uptime
  • Cannot prevent all security breaches
  • Dependent on third-party services
  • Limited control over AI model behavior

14. Future Security Enhancements

14.1 Roadmap

  • SOC 2 Type 2 certification (ongoing initiative, no guaranteed timeline)
  • Enhanced secret scanning
  • Advanced threat detection
  • Improved network isolation options
  • Custom security policies per workspace

14.2 Continuous Improvement

  • Regular security assessments
  • Penetration testing
  • Security training for staff
  • Community feedback integration
  • Industry best practice adoption

15. Security Resources

15.1 Documentation

  • API security guidelines
  • Agent configuration best practices
  • Incident response procedures
  • Security FAQ

15.2 Support

Security Team

Urgent Security Issues

  • Email with "URGENT" in subject
  • Include impact assessment
  • Provide reproduction steps if applicable

16. Transparency Reports

We commit to transparency about security:

  • Annual security report publication
  • Major incident notifications
  • Security improvement updates
  • Compliance certification status

17. Contact Information

Security Contact:
Email: security@superconductor.com

General Security Inquiries:
Email: team@superconductor.com

Mailing Address:
Volition, Inc.
2261 Market Street #4795
San Francisco, CA 94114

18. Acknowledgments

We appreciate the security research community and acknowledge valid security reports through our responsible disclosure program.

This Security Policy is effective as of November 3, 2025. We continuously improve our security posture and update this policy accordingly. For security concerns or questions, please contact security@superconductor.com.