Security & Trust Center

Asiyst is committed to maintaining reasonable technical and organizational measures designed to protect information and maintain the confidentiality, integrity, and availability of its Services.

This Security & Trust Center describes the principal areas of Asiyst's security program.

It is intended to provide customers, developers, business users, and other interested parties with a general understanding of how security is addressed within the Asiyst platform.

Asiyst's security practices are designed around the following principles:

• Confidentiality.
• Integrity.
• Availability.
• Least-privilege access.
• Defense in depth.
• Secure development.
• Monitoring and detection.
• Incident response.
• Data minimization.
• Appropriate access controls.
• Continuous improvement.

The specific controls implemented may vary depending on the applicable product, infrastructure, service provider, and technical requirements.

Security measures may apply to:

• Asiyst websites.
• Web applications.
• User accounts.
• Projects.
• Workspaces.
• APIs.
• SDKs.
• CLI tools.
• AI assistants.
• Avatars.
• Knowledge sources.
• Uploaded content.
• Databases.
• Storage systems.
• Authentication systems.
• Internal administrative systems.
• Infrastructure.
• Integrations.

Third-party services used by Asiyst may maintain their own independent security programs.

Security is a shared responsibility.

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

Customers and users are responsible for security measures within their own environments, applications, accounts, integrations, devices, credentials, and configurations.

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

Asiyst uses authentication and access-control mechanisms designed to help protect user accounts.

Users should:

• Use strong and unique credentials.
• Protect authentication information.
• Avoid sharing account credentials.
• Enable available security controls.
• Review account activity.
• Report suspected unauthorized access.

Authentication mechanisms are used to verify users and authorized applications.

Depending on the Service, authentication may involve:

• Account credentials.
• Sessions.
• API keys.
• Access tokens.
• OAuth or similar authorization mechanisms.
• Other authentication controls.

The authentication method may vary between the Asiyst website, API, SDK, CLI, and integrations.

Authorization controls are used to determine what users and applications are permitted to access.

Where applicable, permissions may be associated with:

• Users.
• Projects.
• Workspaces.
• Organizations.
• Roles.
• API credentials.
• Integrations.

Access is intended to follow the permissions configured for the relevant account or resource.

Asiyst aims to limit access to information and systems to what is reasonably necessary for an authorized purpose.

Access may be restricted based on:

• Role.
• Function.
• Project.
• Workspace.
• Operational responsibility.
• Security requirements.

Administrative access to systems containing customer or operational information may be restricted to authorized personnel or systems.

Administrative access may be subject to authentication, authorization, logging, monitoring, and other security controls.

Asiyst may rely on cloud infrastructure and other specialized service providers to operate its Services.

Infrastructure may include:

• Compute systems.
• Databases.
• Object storage.
• Networking.
• Application hosting.
• Monitoring systems.
• Security services.

Security controls may be implemented at multiple infrastructure layers.

Asiyst uses technical measures intended to protect information during processing and storage.

Depending on the system and information involved, these measures may include:

• Encryption.
• Access controls.
• Authentication.
• Network protections.
• Logging.
• Monitoring.
• Secure configuration.
• Credential management.

The specific security controls applicable to a particular service may vary.

Where appropriate, Asiyst may use encryption to protect information:

• During transmission.
• At rest.
• In storage.
• During communications between services.

The availability and implementation of encryption may depend on the specific system, provider, and type of information.

Asiyst APIs are designed to use authentication and authorization mechanisms appropriate to the applicable API.

API security measures may include:

• API keys.
• Access tokens.
• Authentication validation.
• Authorization checks.
• Rate limiting.
• Request validation.
• Logging.
• Abuse detection.

Customers are responsible for securely storing and using their API credentials.

API keys should be treated as confidential credentials.

Customers should not:

• Publish API keys in public repositories.
• Embed sensitive API keys in publicly accessible client-side code.
• Share keys unnecessarily.
• Store keys in insecure locations.

If an API key is suspected to be compromised, it should be revoked or rotated as soon as reasonably possible.

Asiyst SDKs may provide mechanisms for integrating Asiyst functionality into customer applications.

Customers remain responsible for securely configuring their applications and ensuring that sensitive credentials are not exposed through client-side code or other publicly accessible environments.

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

Users should:

• Install the CLI from trusted sources.
• Protect locally stored credentials.
• Avoid sharing configuration files containing secrets.
• Review permissions granted to the CLI.
• Keep supported versions reasonably current.

Customers building applications using Asiyst are responsible for securing their own applications.

This includes:

• Application authentication.
• Authorization.
• Session security.
• Credential storage.
• Input validation.
• Dependency management.
• Access controls.
• Secure deployment.
• Protection of end-user information.

AI functionality may introduce security risks associated with:

• Prompt injection.
• Malicious instructions.
• Data leakage.
• Unauthorized tool use.
• Untrusted knowledge sources.
• Manipulation of AI-generated responses.
• Malicious content.

