Security overview

In short

• Your records and files are stored in Australia, and the AI runs in Australia.
• Each workspace is kept apart from every other: its own schema in the database, and its own environment in the service that decides who may do what.
• Data is encrypted at rest with AES-256, and in transit over public networks with TLS 1.2 or later.
• Every change is recorded on an audit trail kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident.
• Pyron holds no security certification yet, and no independent penetration test has been done. What we don't have yet says what is still to come.

Where your data is held

Pyron is hosted by Amazon Web Services (AWS) in Australia. The records, forms, pages, automations, files and comments in a workspace, its audit trail and its backups are stored in the AWS Asia Pacific (Melbourne) region, with a copy of the database's backups in the AWS Asia Pacific (Sydney) region. Some services run in the AWS Asia Pacific (Sydney) region: sending email, building the index behind search by meaning, and the gateway web searches go through. Pyron AI runs on Amazon Bedrock in Australia.

A few of our service providers handle limited information outside Australia. Data locations names every provider, what it receives and where.

Encryption

• At rest. The database, its backups and stored files are encrypted with AES-256 under keys held in AWS Key Management Service, which rotate automatically.
• In transit. Pyron is served only over HTTPS, with TLS 1.2 or later (TLS 1.3 where the browser supports it), and tells browsers never to use plain HTTP. The database refuses any connection that isn't encrypted, and file storage refuses any request that isn't.
• Credentials. Logins a workspace keeps in the Pyron Vault are stored encrypted, apart from the database. A hidden value is never shown to the AI, which reads only a hint of what the value is for, and a value is only ever sent to the web addresses its login allows.
• Sign-in secrets. The secrets behind authenticator apps are encrypted a second time inside the database.

Keeping each workspace separate

• Each workspace's data lives in its own schema in the database, and every request is answered inside the schema of the workspace it was made to.
• Each workspace has its own environment in our authorisation service. A person's sign-in names the workspace it was issued for, and no other workspace accepts it.
• Tests that try to reach one workspace's data from another run on every change.
• The database server and the computing cluster are shared between workspaces. A workspace does not have a database server or infrastructure of its own.

Signing in and access

• Two-step sign-in. People sign in with a password or through single sign-on. Two-step sign-in works with an authenticator app, a passkey or a code sent by email, and a workspace admin can make it required. Admins also choose how long a session lasts and how soon an idle session signs out.
• Single sign-on. A workspace can sign its people in through Microsoft Entra ID, Okta, Google Workspace or another SAML or OpenID Connect provider, and can make it the only way in. Single sign-on runs on Amazon Cognito, in AWS in Australia. A person is created the first time they sign in.
• Failed sign-ins. Repeated failed sign-ins are slowed down, and each further failure waits longer. The answer is the same whether or not the account exists, guesses made elsewhere never hold up an address the person has signed in from recently, and each pause is recorded on the audit trail; the person is emailed.
• Roles and sharing. What a person can see and do comes from their roles and from what has been shared with them, and access to a place flows down to everything beneath it. The permission engine's default answer is no.
• Guests. People outside the business sign in with a six-digit code we email them, which works only in the browser that asked for it. A guest sees only what has been shared with them.
• Pyron Support. Techly's support engineers can sign in to a workspace to help, unless its administrators have turned Support access off. It is on until they do, and they can turn it off or back on at any time; turning it off ends any Support session in the workspace at its next request, and Support cannot turn it back on. Support signs in only through Techly's own single sign-on, which enforces two-step verification, and a Support session is time-limited and cannot be extended. Inside a workspace, Support has full access. What Support views and changes is recorded on the workspace's audit trail as "Support", and our internal record names the engineer.
• View as. A workspace admin, or Support, can view Pyron as a particular person, to see what they see. A view-as session needs a reason, cannot change anything, ends within 60 minutes, and is recorded on the audit trail, naming who viewed and as whom.
• Our own access. Our engineers sign in to AWS through single sign-on with two-step verification, in sessions that expire. The production database accepts only short-lived sign-in tokens, never a stored password. Our GitHub organisation requires two-factor authentication.

The audit trail

Pyron keeps an audit trail of every change in a workspace, in plain words, whether a person, an automation, the AI or Support made it. It is kept for 24 months: records are only ever added, never edited, and each is cryptographically linked to the one before it, so tampering would be evident.

What people view is recorded too, and so are attempts the permission engine refuses. A workspace's admins read its trail in Pyron.

