Security Policy

01Purpose and scope

This policy describes the technical and organisational measures Alto Foundry Pty Ltd ("Alto Foundry", "we") uses to protect customer data. It applies to Archer Cloud, to the software we supply for Customer-Hosted Products (RedactAI, and Archer on customer infrastructure), to evaluation and demonstration environments, and to our own systems and people.

Our Cloud Service Agreement and Customer-Hosted Software Agreement refer to this policy. We may improve these measures over time, but we will not materially reduce the overall protection they give customer data during a customer's subscription.

02Deployment models at a glance

Whichever model is used, Archer turns speech into text and separates speakers on the user's computer. Meeting audio is held in memory only and is never written to a file or uploaded.

03Governance and people

• We run a documented information security management system: a set of policies covering acceptable use, access control, asset management, data classification, encryption, secure development, logging, vendor risk, people security, training, risk management, business continuity and incident response.
• Our Information Security Lead owns these policies, and a co-founder approves them. They are reviewed at least once a year, and after any material incident or change to our architecture. Exceptions must be approved, time-limited and recorded.
• We classify customer documents and personal information as Restricted, our highest class. Restricted data is accessed only with a business need, kept only on approved systems, and never pasted into chat, personal tools or consumer AI products.
• Everyone who works for us is bound by confidentiality obligations that continue after they leave. They complete security awareness training before they get access to production systems, and again every year.
• Laptops used for our work have full-disk encryption, receive security updates promptly, and lock when unattended. We use multi-factor authentication for Microsoft Entra ID, production Azure, GitHub and other critical systems.
• Everyone has their own account, and access is granted on least privilege. Privileged roles are held by as few people as possible. Production and administrative access is reviewed at least once a year, and removed on the day someone leaves wherever practicable.
• We assess information security risks at least once a year, and after material changes or serious incidents. Decisions to accept residual risk are made explicitly by the founders.

04Archer Cloud

Hosting and data residency

Archer Cloud runs on Microsoft Azure in the Australia East region. Accounts, meeting content and transcripts are stored there. AI requests are processed there too (section 6).

Encryption

• All traffic between the Archer app and the service uses TLS 1.2 or later.
• Databases and storage are encrypted at rest with AES-256, using keys managed by Microsoft Azure.

Network

• The database, transcript storage, key vault and AI service are reachable only through private endpoints inside our virtual network, and have public network access turned off.
• Only the Archer service is exposed to the internet, over HTTPS, and every request to it except public health checks and personal status links must be authenticated.

Identity and access

• People sign in with Google or Microsoft. The service checks the provider's signature, audience and expiry, then issues its own short-lived access token.
• Refresh tokens are stored only as hashes and replaced each time they are used. Access is re-checked on every refresh, so removing someone ends their session within one access token's lifetime.
• Every record belongs to one workspace, and every request is scoped to the signed-in person's workspace. Members of an organisation see only what its sharing rules allow.
• Status links for external attendees are long, random and limited to posting that person's update.

Secrets

Keys for the AI models, email service and token signing are held in Azure Key Vault and read by the service through a managed identity. No keys are stored in source code, configuration files or the desktop app.

Operational access

Production access is limited to named engineers who need it, requires multi-factor authentication, and is logged. We look at customer content only to provide support you have asked for, to investigate a security issue, or where the law requires it.

The Archer desktop app

• Speech recognition and speaker separation run on the device. Only the resulting text and speaker timings are sent to the service.
• The app signs in with short-lived tokens and holds no keys for AI models or email.
• App updates are signed, and the app checks the signature before installing them.
• The app keeps settings, speech models and copies of transcripts for meetings the user is in. These are protected by the device's own security, so we recommend full-disk encryption on every computer that runs Archer.

Connected AI apps

When a person connects an AI app such as ChatGPT or Claude, the app acts as that person and sees only what they can see. It cannot read transcripts unless the organisation turns this on. It can add items, but cannot delete anything or confirm a decision. Each person can see their connected apps' recent actions, and disconnect them, in Settings.

05Customer-Hosted Products

RedactAI is always deployed into the customer's own cloud environment. Archer can also be deployed this way. We supply the software as container images, infrastructure templates and deployment guides. The customer runs it.

Reference architecture

• Private access: the application has no public endpoint. Users reach it over the customer's VPN, ExpressRoute or private link.
• Customer identity: users sign in through the customer's Microsoft Entra tenant. Only members of assigned security groups can use the application, and the customer's Conditional Access policies apply.
• Private data services: the database, document storage, key vault, document recognition and AI services all have public access turned off and are reached through private endpoints.
• Managed identities: the application reaches each service with a managed identity granted only the roles it needs. There are no long-lived keys in configuration.
• Encryption: TLS 1.2 or later in transit. Encryption at rest using the cloud provider's keys, or the customer's own keys where the customer configures them.
• Audit: sign-in, upload, redaction, export and other key actions are recorded as audit events in the customer's own monitoring workspace.
• No phone-home: the software does not send content, usage measures or telemetry to Alto Foundry.

Shared responsibility

Support access

We have no standing access to a customer environment. If the customer grants access for support or deployment, it is through the customer's own controls, limited to what is needed, time-bound, and ends when the work is done.

06AI security

Models and processing location

Archer Cloud uses models from Microsoft Azure OpenAI, deployed in our Azure subscription in Australia East as regional deployments, not global ones. Requests are made only by the Archer service, over a private endpoint, and are processed in Australia.

