Security Policy

The purpose of this Security Policy is to establish the security principles and practices applicable to the Asiyst Services.

The policy is intended to address:

• Information security.
• Account security.
• Application security.
• Infrastructure security.
• API security.
• Data protection.
• Access control.
• Credential protection.
• Vulnerability management.
• Security monitoring.
• Incident response.
• Business continuity.
• Customer security responsibilities.

This policy applies to security practices associated with Asiyst-controlled Services, including where applicable:

• Asiyst websites.
• Web applications.
• APIs.
• SDKs.
• CLI tools.
• AI assistants.
• Avatars.
• Projects.
• Workspaces.
• Databases.
• Storage.
• Authentication systems.
• Internal administrative systems.
• Supporting infrastructure.

Third-party services remain subject to their own security practices and contractual obligations.

Asiyst's security program is based on principles including:

• Confidentiality.
• Integrity.
• Availability.
• Least privilege.
• Defense in depth.
• Secure-by-design development.
• Access control.
• Data minimization.
• Monitoring.
• Incident response.
• Continuous improvement.

Asiyst is responsible for security controls within infrastructure and systems under its control.

Customers are responsible for securing their own applications, devices, credentials, integrations, users, and deployments.

Third-party providers are responsible for security of the systems and services they operate.

Asiyst maintains measures intended to protect information against unauthorized:

• Access.
• Disclosure.
• Modification.
• Destruction.
• Loss.
• Processing.

Security measures are selected based on the nature and sensitivity of the information and the risks associated with the applicable system.

Access to Asiyst systems may be restricted based on:

• Role.
• Job function.
• Business need.
• System requirements.
• Project requirements.
• Security requirements.

Access may be granted only where necessary for an authorized purpose.

Asiyst seeks to limit access to the minimum level reasonably required to perform an authorized function.

Access permissions may be reviewed or modified when responsibilities, systems, or security requirements change.

Asiyst uses authentication mechanisms appropriate to the applicable Service.

Depending on the system, authentication may include:

• Account credentials.
• Sessions.
• Access tokens.
• API keys.
• OAuth-based authorization.
• Other authentication mechanisms.

Users are responsible for protecting their accounts.

Users should:

• Use strong credentials.
• Avoid sharing credentials.
• Protect authentication devices.
• Monitor account activity.
• Secure recovery mechanisms.
• Report suspected compromise.

Asiyst APIs may use authentication and authorization controls to restrict access to authorized applications and users.

API security measures may include:

• API keys.
• Access tokens.
• Authorization checks.
• Request validation.
• Rate limiting.
• Logging.
• Monitoring.
• Abuse prevention.

API keys are credentials and should be treated as confidential.

Customers should not:

• Commit keys to public repositories.
• Place sensitive keys in publicly accessible client-side code.
• Share keys unnecessarily.
• Include keys in screenshots or documentation.

Compromised keys should be revoked or rotated promptly.

Asiyst SDKs are intended to facilitate secure integration with Asiyst services.

Customers are responsible for securely implementing SDKs within their own applications.

Sensitive server-side credentials should not be exposed through client-side applications.

The Asiyst CLI may interact with local files, projects, APIs, credentials, and configuration information.

Users should ensure that:

• Credentials are stored securely.
• Configuration files containing secrets are protected.
• Local project permissions are appropriate.
• CLI installations come from trusted sources.
• Credentials are revoked when compromise is suspected.

Asiyst applies security considerations to the design, development, testing, deployment, and maintenance of its applications.

Depending on the system, practices may include:

• Code review.
• Testing.
• Dependency management.
• Access controls.
• Secure configuration.
• Vulnerability management.
• Security monitoring.

Security may be incorporated into the software development lifecycle.

Development practices may include:

• Security reviews.
• Code review.
• Dependency review.
• Testing.
• Security testing.
• Controlled deployments.
• Environment separation.
• Credential protection.

Asiyst may monitor dependencies used by its software and infrastructure for known security issues.

Where appropriate, Asiyst may update, replace, restrict, or remove vulnerable dependencies.

The timing of remediation may depend on the severity and exploitability of the vulnerability.

Where appropriate, Asiyst may separate:

• Development environments.
• Testing environments.
• Staging environments.
• Production environments.

