Security Policy

Effective Date: August 4, 2026
Last Updated: August 4, 2026

CacheCoders takes the security of its website, products, systems, and client information seriously.

This Security Policy describes our general approach to security, the responsibilities of website visitors and users, and how security researchers may report suspected vulnerabilities.

Security requirements for a particular client project, CacheVoice or CacheAssist implementation, subscription, integration, or hosted system may be governed by a separate agreement, statement of work, data-processing agreement, or product-specific security documentation.

1. Scope of This Policy

This policy applies to:

• The CacheCoders public website
• Website forms and communications
• CacheCoders-operated applications and product environments
• CacheVoice and CacheAssist environments operated by CacheCoders
• Infrastructure and software under our direct administrative control

This policy does not automatically apply to:

• Client-managed infrastructure
• Third-party platforms
• External websites linked from our website
• Systems operated by clients or service providers
• Demonstration environments owned by another organization
• Software outside CacheCoders’ control

Security obligations for client projects are determined by the applicable written agreement.

2. Our Security Approach

CacheCoders follows a risk-based approach to security.

The controls used for a particular system depend on factors such as:

• The sensitivity of the information involved
• The system’s purpose and architecture
• User and administrator access requirements
• Applicable client requirements
• Third-party integrations
• Legal or regulatory obligations
• Potential consequences of unauthorized access or system failure

No single security control is sufficient for every environment. We aim to use layered safeguards appropriate to the system and the risks involved.

3. Security by Design

We consider security during the planning, architecture, development, testing, deployment, and maintenance of software systems.

Depending on the project, this may include:

• Reviewing data flows and system boundaries
• Identifying sensitive information
• Defining user and service permissions
• Restricting unnecessary access
• Validating inputs and system actions
• Protecting credentials and secrets
• Logging significant administrative activity
• Reviewing third-party integrations
• Planning for errors and service interruptions
• Including human approval for sensitive AI actions
• Testing before production deployment

Security requirements may be documented separately for each client engagement.

4. Data Minimization

We seek to collect and retain only the information reasonably needed for legitimate business, operational, contractual, or legal purposes.

Visitors should not submit the following through public website forms:

• Passwords
• API keys
• Access tokens
• Payment-card details
• Government identification numbers
• Confidential source code
• Protected health information
• Regulated financial information
• Private client datasets
• Production credentials
• Other highly sensitive information

Sensitive project materials should be exchanged only through an approved method and, where appropriate, under a confidentiality or data-processing agreement.

5. Access Control

Access to systems and information should be limited to individuals, services, and tools with a legitimate need.

Depending on the environment, access controls may include:

• Individual user accounts
• Role-based permissions
• Multi-factor authentication
• Least-privilege access
• Restricted administrator access
• Time-limited credentials
• Periodic access reviews
• Separation between development and production environments
• Removal of access when it is no longer required

The principle of least privilege limits users and services to the permissions necessary for their intended functions, helping reduce the potential effect of misuse or compromise.

6. Authentication and Credentials

Users are responsible for protecting credentials associated with any CacheCoders-operated system they are authorized to access.

Users should:

• Use strong and unique passwords
• Enable multi-factor authentication where available
• Avoid sharing accounts
• Keep passwords, keys, and tokens confidential
• Report suspected credential exposure promptly
• Sign out of shared or untrusted devices
• Avoid storing credentials in unsecured documents or messages

CacheCoders will never ask users to publish passwords or secret keys through a public website form.

7. Encryption and Secure Transmission

Where appropriate for the system, the information involved, and the available technology, safeguards may include encryption during transmission and protection of stored sensitive information.

The specific encryption, storage, and key-management requirements for a client system are determined by the applicable architecture and written agreement.

Visitors should still avoid sending highly sensitive data through ordinary email or public forms unless CacheCoders has approved that method.

8. Secure Software Development

Our development approach may include controls such as:

• Code review
• Dependency management
• Input validation
• Authentication and authorization checks
• Secure configuration
• Secret-management practices
• Error handling
• Logging and monitoring
• Automated or manual testing
• Separation of environments
• Deployment controls
• Vulnerability remediation
• Backup and recovery planning

The exact controls vary according to the scope, risk, and technical requirements of each project.

9. AI System Security

AI systems introduce risks beyond traditional software, including inaccurate outputs, excessive permissions, unsafe tool use, prompt manipulation, unintended data exposure, and reliance on unverified information.

Depending on the use case, CacheCoders may use safeguards such as:

