Published: 2 September 2026  ·  Last reviewed: 27 September 2026

1. Reporting a vulnerability

Email security@chameleon-ai-agent-ltd.net. Please do not post security problems in a public forum or a support ticket before we have had a chance to fix them.

Tell us:

  • what the issue is and where — the website page, or the software component / version (chameleon_accounting.py --version);
  • how to reproduce it: steps, a proof of concept, or a short script;
  • what impact you think it has.

If you need to send us something sensitive and want it encrypted, ask in a first email and we will arrange a secure channel.

2. What you can expect from us

  • an acknowledgement within 3 working days;
  • an assessment, a severity, and a target fix date, with progress updates;
  • coordinated disclosure: we aim to release a fix within 90 days and will credit you by name in the release notes if you would like that;
  • there is no paid bug bounty — we recognise reporters in the release notes.

3. Safe harbour

We will not pursue or support legal action against anyone who tests in good faith and within this policy. That means: only against your own installation and your own test data; without accessing, altering or deleting anyone else's data; without degrading the service for others; and without social engineering or physical attacks. If you come across personal data, stop and tell us.

4. Out of scope

  • Third-party services the software connects to — HMRC, GoCardless, TrueLayer, Companies House. Report those to the provider.
  • Volumetric denial-of-service testing.
  • Automated-scanner output with no demonstrated impact.
  • Missing hardening headers on the marketing site with no working exploit.

5. How the software is protected

  • Data stays on your device. The ledger, the HMRC OAuth tokens and your API credentials are stored locally and are never routed through us.
  • Signed updates. The release manifest and download archives are signed with an Ed25519 key. The software verifies the signature offline against a built-in public key and ignores anything that does not verify. You choose when to upgrade; nothing is installed automatically. The public key is at /.well-known/chameleon-accounting-release.pub.
  • Local hardening check. chameleon_accounting.py --security-check audits file permissions, token age, the TLS trust store and the OAuth configuration on the machine; --security-check --fix tightens what it can.
  • Standard TLS to online services. Connections to HMRC, banks and AI providers use the operating system's certificate store.
  • Encrypted books. The Chameleon Accounting MTD app encrypts its whole ledger and its daily backups on your device (SQLCipher v4 format, AES-256, via SQLite3 Multiple Ciphers bundled with the app). The key is random per install and kept in the device's secure store (Keychain, Android Keystore, the Linux keyring, Windows DPAPI); Settings → Backup → Show database key lets you keep a copy. Android and iCloud cloud backup are switched off for the app.
  • Linux kernels. Use your distribution's standard kernel. On a full real-time (PREEMPT_RT) 7.2 kernel we saw freezes and crashes in the kernel's real-time locking code while running Dart and Flutter software; the standard kernel was stable.
  • Encrypted phone-to-desktop links. Your phone connects to your desktop over TLS with a per-install certificate that the phone pins by fingerprint, or over Tailscale (WireGuard). Unencrypted connections on the local network are refused unless you turn them on.
  • Credentials. API keys are kept in one key file on your device that only you can read, and never in our source code. Sign-in patterns are stored only as salted, deliberately slow hashes, and repeated wrong attempts lock out.

6. AI features and your data

AI features are optional, bring-your-own-key, and send data from your device directly to the AI provider you choose (Terms & Conditions §9). We are sometimes asked why we don't instead disguise the figures mathematically before sending them — for example doubling every amount and halving the AI's answer — so nothing real ever leaves the device. We looked at this and it doesn't hold up:

  • A fixed scaling factor preserves every ratio in the data. UK VAT is 20% of net sales; double both figures and the 20% relationship still holds exactly, so the shape of the data — and often the scaling factor itself — is recoverable from the request alone. It is obfuscation, not encryption, with no real security margin.
  • It does nothing for the parts of a document that are text, not numbers — supplier names, descriptions, references — which are usually the more sensitive part.
  • It undermines the reason to use AI at all: a model's judgement about what's "a large transaction" or unusual for a business is calibrated on real-world magnitudes, so scaling either breaks that judgement or is silently reversed by the model inferring the true scale from context.
  • Computing on genuinely encrypted data without decrypting it is a real field (homomorphic encryption / secure multiparty computation) — but it does not exist today for "send encrypted figures to a commercial AI model and get a coherent answer". We won't advertise a protection we can't actually provide.