Production access may be more restricted than access to development or testing environments.

Asiyst may use cloud and infrastructure providers to operate its Services.

Infrastructure security may include:

• Network controls.
• Access controls.
• Authentication.
• Encryption.
• Monitoring.
• Logging.
• Secure configuration.
• Backup mechanisms.

Network-level controls may be used to limit unauthorized communication with Asiyst systems.

Depending on the infrastructure, controls may include:

• Firewalls.
• Network segmentation.
• Access restrictions.
• Secure communication protocols.
• Traffic monitoring.
• Rate controls.

Asiyst may use encryption to protect information during transmission and storage where appropriate.

Encryption mechanisms may vary depending on:

• Service.
• Data type.
• Infrastructure.
• Third-party provider.
• Technical requirements.

Information stored by Asiyst may be protected through controls such as:

• Access restrictions.
• Authentication.
• Encryption.
• Monitoring.
• Backup controls.
• Infrastructure security measures.

Access to stored information is intended to be limited to authorized purposes.

Databases supporting Asiyst services may be protected using appropriate:

• Authentication.
• Authorization.
• Access controls.
• Network restrictions.
• Logging.
• Backup mechanisms.
• Monitoring.

Database access may be restricted to authorized applications and personnel.

Object storage and file-storage systems may use access controls designed to prevent unauthorized access.

Customer files and other stored objects should not be publicly exposed unless the applicable product functionality intentionally requires public access.

Asiyst may use dedicated mechanisms or security controls to manage sensitive operational credentials.

Sensitive information may include:

• Database credentials.
• API credentials.
• Encryption secrets.
• Service credentials.
• Authentication secrets.
• Integration credentials.

Operational secrets should not be intentionally embedded in publicly accessible source code.

Development and deployment processes may use environment variables, secret-management systems, or other mechanisms to reduce exposure.

Asiyst may maintain logs necessary for:

• Security monitoring.
• Troubleshooting.
• Auditing.
• Abuse prevention.
• Incident investigation.
• Service reliability.

Logs may contain technical and operational information.

Systems may be monitored for:

• Unauthorized access.
• Suspicious behavior.
• Credential misuse.
• API abuse.
• Security events.
• System anomalies.
• Availability problems.

Monitoring may generate alerts or trigger additional investigation.

Asiyst may identify and evaluate vulnerabilities through:

• Internal testing.
• Automated scanning.
• Dependency monitoring.
• Security reviews.
• External reports.
• Other appropriate security processes.

Vulnerabilities may be prioritized based on factors including:

• Severity.
• Exploitability.
• Exposure.
• Potential impact.
• Affected systems.

Asiyst may conduct security testing appropriate to its applications and infrastructure.

Testing may include:

• Application security testing.
• Dependency analysis.
• Configuration reviews.
• Vulnerability assessments.
• Other security evaluations.

Testing scope may vary between systems.

Security researchers and users are encouraged to report suspected vulnerabilities responsibly.

Reports should provide enough information to reproduce or investigate the issue.

Researchers should avoid:

• Accessing unnecessary data.
• Modifying customer information.
• Disrupting services.
• Destroying information.
• Conducting denial-of-service attacks.
• Exploiting vulnerabilities beyond what is necessary to demonstrate the issue.

A security incident may include an event that results in, or reasonably appears likely to result in:

• Unauthorized access.
• Unauthorized disclosure.
• Unauthorized modification.
• Loss of protected information.
• Credential compromise.
• Malicious system activity.
• Significant security disruption.

Not every security alert or operational error constitutes a security incident.

Asiyst maintains processes intended to respond to security incidents.

Response activities may include:

1. Detection.
2. Assessment.
3. Classification.
4. Containment.
5. Investigation.
6. Eradication.
7. Recovery.
8. Post-incident review.

When appropriate, Asiyst may take immediate measures to limit the impact of a security incident.

These measures may include:

• Revoking credentials.
• Restricting access.
• Isolating systems.
• Blocking malicious traffic.
• Disabling affected functionality.
• Restricting API access.

Asiyst may investigate security incidents to determine:

• What occurred.
• Which systems were affected.
• What information may have been involved.
• How the incident occurred.
• Whether unauthorized access occurred.
• What remediation is necessary.

