Responsible Use Guidelines

​

Legal Requirements

​

Authorization

• Your own applications - Applications you own or develop
• Client applications - Written authorization from the system owner
• Bug bounty programs - Follow program rules and scope
• Penetration testing engagements - Formal signed contract or statement of work

• Third-party applications or websites
• Public-facing systems you don’t own
• Competitor applications
• Any system without explicit permission

​

Documentation

1. Authorization letter - Written permission from system owner
2. Scope document - Clear boundaries of what can be tested
3. Rules of engagement - Testing windows, limitations, contact procedures
4. Findings report - Document all discoveries professionally

​

Example Authorization Request

To: [System Owner]
From: [Your Name/Company]
Subject: Security Testing Authorization Request

I request authorization to perform security testing on:
- Application: [Name]
- URL/Environment: [Target]
- Testing Period: [Dates]
- Scope: [Endpoints, features, exclusions]

Testing Methodology:
- Automated scanning with Strix
- Manual vulnerability validation
- No destructive testing
- No data exfiltration

Please confirm authorization in writing.

Regards,
[Your Name]

​

Ethical Guidelines

​

Do No Harm

• No destructive testing - Don’t delete data or disrupt services
• Respect privacy - Don’t access or exfiltrate personal data
• Minimize impact - Use staging environments when possible
• Stop if uncertain - If something could cause harm, stop and ask

​

Responsible Disclosure

1. Report privately first - Don’t publicly disclose immediately
2. Provide details - Clear reproduction steps and impact assessment
3. Allow time to fix - Give reasonable time (typically 90 days)
4. Don’t exploit for personal gain - Don’t use findings maliciously
5. Follow disclosure programs - Respect bug bounty timelines and processes

​

Example Disclosure Timeline

​

Respect Boundaries

• Test only authorized targets - Don’t expand scope without permission
• Respect testing windows - Test during agreed-upon times
• Honor exclusions - Don’t test explicitly excluded areas
• Stop when asked - Immediately cease if authorization is revoked

​

Best Practices

​

Before Testing

1. Verify authorization
   # Document authorization
   cat > authorization.txt << EOF
   Date: $(date)
   Target: https://example.com
   Authorized by: [Name]
   Valid until: [Date]
   EOF
   
2. Review scope carefully
   • What is in scope?
   • What is explicitly out of scope?
   • Are there rate limits or testing windows?
   • Who is the emergency contact?
3. Prepare safe environment
   • Use staging/test environments when available
   • Configure read-only database replicas
   • Set up monitoring and alerts
4. Configure Strix responsibly
   # Use appropriate scan mode
   strix --target https://staging.example.com --scan-mode quick
   
   # Provide clear boundaries
   strix --target https://example.com \
     --instruction "Do not test /admin or /internal. Avoid destructive operations."
   

​

During Testing

1. Monitor impact
   • Watch for performance degradation
   • Check for triggered alerts
   • Monitor error logs
2. Document findings thoroughly
   • Take screenshots
   • Save request/response pairs
   • Note exact steps to reproduce
3. Communicate proactively
   • Notify if you discover critical vulnerabilities
   • Report any testing issues immediately
   • Ask if uncertain about scope
4. Stay professional
   • Don’t access user data unnecessarily
   • Don’t demonstrate vulnerabilities to unauthorized parties
   • Maintain confidentiality

​

After Testing

1. Submit comprehensive report
   # Strix generates reports automatically
   # Review before sharing
   cat strix_runs/latest/report.md
   
2. Secure findings data
   • Encrypt sensitive reports
   • Store securely
   • Delete when no longer needed
3. Follow up responsibly
   • Confirm receipt of report
   • Offer to clarify findings
   • Verify fixes if requested
4. Clean up
   # Remove test accounts or data created
   # Stop any persistent processes
   # Clean up Docker containers
   docker container prune -f
   

​

Specific Scenarios

​

Bug Bounty Programs