Application security

• Every change a person, an automation or the AI makes goes through the same path, which asks the permission engine before anything is written.
• Requests to Pyron's API are rate-limited at our network edge and again in the application, and Cloudflare's managed firewall rules, including the OWASP Core Ruleset, run in front of Pyron.
• Every uploaded file is scanned for malware before anyone can open it.
• When Pyron fetches a web address for an automation or the assistant, it refuses private and internal addresses.
• Traffic leaving our servers, apart from calls to AWS's own services, passes through Cloudflare Gateway, which blocks known malware, phishing and command-and-control destinations.
• Pages and automations run as programs in isolated sandboxes (Cloudflare Workers) with no network access of their own. A program reaches records only by asking Pyron, which checks permissions as it does for every other request.
• API keys are stored only as hashes. A webhook with a signing secret is checked by its signature and its time, so an old one cannot be replayed.
• To report a vulnerability, write to security@pyron.com.au. Our security.txt is at pyron.com.au/.well-known/security.txt.

Monitoring and incidents

• Logs, metrics and traces go to Grafana Cloud in Australia. Before they leave our servers, credentials, cookies, request bodies and what is said to and by the AI are removed from them. Error reports go to Sentry in the European Union, and can contain fragments of the data being processed.
• Activity on our AWS accounts is recorded by AWS CloudTrail into a separate archive account, where it is locked for 12 months.
• Security events, such as a sign-in as an account's root user, use of emergency access, or a change to organisation policy or to that logging, page our on-call engineer.
• We notify an affected customer of a suspected or confirmed security incident affecting their data without undue delay and no later than 48 hours. Where personal information is involved we assess whether an eligible data breach has occurred under Part IIIC of the Privacy Act 1988 (Cth), within 30 days and sooner where we can, and notify the Office of the Australian Information Commissioner and affected individuals where the test is met.
• We keep application logs for up to 30 days, security logs for 12 months, error reports for up to 90 days and the audit trail for 24 months.

Backups and recovery

• The database is backed up continuously and can be restored to any moment in the last 35 days. Its backups are encrypted and held in Melbourne, and copied to Sydney, where the copy is also kept for 35 days.
• A restore recovers the database to within about five minutes of a failure, because its transaction logs are backed up that often. A quarterly restore test measures how long a full restore takes: the first, on 26 October 2026, restored the database and verified it in 11 minutes.
• The database is protected from deletion, and a final snapshot is taken if it is ever deleted.
• When a stored file is replaced or deleted, its earlier version is kept for 30 days.

How we build Pyron

• Every change reaches production as a pull request, which merges only when the required checks pass, among them the test suites, a production build, an API contract check and a dependency scan.
• Static analysis runs on every change, including security rules, secret detection and checks of our infrastructure code. GitHub's secret scanning, with push protection, is on.
• Dependencies are scanned for known vulnerabilities on every change and every day. A change that adds a high or critical advisory is blocked.
• Container images are built from base images pinned to an exact digest, and scanned when they are pushed.

Pyron AI

• Pyron AI uses Anthropic's Claude models on Amazon Bedrock, through Bedrock's Australian cross-region profile, which keeps each request within the Sydney and Melbourne regions.
• Customer data is not used to train foundation models and is not shared with the model provider for training.
• The AI works with the permissions of the person asking: it sees only what they can see, and its activity is recorded on the audit trail like any other actor's.
• Anything Pyron AI would delete, publish, send or use to grant access waits for the approval of the person it is acting for, with a preview of what it will do. Other changes it makes on that person's behalf are recorded on the audit trail as made by Pyron AI.
• An automation that uses AI runs as an account an admin chose, and does only what its approved version declares.
• When the assistant or an automation searches the web, the search runs on Amazon Bedrock AgentCore, through our gateway in Sydney. AWS states that such a query is served within AWS and is not sent to a third-party search engine.
• Admins set monthly AI budgets for the workspace, each role, each person and each automation.

What we don't have yet

• A certification. Pyron holds no ISO 27001 certificate, no SOC 2 report and no other security certification. We are mapping our controls to the frameworks Australian buyers ask about.
• An independent penetration test. None has been done yet.
• A standby database. The production database runs in a single availability zone, and we make no uptime commitment and offer no service level agreement.
• A Data Processing Agreement. A standard one is not yet written. Until it is, the Privacy Statement sets out how customer data is handled, kept, returned and deleted.