Where appropriate, Asiyst may preserve relevant logs, system information, and other evidence necessary to investigate security incidents.

Evidence may be handled according to security, privacy, legal, and operational requirements.

Where notification is required by applicable law or contractual obligations, Asiyst may notify affected customers or other relevant parties through appropriate communication channels.

Notification timing may depend on the nature of the incident, investigation status, legal requirements, and security considerations.

Customers may be required to provide reasonable information necessary to investigate security incidents affecting their use of the Services.

Customers should promptly report suspected compromise of:

• Accounts.
• API keys.
• Access tokens.
• Integration credentials.
• Other Asiyst credentials.

Customers building applications with Asiyst remain responsible for securing those applications.

Customer responsibilities may include:

• Authentication.
• Authorization.
• Input validation.
• Secure credential storage.
• Dependency management.
• Data protection.
• Access control.
• Monitoring.
• Secure deployment.

Integrations may introduce additional security risks.

Customers should review:

• Requested permissions.
• Data access.
• Credential requirements.
• External service security.
• Data flows.

Customers should connect only services they are authorized to connect.

AI functionality may introduce security risks including:

• Prompt injection.
• Data extraction.
• Malicious instructions.
• Untrusted content.
• Model manipulation.
• Unauthorized tool use.
• Information disclosure.

Asiyst may use technical and operational controls designed to mitigate these risks.

Third-party AI providers may process information as part of AI functionality.

Their security practices are governed by their own systems, agreements, and policies.

Asiyst does not control the internal security architecture of independently operated third-party AI providers.

Knowledge sources may contain confidential or proprietary information.

Customers are responsible for ensuring that:

• They have rights to provide the information.
• Appropriate permissions are configured.
• Sensitive information is shared only with authorized users.
• Knowledge sources are maintained appropriately.

Customers deploying Asiyst avatars or assistants on websites are responsible for securely configuring the deployment.

Customers should consider:

• API security.
• Visitor permissions.
• Data collection.
• Knowledge-source access.
• External integrations.
• Client-side exposure.

Payment transactions may be processed through third-party payment providers.

Asiyst may receive transaction information necessary to operate billing and credit functionality.

Customers should review the applicable payment provider's security practices for payment processing.

Access to systems may be limited to authorized personnel based on business need and role.

Personnel with access to sensitive systems may be subject to confidentiality and security requirements.

Personnel involved in relevant operational, engineering, support, or security activities may receive security guidance appropriate to their responsibilities.

Where Asiyst uses third-party infrastructure providers, physical security of data centers and facilities may be managed by those providers.

Physical security controls may include:

• Facility access controls.
• Environmental protections.
• Surveillance.
• Monitoring.
• Other data-center security measures.

The exact controls depend on the applicable infrastructure provider.

Backups may be maintained to support:

• Disaster recovery.
• Service restoration.
• Data recovery.
• Operational continuity.

Backup access may be restricted according to applicable security controls.

Asiyst may maintain operational procedures intended to support recovery from significant service disruptions.

Continuity measures may include:

• Monitoring.
• Recovery procedures.
• Backup systems.
• Infrastructure redundancy where appropriate.
• Incident-response processes.

Recovery procedures may be used following events such as:

• Infrastructure failure.
• Data loss.
• Security incidents.
• Service outages.
• Provider failures.

Recovery capabilities vary by system and infrastructure.

Asiyst uses measures intended to maintain availability of its Services.

However, availability may be affected by:

• Maintenance.
• Infrastructure failures.
• Security incidents.
• Network problems.
• Third-party outages.
• Internet failures.
• Events outside Asiyst's reasonable control.

Security considerations may be reviewed when Asiyst changes:

• Infrastructure.
• Applications.
• APIs.
• AI providers.
• Integrations.
• Storage systems.
• Authentication systems.

Security requirements may change as the architecture evolves.

Asiyst may evaluate third-party providers based on considerations relevant to the services they provide.

Depending on the relationship, considerations may include:

• Security practices.
• Data handling.
• Reliability.
• Access controls.
• Contractual obligations.
• Service functionality.

The level of assessment may vary based on the nature and risk of the service.

Where third parties process customer information on behalf of Asiyst, applicable contractual arrangements may establish security and confidentiality requirements.

