Trust at Jaspyr

Security at Jaspyr

Jaspyr connects information across your organisation's systems. Our security practices focus on controlling who can access that information, protecting it during processing and keeping a record of important activity. This page describes our platform safeguards and the choices we agree with customers.

Hosting and data location

Our core production platform runs on Amazon Web Services in Sydney, Australia. Selected encrypted key-recovery material is held in Melbourne. For customers using our Australian Amazon Bedrock configuration, AI inference can run in Sydney or Melbourne.

Customers using direct AI providers or other connected services may have additional processing outside Australia. We agree the relevant integration, provider and location requirements with each customer. Australian hosting alone does not make every integration Australia-only.

Identity and access

Application sign-in uses Amazon Cognito. Native accounts require an authenticator app for multi-factor authentication. Customers using single sign-on manage authentication and MFA through their own identity provider.

The platform checks organisation membership and permissions when handling requests. Its authorisation rules deny access when no rule permits it and reject access across organisation boundaries. Platform administration and access to customer work are separate permissions. An administrative role does not by itself grant access to every customer's data.

Human access to the AWS environment uses federated sign-in with MFA. Application services use AWS roles with short-lived credentials. Access to customer integrations uses credentials associated with the relevant customer and service.

Encryption and credential protection

Public application connections use HTTPS with TLS 1.2 or later. Production databases, storage volumes, object storage and backups use encryption at rest. Selected personal fields, model audit content and integration credentials also have application-level encryption.

We use AWS Key Management Service to protect encryption keys and approved secret stores to hold service credentials. Organisation-specific keys protect selected customer records. Our deployment workflows use federated AWS credentials rather than stored AWS access keys.

Deletion of particular encryption keys can make the protected content unreadable. This applies to the fields and records covered by that encryption, rather than every record associated with a customer.

Customer separation and integrations

Our multi-tenant platform applies organisation boundaries through its authorisation checks, data access and customer-specific credentials. Automated tests cover denied access and cross-organisation access scenarios.

The permissions available through a connected system depend on the integration and the credentials the customer authorises. Customers should grant only the access required for the intended service. We confirm the scope for each implementation, including whether an integration reads information or performs authorised workflow actions.

AI processing

AI features use the provider configured for the customer. For Amazon Bedrock customers, we use customer-specific AWS roles and Australian inference profiles. The Australian configuration restricts calls to the approved Australian regions and profiles. Direct Anthropic and OpenAI integrations use the customer's own provider accounts and keys.

AI requests can contain the customer's questions, documents and relevant context retrieved from connected systems. We do not claim that all personal information is removed before processing. We do not use customer personal information to train or fine-tune AI models.

We protect platform-side model audit records separately from provider-side processing. Provider retention and handling depend on the route, model, service terms and configuration. We confirm those arrangements for customers with specific restrictions rather than treating all AI services as equivalent.

Development and release controls

We manage application and infrastructure changes in version control. Our delivery workflows run automated tests and checks for exposed secrets, vulnerable dependencies, container-image issues and other security findings. Some checks block a release or merge; others produce findings for review and treatment.

Deployment records link running application versions to their source revision. Container builds produce software inventories and signatures. Application images run without root privileges, and deployment checks verify rollout and basic service health. Rollback procedures use previously built versions.

We use synthetic fixtures for routine automated testing. Any use of production-derived information requires separate handling appropriate to its sensitivity.

Logging and security monitoring

We collect application, infrastructure and cloud audit logs. These include denied access and security-relevant administrative activity. Our logging includes controls to redact credentials, secrets and selected sensitive fields.

AWS CloudTrail records cloud activity, and GuardDuty provides threat-detection findings for enabled data sources. Configured alarms cover selected operational and security events. Automated security checks also run on a schedule. These measures support investigation and response.

Backups and recovery

Core production databases and stateful storage have scheduled backups with 30-day retention. Object versioning provides additional recovery options for selected stores. We maintain operational and recovery runbooks, and selected wrapped encryption keys have a recovery copy in a second Australian region.

Recovery arrangements depend on the service and the failure scenario. The second-region key copy supports recovery of the encrypted material it protects. Any availability, recovery-time or recovery-point commitment is set out in the applicable customer agreement.

Security governance and incident response

Our information security management system is structured around ISO/IEC 27001. It includes policies, risk assessment, supplier review, evidence collection and corrective-action tracking. We assess material changes to personal-information processing through our privacy impact assessment process.

We maintain an incident response process to assess suspected incidents, contain harm, investigate and coordinate recovery. Customer communication follows the applicable agreement and legal duties. Where a privacy breach is notifiable under New Zealand law, notification is made as soon as practicable, subject to the statutory requirements and exceptions.

Security questions and procurement

Contact security@jaspyr.ai for security questions or to report a suspected vulnerability. Privacy enquiries can be sent to privacy@jaspyr.ai. Please start with a brief description and avoid sending passwords, access tokens or customer records by email. We can arrange an appropriate way to exchange sensitive details.

During procurement, we can discuss the relevant architecture, data flows, provider arrangements and available assurance evidence. We confirm the scope, date and status of assurance material rather than treating this overview as an audit report or a contractual service-level commitment.