Asiyst may implement technical and operational controls intended to reduce these risks.

AI security controls may vary by model, provider, feature, and deployment architecture.

Knowledge sources connected to Asiyst may contain customer-controlled or third-party information.

Access to knowledge sources should be configured according to the intended audience and authorization requirements.

Customers are responsible for ensuring that the information they provide to Asiyst may lawfully be processed and made available to the relevant users or applications.

Uploaded files and other customer-provided content may be processed according to the functionality selected by the customer.

Customers should avoid uploading information that they are not authorized to provide or that is unnecessary for the intended purpose.

Certain Asiyst AI features may use third-party AI providers.

The security and privacy characteristics of AI processing may therefore depend partly on the applicable provider.

Third-party providers may maintain their own security controls, policies, certifications, infrastructure, and incident-response procedures.

Asiyst may use third-party providers for services including:

• Cloud infrastructure.
• Storage.
• Authentication.
• AI processing.
• Payment processing.
• Email delivery.
• Analytics.
• Monitoring.
• Security.
• Customer support.

These providers may have independent security obligations under their agreements with Asiyst.

Where Asiyst processes customer information on behalf of customers, certain third-party service providers may act as subprocessors.

Applicable subprocessors may process information only for the services they provide to Asiyst, subject to applicable contractual arrangements.

The current list of relevant subprocessors may be provided through the Asiyst Subprocessors Policy.

Asiyst may monitor systems and services for:

• Unauthorized access.
• Suspicious activity.
• Abuse.
• Security events.
• Performance problems.
• Availability issues.
• Operational failures.

Monitoring information may be used to investigate and respond to security or operational events.

Asiyst may maintain logs relating to:

• Authentication.
• API requests.
• Administrative activity.
• Security events.
• System activity.
• Errors.
• Infrastructure events.
• Account activity.

Logs may be used for security, troubleshooting, auditing, abuse prevention, and service reliability.

Asiyst may use processes designed to identify, evaluate, prioritize, and address security vulnerabilities.

Depending on the system, these processes may include:

• Security testing.
• Dependency monitoring.
• Vulnerability scanning.
• Code review.
• Configuration review.
• Security assessments.
• Remediation procedures.

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

Security considerations may be incorporated into the development and maintenance of Asiyst software.

Development security practices may include:

• Code review.
• Dependency management.
• Access controls.
• Testing.
• Security testing.
• Environment separation.
• Credential management.
• Deployment controls.

The exact development process may vary by component.

Software dependencies may introduce security vulnerabilities.

Asiyst may monitor or update dependencies where appropriate and may take additional measures when security vulnerabilities are identified.

Customers using Asiyst SDKs or CLI tools are responsible for maintaining their own application dependencies and deployment environments.

Where appropriate, Asiyst may separate development, testing, staging, and production environments.

Access to production environments may be restricted according to operational requirements.

Asiyst may use security controls designed to protect operational credentials and secrets.

Credentials may include:

• API credentials.
• Database credentials.
• Service credentials.
• Encryption-related secrets.
• Authentication secrets.
• Third-party integration credentials.

Users are responsible for protecting credentials under their control.

Sensitive credentials should not be unnecessarily exposed in:

• Source code.
• Public repositories.
• Client-side applications.
• Logs.
• Documentation.
• Screenshots.
• Support requests.

Asiyst may implement controls intended to reduce accidental exposure of sensitive information.

Where personnel have access to systems containing sensitive information, access may be restricted according to role and operational necessity.

Personnel may be subject to confidentiality and security requirements.

Personnel involved in operating or maintaining relevant systems may receive security-related guidance, procedures, or training appropriate to their responsibilities.

Asiyst maintains processes intended to identify, investigate, contain, and respond to security incidents.

Incident response may include:

1. Detection.
2. Initial assessment.
3. Classification.
4. Containment.
5. Investigation.
6. Remediation.
7. Recovery.
8. Post-incident review.

Additional information is provided in the Incident Response & Security Breach Policy.

If Asiyst determines that a security incident requires customer notification under applicable law, contractual requirements, or other applicable obligations, Asiyst may provide notification through an appropriate communication channel.

The timing and content of notification may depend on:

• Nature of the incident.
• Information affected.
• Applicable law.
• Contractual requirements.
• Investigation status.
• Security considerations.

Customers are responsible for reporting suspected security incidents affecting their use of Asiyst where notification is appropriate.

Examples include:

• Compromised API keys.
• Unauthorized account access.
• Stolen credentials.
• Suspicious API activity.
• Unauthorized integrations.

Security researchers and users may report suspected vulnerabilities through the security contact method provided by Asiyst.

Reports should include sufficient technical information to allow the issue to be investigated.

Security testing against Asiyst systems should be conducted only when authorized.

Unauthorized penetration testing, scanning, exploitation, denial-of-service testing, or attempts to gain unauthorized access may violate applicable policies.