Customer-Hosted Products use the AI service the customer configures. The default is Azure OpenAI in the customer's own subscription. A customer can choose another provider, and if it does, that provider's terms apply to the data sent to it.

No training on customer data

We do not use customer content to train or fine-tune AI models. Under Microsoft's terms for Azure OpenAI, prompts and responses are not used to train Microsoft's or OpenAI's models, and are not available to other customers. Search by meaning in Archer runs inside the Archer service itself and does not send content to a third party.

Limiting what AI can do

• Each AI request includes only the content needed for the task, from the requesting person's workspace.
• AI output is a draft or proposal. Archer notes are drafts until a person reviews them, and RedactAI findings are applied only when a reviewer accepts them.
• Content from documents and meetings is treated as data, not instructions. Connected AI apps cannot delete anything or confirm decisions, so a misleading instruction hidden in content cannot remove records.
• Responses from models are checked against an expected structure before they are saved.

07Secure development

• Changes to production code, infrastructure and configuration go through a pull request, reviewed by someone other than the author, on a protected branch. Changes touching sign-in, permissions, encryption, customer data or public endpoints get explicit security review.
• Routine development does not need production privileges. Production is changed through our documented deployment path, not by hand.
• Development, demonstration and production environments are separate. We do not use customer data in development or testing; we use synthetic or sanitised data.
• Dependencies are kept current. Known high-severity vulnerabilities in them are assessed and fixed, or accepted with a short-term plan. Third-party and open-source components are listed in each product's notices.
• Secrets are kept in Azure Key Vault, never in source code. A secret that is exposed is rotated immediately and treated as a possible incident.
• Releases of Customer-Hosted Products are versioned, built from reviewed source, and come with release notes that call out security fixes.

08Logging and monitoring

• Archer Cloud sends security-relevant events to Azure Application Insights and Azure Monitor, including sign-ins, administrative actions in Azure, deployments and configuration changes, and errors that could indicate misuse.
• Logs use identifiers and outcomes. They avoid unnecessary personal information and never contain meeting or document content.
• Access to logs is limited to people who need it, and logs must not be altered or deleted. Logs are kept for as long as needed to investigate incidents, and preserved from deletion while an investigation is open.

09Backup and availability

• The Archer Cloud database is backed up automatically by Azure with point-in-time restore. Backups are encrypted, kept in Australia, and retained for up to 35 days.
• Because transcription runs on the device, people can keep recording if the service is briefly unavailable. Text is sent when the connection returns.
• Our internal recovery targets are to restore critical service within 48 hours (recovery time objective) with no more than 24 hours of data loss (recovery point objective).
• We test restoring a production backup to a separate environment at least once a year, and record the result.
• Any availability commitment is set out in the customer's Order Form.

10Incident response and breach notification

We follow a written incident response policy and procedure: detect, classify severity, contain, eradicate, recover, notify, and learn. Anyone who works for us must report a suspected incident straight away, without waiting to be certain. Every incident is recorded in our incident log, and evidence is preserved for investigation.

• If we confirm a security incident that affects a customer's data, we notify the customer without undue delay, and in any case within 72 hours of confirming it.
• Our notice describes what happened, the data affected, what we have done and what the customer should do, and we update it as we learn more.
• We assess suspected eligible data breaches under the Notifiable Data Breaches scheme within 30 days, and notify the OAIC and affected individuals where required. Where the customer is the responsible entity, we support it to do so.
• After any medium or high severity incident, we review the root cause and track the fixes to completion. We share a summary with affected customers.
• For Customer-Hosted Products, the customer runs incident response for its environment. If we find a vulnerability in our software, we tell affected customers and provide a fix or workaround.

11Sub-processors

We keep an inventory of the providers that handle company or customer data. Before any provider receives customer data, we assess its security and put a data processing agreement or equivalent terms in place. We share only the minimum data it needs, review each provider at least once a year and after any material change, and confirm deletion when we stop using it. Microsoft Azure is our primary cloud; we do not place customer data with another hosting provider without prior assessment and approval. These providers process customer data for Archer Cloud:

Customer-Hosted Products send no customer data to us or our providers. They use the services in the customer's own cloud environment.

We will give customers at least 30 days' notice before we add or replace a sub-processor for Archer Cloud, by email and by updating this list. A customer that reasonably objects may end the affected service and receive a pro-rata refund of prepaid fees.

12Evaluations and demonstrations

• Sample documents for an evaluation are uploaded through short-lived, single-use links into private storage in Microsoft Azure in Australia. Upload access is protected by an access code that we rotate after each evaluation.
• Our demonstration environment is in Australia, requires sign-in with an assigned account, and keeps its data services on private networks.
• We delete evaluation material within 30 days after the evaluation ends, or sooner if asked.
• We ask everyone to use sanitised or representative material wherever possible.

13Compliance and assurance

Alto Foundry does not yet hold an independent security certification. Microsoft Azure, which hosts Archer Cloud and our reference deployments, holds certifications including ISO/IEC 27001 and SOC 2, and has been assessed under the Australian Government's IRAP program.

We are happy to complete security questionnaires, walk through our architecture, and share our information security policies and deployment documentation with customers under a confidentiality agreement.

14Reporting a vulnerability

If you believe you have found a security vulnerability in our website or products, email hello@alto-foundry.com.au with "Security" in the subject line. Please include enough detail for us to reproduce the issue.

We will acknowledge your report within 2 business days and keep you updated. We ask that you give us reasonable time to fix the issue before sharing it publicly, do not access or change other people's data, and do not run tests that could harm the availability of our services. We will not take legal action against people who report in good faith and follow these guidelines.