• Restricted tool permissions
• Approved knowledge sources
• Human review before sensitive actions
• Validation of model-generated output
• Confidence or escalation rules
• Audit logs
• Source citations
• Input and output filtering
• Authentication and authorization
• Rate limiting
• Separation of private client data
• Monitoring for unusual behavior
• Limits on autonomous actions

AI should not be given unrestricted authority over sensitive business systems merely because it can generate a plausible response.

10. Human Approval and Sensitive Actions

Actions involving significant financial, legal, operational, privacy, safety, or customer consequences may require human approval.

Examples may include:

• Sending binding communications
• Making or changing payments
• Deleting records
• Approving applications
• Modifying sensitive customer information
• Making high-impact decisions
• Granting system access
• Executing irreversible actions
• Communicating regulated advice

Approval requirements are determined according to the system and agreed client workflow.

11. Third-Party Service Providers

CacheCoders may use third-party providers for services such as:

• Website hosting
• Cloud infrastructure
• Communications
• Voice AI
• Telephone services
• Model hosting
• Analytics
• Authentication
• Scheduling
• Data storage
• Email
• Monitoring
• Development and deployment

Third-party systems remain subject to their own security practices, availability, terms, and privacy policies.

Where appropriate, we assess providers based on the nature of their service, the information they process, available security controls, contractual requirements, and the risks associated with using them. FTC guidance recommends setting reasonable security expectations with service providers and documenting those requirements contractually.

CacheCoders cannot guarantee that an independent third-party provider will never experience an outage, vulnerability, or security incident.

12. Monitoring and Logging

Depending on the system, CacheCoders may collect logs and operational information to:

• Detect errors
• Investigate suspicious activity
• Monitor system health
• Troubleshoot failures
• Review administrative actions
• Identify misuse
• Improve reliability
• Support incident response
• Verify workflow execution

Access to security and operational logs should be restricted according to business and technical requirements.

Logs may be retained for different periods depending on the system, contract, security need, and applicable law.

13. Vulnerability Management

CacheCoders may review and address vulnerabilities identified through:

• Internal testing
• Dependency or platform notifications
• Third-party security reports
• Client reports
• Service-provider alerts
• Responsible security research
• Operational monitoring

The urgency and timing of remediation depend on factors including:

• Potential impact
• Likelihood of exploitation
• Accessibility of the affected system
• Sensitivity of exposed information
• Availability of a safe correction
• Risk of disrupting production services

Not every reported issue represents an exploitable security vulnerability.

14. Incident Response

Where CacheCoders becomes aware of a suspected security incident affecting a system under its control, we may take steps such as:

• Investigating the reported activity
• Restricting or disabling affected access
• Preserving relevant records
• Containing the issue
• Correcting vulnerable configurations or code
• Restoring affected services
• Coordinating with service providers
• Informing affected clients where appropriate
• Providing legally required notifications
• Reviewing the cause and improving safeguards

No security program can guarantee that every attack, vulnerability, or incident will be prevented. Security programs should include both reasonable preventive safeguards and preparation for responding to incidents.

15. Business Continuity and Recovery

Depending on the applicable service and agreement, systems may include measures designed to support availability and recovery, such as:

• Backups
• Redundant services
• Restore procedures
• Service-health monitoring
• Failure alerts
• Retry mechanisms
• Manual fallback procedures
• Recovery documentation

Recovery times and service-availability commitments apply only where stated in a separate written agreement.

16. Employee and Contractor Responsibilities

Individuals with authorized access to CacheCoders or client systems are expected to:

• Follow applicable security policies
• Protect credentials
• Use approved systems and tools
• Avoid unnecessary collection of sensitive information
• Report suspected incidents
• Respect client confidentiality
• Access information only for legitimate work
• Keep software and devices reasonably secure
• Follow contractual security requirements

Access may be restricted or removed when no longer required.

17. Responsible Vulnerability Disclosure

CacheCoders welcomes good-faith reports of suspected security vulnerabilities affecting systems under our control.

Reports should be sent to:

connect@cachecoders.com

Use the subject line:

Security Vulnerability Report

Please include:

• The affected page, product, domain, or system
• A clear description of the suspected vulnerability
• Steps required to reproduce it
• The potential security impact
• Relevant screenshots, logs, or request details
• Any proof-of-concept material necessary to understand the issue
• Your contact information
• Whether you plan to disclose the issue publicly

Do not include unnecessary personal information, client data, credentials, or confidential records in the report.

18. Good-Faith Security Research

Security research must be conducted carefully and in good faith.

Researchers must:

• Make a reasonable effort to avoid accessing personal or confidential information
• Stop testing if sensitive data becomes accessible
• Avoid changing or deleting information
• Avoid interrupting services
• Use the minimum testing necessary to demonstrate the issue
• Report the issue promptly
• Give CacheCoders reasonable time to investigate before disclosure
• Comply with applicable law
• Respect third-party systems and terms

Submitting a report does not create a contract, employment relationship, or entitlement to payment.

19. Prohibited Testing

The following activities are not authorized:

• Denial-of-service or distributed denial-of-service testing
• Excessive automated traffic
• Destructive testing
• Deleting or altering data
• Accessing another user’s account
• Downloading private or confidential information
• Social engineering
• Phishing
• Physical security testing
• Malware deployment
• Ransomware testing
• Credential stuffing
• Password spraying
• Brute-force authentication attempts
• Spam
• Testing third-party systems without permission
• Disrupting customer or production operations
• Publicly exposing a vulnerability before reasonable remediation

If testing creates a risk to users, clients, data, or system availability, stop immediately and report the issue.

20. Out-of-Scope Reports

Examples of reports that may not be treated as security vulnerabilities include:

• Missing security headers without a demonstrated impact
• Email spoofing claims without evidence of a domain configuration issue
• Publicly available information
• Clickjacking on pages without sensitive actions
• Self-XSS
• Findings produced only by automated scanners
• Version disclosure without an exploitable condition
• Rate-limit observations without a security impact
• Issues affecting unsupported browsers
• Social engineering reports
• Reports involving systems outside CacheCoders’ control
• Hypothetical attacks requiring unrealistic access
• Duplicate reports
• Spam or content-quality complaints

We may still review these reports, but they may not receive the same priority as exploitable vulnerabilities.

21. Our Response to Reports

When a sufficiently detailed vulnerability report is received, CacheCoders may:

• Confirm receipt
• Request additional information
• Attempt to reproduce the issue
• Assess severity and scope
• Coordinate with affected providers or clients
• Develop and test a correction
• Request that public disclosure be delayed
• Notify the reporter when the matter has been addressed

Response and remediation timing will vary according to the report’s clarity, severity, affected system, technical complexity, and third-party dependencies.

We do not guarantee a specific response or resolution period unless agreed separately in writing.

22. No Bug-Bounty Commitment

CacheCoders does not currently operate a guaranteed public bug-bounty program.

Submitting a vulnerability report does not create an obligation for CacheCoders to provide:

• Payment
• Rewards
• Employment
• Public recognition
• Product access
• Reimbursement
• Any other compensation

Any reward or acknowledgment is entirely discretionary and must be confirmed in writing.

23. Coordinated Disclosure

Researchers should not publish or disclose vulnerability details until:

• CacheCoders has had a reasonable opportunity to investigate;
• affected clients or service providers have been informed where necessary;
• a correction or mitigation has been made available where reasonably possible; and
• disclosure can occur without creating unnecessary risk to users or systems.

CacheCoders may request additional time where remediation depends on a third party or requires significant architectural changes.

24. Security Is a Shared Responsibility

Security also depends on clients and users configuring and operating systems appropriately.

Clients and authorized users are responsible for:

• Protecting their accounts and credentials
• Managing their employees’ access
• Removing access that is no longer required
• Following implementation guidance
• Maintaining connected third-party systems
• Reviewing sensitive AI-generated actions
• Keeping contact and security information current
• Reporting suspected misuse promptly
• Complying with applicable laws and contracts

CacheCoders is not responsible for incidents caused solely by unauthorized credential sharing, insecure client configurations, unapproved modifications, or third-party systems outside our control.

25. No Absolute Guarantee

Although CacheCoders seeks to use safeguards appropriate to its operations, no website, application, AI system, network, transmission method, or storage environment can be guaranteed completely secure.

This Security Policy does not constitute:

• A warranty of perfect security
• A guarantee against all attacks
• A certification of regulatory compliance
• A service-level agreement
• A promise that every described control applies to every system
• A replacement for project-specific security terms

Specific security commitments must be documented in the applicable client or product agreement.

26. Changes to This Security Policy

We may update this policy to reflect changes in:

• Our website
• Products
• Services
• Infrastructure
• Security practices
• Third-party providers
• Legal requirements
• Vulnerability-reporting procedures

The updated version will be posted on this page with a revised “Last Updated” date.

27. Contact Us

For general security questions or vulnerability reports, contact:

CacheCoders
Email: connect@cachecoders.com
Phone: +1 (832) 220-8502
Location: United States

For vulnerability reports, use the email subject:

Security Vulnerability Report