So we say plainly instead: if you use an AI feature, your data is sent to and may be retained by the provider you chose, under their policy. The only architecture that is genuinely zero-transfer is a model that runs entirely on your own device, which is on our roadmap as an alternative, not a replacement, for bring-your-own-key.

7. If we have a security incident

If we become aware of a breach affecting personal or customer data, or the security of the Making Tax Digital service or HMRC credentials, then within 72 hours of becoming aware we will:

  1. contain it — isolate the affected system, preserve evidence, revoke exposed credentials;
  2. notify HMRC by logging a ticket at developer.service.hmrc.gov.uk/devhub-support/tickets, with a named breach contact and a direct telephone number;
  3. notify the Information Commissioner's Office where the breach involves personal data and meets the risk threshold, via ico.org.uk/for-organisations/report-a-breach;
  4. notify affected customers without undue delay where the risk to them is high, explaining what happened and what to do;
  5. publish a fix and a release note.

See our Privacy Policy for how we handle personal data.

8. How we manage information security

Our security controls are aligned with the Annex A controls of ISO/IEC 27001:2022 that apply to a small software publisher: access control and authentication, protection of credentials, cryptography, secure development, vulnerability management and incident response. The policy is owned by the company director and reviewed every year and after any incident. We are not certified to ISO/IEC 27001 and do not claim to be.

8.1 TrXi-Ctrl and trixie-gateway: ISO/IEC 27001 gap review

In October 2026 we reviewed TrXi-Ctrl and trixie-gateway against ISO/IEC 27001:2022 Annex A and listed 19 gaps, from code weaknesses to the paperwork certification would need. We are working through them in priority order. This is alignment work, not certification.

Fixed (gateway v0.3.0, and v0.3.1 for the last two):

  • Web pages open in the PC's browser can no longer send requests to the gateway (cross-site and DNS-rebinding protection) (A.8.26).
  • Authentication is on by default; the "no authentication" testing switch only ever works from the PC itself (A.8.5).
  • The gateway answers only over Tailscale and from the PC itself; home-network access is an explicit setting. From the first pairing on, only listed devices get in (A.8.20, A.8.22).
  • Every paired device is listed on the admin page with a Revoke button; devices unused for 90 days must pair again; the terminal is granted per device and is off for new ones; token renewal can no longer raise a device's rights (A.5.15, A.5.18).
  • Terminal commands that delete, overwrite, copy, encrypt, format or shut down ask for confirmation first (A.8.2).
  • The activity log is owner-only, rotated and hash-chained so edits show, and records refused requests, failed pairings, revocations and permission changes (A.8.15, A.8.16).
  • Shared clipboard items expire after 24 hours unless locked; the history can be cleared (A.8.10).
  • Pairing locks for a minute after 5 wrong codes (A.8.5).
  • Dependencies are pinned to tested versions, build actions to exact commits, and update proposals arrive weekly (A.8.8, A.5.21).
  • Release checksums are signed with our Ed25519 key, published at /.well-known/trxi-release.pub (A.8.24).
  • Security regression tests run on every change (A.8.29).
  • The gateway shows which account it runs as and can run as a normal user; a small root helper does only the firewall, Wi-Fi and layer actions, for that one account, with every argument checked (A.8.2, A.8.18).
  • On home networks the apps use HTTPS and pin the gateway's own certificate, delivered in the pairing QR (A.8.24).

Planned, with what you can do meanwhile:

  • Code-signed Windows and macOS apps and a dedicated Android release key (A.8.24). Meanwhile: check the signed checksums.
  • Information security management documents (scope, risk register, Statement of Applicability, policies, asset and supplier registers) are drafted and awaiting the owner's approval.

Found something we missed? Report it as described in section 1.

9. Machine-readable contact

This policy is also advertised at /.well-known/security.txt in the format defined by RFC 9116.

Security contact: security@chameleon-ai-agent-ltd.net

Published by: CHAMELEON-AI-AGENT LTD, company no. 17147789, 3rd Floor, 86–90 Paul Street, London EC2A 4NE.

See also our Privacy Policy, Terms & Conditions and Accessibility statement.