1. Read program rules carefully
   • Scope and exclusions
   • Severity guidelines
   • Disclosure requirements
2. Follow platform guidelines
   • HackerOne, Bugcrowd, etc. have specific rules
   • Respect program preferences
3. Submit quality reports
   • Clear title and summary
   • Detailed reproduction steps
   • Impact assessment
   • Suggested remediation
4. Be patient
   • Triage takes time
   • Respond to questions promptly
   • Don’t pressure for rewards

​

Penetration Testing Engagements

1. Formalize rules of engagement
   • Signed statement of work
   • Clear scope and timelines
   • Emergency contacts
   • Legal protections
2. Maintain professionalism
   • Regular status updates
   • Document everything
   • Deliver quality reports
   • Present findings clearly
3. Provide actionable recommendations
   • Prioritized findings
   • Remediation guidance
   • Retesting services

​

Internal Security Testing

1. Get management approval
   • Even internal testing needs authorization
   • Document approval
   • Coordinate with teams
2. Use appropriate environments
   # Test staging first
   strix --target https://staging.internal.com
   
   # Then production if necessary
   strix --target https://prod.internal.com --scan-mode quick
   
3. Coordinate with operations
   • Notify security team
   • Schedule during low-traffic periods
   • Have incident response ready

​

CI/CD Integration

1. Scope appropriately
   # Only scan your own code
   - name: Security Scan
     run: strix -n -t ./ --scan-mode quick
   
2. Handle findings responsibly
   • Set up secure notifications
   • Restrict access to findings
   • Track remediation
3. Respect rate limits
   • Don’t overload external services
   • Use caching when possible
   • Configure reasonable timeouts

​

Data Privacy

​

What Data Strix Accesses

• Source code and configuration files
• HTTP requests and responses
• Application output and error messages
• User interface and API endpoints

​

Protecting Sensitive Data

1. Use test data
   • Never use production user data
   • Create synthetic test datasets
   • Anonymize when necessary
2. Secure LLM API calls
   # Use private LLM instances for sensitive apps
   export STRIX_LLM="azure/gpt-5-private"
   export LLM_API_BASE="https://private.openai.azure.com"
   
   # Or use local models
   export STRIX_LLM="ollama/llama3.3:70b"
   
3. Sanitize reports
   • Remove credentials from findings
   • Redact sensitive data
   • Encrypt before sharing
4. Secure storage
   # Encrypt scan results
   tar -czf - strix_runs/ | gpg -c > scan-results.tar.gz.gpg
   
   # Secure delete originals
   rm -rf strix_runs/
   

​

Legal Consequences

​

Unauthorized Access Laws

• United States - Computer Fraud and Abuse Act (CFAA)
• European Union - Computer Misuse Directive
• United Kingdom - Computer Misuse Act 1990
• Australia - Cybercrime Act 2001

• Criminal charges
• Civil lawsuits
• Significant fines
• Imprisonment
• Professional consequences

​

Safe Harbor Provisions

• Protected if you follow program rules
• Authorization in writing
• Good faith security research
• Responsible disclosure

​

When in Doubt

• Is this system explicitly in scope?
• Do I have written authorization?
• Could this cause harm or disruption?
• Am I accessing data I shouldn’t?
• Would I want someone doing this to my system without asking?

​

Resources

​

Further Reading

• OWASP Testing Guide
• Penetration Testing Execution Standard
• Bug Bounty Platforms

​

Legal Guidance

• Consult legal counsel for formal engagements
• Review local computer crime laws
• Understand safe harbor provisions

​

Community Standards

• Discord Community
• GitHub Discussions

​

Reporting Misuse

1. Document the misuse - Screenshots, logs, evidence
2. Report to appropriate authorities - Law enforcement if illegal
3. Notify Strix team - Email [email protected]
4. Don’t engage directly - Let authorities handle it

​

Conclusion

• Legal - Properly authorized and documented
• Ethical - Responsible and non-harmful
• Effective - Produces actionable results
• Professional - Maintains trust and reputation