Additional information is available through the Subprocessors Policy.

Security measures support Asiyst's broader privacy and data-protection practices.

Personal information is handled according to the Privacy Policy and applicable data-protection requirements.

Security-related information may be retained as necessary for:

• Incident investigation.
• Fraud prevention.
• Abuse detection.
• Security monitoring.
• Legal compliance.
• Dispute resolution.

Retention periods vary depending on the type and purpose of the information.

Deletion of information may be subject to security, legal, operational, and backup requirements.

Information may remain in backups or security records for an applicable period after deletion from active systems.

Asiyst may provide additional security documentation to eligible customers where appropriate.

Such documentation may include:

• Security architecture information.
• Data-flow information.
• Control descriptions.
• Subprocessor information.
• Assessment information.
• Other security materials.

Some information may be restricted because disclosure could create security risks.

Where Asiyst conducts or obtains security assessments or certifications, their scope applies only to the systems and services expressly covered by the assessment or certification.

A certification or assessment does not guarantee that every Asiyst service, integration, or third-party provider has identical controls.

Security controls are designed to reduce risk but cannot eliminate all security threats.

Asiyst does not guarantee that:

• Security incidents will never occur.
• Vulnerabilities will never exist.
• Unauthorized access will never occur.
• Data will never be lost.
• Third-party providers will never experience security incidents.

Asiyst may modify security practices in response to:

• New threats.
• Vulnerabilities.
• Technology changes.
• Product changes.
• Infrastructure changes.
• Regulatory requirements.
• Security assessments.
• Lessons learned from incidents.

Customers should:

• Protect account credentials.
• Protect API keys.
• Configure permissions appropriately.
• Secure applications.
• Maintain dependencies.
• Monitor activity.
• Restrict access.
• Review integrations.
• Report suspected security incidents.

Developers using Asiyst APIs, SDKs, or CLI tools should:

• Protect credentials.
• Avoid exposing server-side keys.
• Validate application inputs.
• Implement appropriate authorization.
• Protect user data.
• Monitor their applications.
• Keep dependencies reasonably current.
• Follow applicable Asiyst developer and API requirements.

Users should:

• Protect their login credentials.
• Avoid sharing authentication information.
• Use trusted devices and networks where appropriate.
• Report suspicious activity.
• Avoid intentionally bypassing security controls.

Users must not intentionally:

• Bypass authentication.
• Circumvent authorization.
• Access another user's information without authorization.
• Exploit vulnerabilities for malicious purposes.
• Introduce malware.
• Conduct denial-of-service attacks.
• Abuse API credentials.
• Interfere with security controls.
• Attempt unauthorized system access.

Additional restrictions may apply under the Acceptable Use Policy and AI Usage Policy.

Security concerns should be reported promptly through the security contact method provided by Asiyst.

A useful report should include:

• Description of the issue.
• Affected service.
• Steps to reproduce.
• Potential impact.
• Relevant technical information.

Do not include unnecessary personal or confidential information in a security report.

Security communications may be delivered through:

• Email.
• Account notifications.
• Service notifications.
• Other appropriate communication channels.

Customers should maintain accurate contact information for their accounts.

Certain systems, features, or third-party services may have security requirements that differ from this general policy.

Where a specific contractual or technical security requirement applies, that requirement may govern the relevant service.

Asiyst may update this Security Policy when its security practices, Services, infrastructure, legal obligations, or operational requirements change.

The current version will be made available through the applicable Asiyst website or service.

This Security Policy should be read together with:

• Security & Trust Center.
• Incident Response & Security Breach Policy.
• Privacy Policy.
• Data Processing Agreement.
• Data Retention Policy.
• Data Deletion Policy.
• Subprocessors Policy.
• Service Availability / Status Policy.
• Service Level Agreement.
• API Terms.
• Developer Terms.
• Terms of Service.
• Acceptable Use Policy.

Where a separate written agreement contains specific security obligations, that agreement may govern the applicable relationship to the extent stated in that agreement.

Security questions, vulnerability reports, and security concerns should be submitted through the security contact method provided by Asiyst.

When reporting a security issue, provide sufficient information for investigation while avoiding unnecessary disclosure of sensitive information.