Asiyst uses operational measures intended to maintain service availability and recover from disruptions.

These may include:

• Monitoring.
• Backups.
• Redundancy where appropriate.
• Incident response.
• Recovery procedures.
• Infrastructure controls.

No system can guarantee uninterrupted availability under all circumstances.

Asiyst or its infrastructure providers may maintain backups for operational recovery, security, and continuity purposes.

Backups may contain information that has been deleted from active systems until the applicable backup lifecycle is completed.

Backup handling is subject to applicable retention and deletion practices.

Asiyst may maintain procedures designed to support continued operation or recovery following significant operational disruptions.

The specific procedures may vary based on the affected system and severity of the event.

Where appropriate, Asiyst may maintain recovery mechanisms for critical systems.

Recovery procedures may address:

• Infrastructure failures.
• Data loss.
• Security incidents.
• Service interruptions.
• Provider outages.
• Other significant operational events.

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

Asiyst may receive transaction information necessary to manage billing but may not directly store full payment-card information when payment processing is handled by the applicable provider.

Customers should review the applicable payment provider's security and privacy documentation.

Security controls are part of Asiyst's broader privacy and data-protection practices.

Information concerning collection, processing, retention, deletion, and individual privacy rights is described in the Privacy Policy and related policies.

Certain security information may need to be retained to:

• Investigate incidents.
• Detect recurring attacks.
• Prevent fraud.
• Maintain system security.
• Meet legal obligations.
• Resolve disputes.

Retention periods may vary according to the type and purpose of the information.

Asiyst may provide mechanisms for deleting accounts or certain customer information.

Deletion may be subject to:

• Legal retention requirements.
• Security requirements.
• Backup lifecycles.
• Financial record requirements.
• Active disputes.
• Fraud-prevention requirements.

Additional information is provided in the Data Deletion Policy.

Customers should maintain appropriate security controls over their own environment.

This includes:

• Protecting credentials.
• Managing user permissions.
• Securing applications.
• Keeping dependencies updated.
• Monitoring account activity.
• Configuring integrations securely.
• Limiting access to authorized personnel.

When customers deploy Asiyst assistants, SDKs, or APIs into their own applications, security depends partly on the customer's implementation.

Customers should review:

• API key placement.
• Authentication.
• Authorization.
• Data exposure.
• Client-side code.
• Server-side configuration.
• User permissions.
• Integration security.

AI assistants and avatars may interact with information supplied by customers or end users.

Customers should configure assistant permissions and knowledge sources appropriately.

Customers should also avoid granting unnecessary access to sensitive information or external systems.

If an Asiyst integration supports automated actions, customers are responsible for determining appropriate permissions and safeguards.

Automated systems should not be granted more authority than necessary to perform their intended function.

Connecting Asiyst to another service may require granting permissions to that service or allowing data to flow between systems.

Customers should review the permissions requested by integrations before enabling them.

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

Additional documentation may include information concerning:

• Architecture.
• Security controls.
• Data flows.
• Subprocessors.
• Operational practices.
• Compliance information.

Availability of additional documentation may depend on customer type, contractual requirements, and confidentiality considerations.

Asiyst may conduct or obtain security assessments appropriate to its services and operational requirements.

The scope, methodology, frequency, and results of such assessments may vary.

Any third-party assessment or certification should be understood according to its specific scope and validity rather than as a guarantee of security under all circumstances.

Where Asiyst obtains a security certification or independent assessment, applicable information may be made available through the Security & Trust Center or appropriate customer documentation.

Asiyst does not represent that a certification or assessment covers systems, products, or services outside its stated scope.

Security measures reduce risk but cannot eliminate all security threats.

Asiyst cannot guarantee that:

• Unauthorized access will never occur.
• Data will never be lost.
• Services will never be attacked.
• Vulnerabilities will never exist.
• Third-party providers will never experience incidents.
• Every security threat will be detected immediately.

Asiyst may modify and improve security controls as technology, threats, infrastructure, regulations, and service architecture evolve.

Security practices may therefore change over time.

Asiyst seeks to provide customers with appropriate information regarding significant security practices and events.

Certain technical details may not be publicly disclosed where disclosure could create additional security risk.

Customers may contact Asiyst regarding security-related questions, documentation, assessments, or concerns.

Certain requests may require verification of the requester's identity and authority.

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

Security reports should contain enough information to allow Asiyst to investigate the issue while avoiding unnecessary disclosure of sensitive information.

This Security & Trust Center should be read together with:

• Security Policy.
• 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.
• Terms of Service.
• Developer Terms.
• API Terms.

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

Asiyst may update this Security & Trust Center as its security program, infrastructure, products, service providers, or security practices change.

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

For security questions, security documentation requests, vulnerability reports, or other security-related matters, contact Asiyst through the security contact method provided on the Asiyst website.