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 lists every gap we know of.

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. 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.
• 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 any workspace to help. They sign in through Techly's Google Workspace, which enforces 2-step verification, and a Support session lasts at most 8 hours 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 AWS IAM Identity Center. 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 passes through Cloudflare Gateway, which blocks known malware, phishing and command-and-control destinations. If Gateway is unavailable, traffic continues without that filter rather than stopping. That is a risk we have accepted, so that an outage at the filter does not stop customers' automations.
• 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.io. Our security.txt is at pyron.io/.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.
• 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.
• Backups in a second region, and a tested restore. Backups are held in Melbourne only, and a full restore has not yet been tested.
• Encryption inside our private network. Traffic reaches our servers through an encrypted tunnel and the database connection is encrypted, but traffic between our own services inside the cluster is not.
• A switch for Support access. Support can sign in to any workspace, and a workspace cannot yet turn that off.
• Automatic deprovisioning. There is no SCIM. When someone leaves, an admin deactivates them in Pyron.
• A second reviewer on every change. Every change goes through a pull request and its checks, but the team is small and a second engineer's approval is not yet required.