Skip to main content

Security

Security

Version 2.0, Effective 8 August 2026

Alter Meridian Pty Ltd T/A True Alter (ACN 696 662 049, ABN 54 696 662 049)

Every breached company had a security page, so this one names what is built, what it is measured against, and where it is weak. The strongest defence here is that we hold less of you than you would expect, and what we hold goes stale fast. Everything below is the detail, weak spots included.

What this page is

Alter Meridian Pty Ltd T/A True Alter (ACN 696 662 049, ABN 54 696 662 049) ("ALTER", "we", "us", "our") operates identity infrastructure. This page states the technical and organisational controls that protect an identity record, the frameworks those controls are mapped against, and the limits of what we claim. Where this page describes a protection, it describes a control that is built and running, not an intention. Where a control is partial or absent, we say so on this page rather than leave the reader to infer it. The Privacy Policy governs what we process and why; this page governs how it is defended.
  • Legal entityAlter Meridian Pty Ltd T/A True Alter (ACN 696 662 049, ABN 54 696 662 049)
  • Security contactsecurity@truealter.com
  • Vulnerability disclosuredisclose@truealter.com
  • Privacy contactprivacy@truealter.com
  • Primary hosting regionSydney, Australia
Two commitments frame everything below. The first is that security is measured as the worst reasonable case, not the average case. The second is that we would rather hold less of you than defend more of you, so the strongest control on this page is the one that means there is less to steal in the first place.

Account and session protection

An identity record is only as strong as the credential that opens it. We treat account binding as the primary control, not as a preliminary to the real ones.
  • Password hashingArgon2id, a memory-hard function resistant to GPU and timing attack. We do not use bcrypt or scrypt. A password is never stored, logged, or recoverable.
  • PasskeysWebAuthn passkeys are available and are the recommended factor for binding an account. A passkey cannot be phished, replayed, or read out of a database, because the secret never leaves your device.
  • Multi-factor authenticationTime-based one-time codes and WebAuthn are both supported, and multi-factor is enforced on every administrative account.
  • Access tokensShort-lived access tokens are asymmetrically signed (RS256). Refresh material is held in HttpOnly cookies, so no client-side script can read it. Token rotation invalidates the prior credential.
  • Session isolationA command-line session, a paired agent session and a browser session are separate credentials with separate scopes. Signing in through an AI client never hands that client your record; it acts with your credential, inside your consent, and its reads are logged like anyone else’s.
  • Rate limiting and abuse controlsApplied at the query, session and pairing layers to deter scraping, credential stuffing and automated harvesting.
We will never ask you to mint, paste, or email a credential to resolve a problem. If any surface ever instructs you to do that, treat it as fraudulent and report it to security@truealter.com.

Encryption and store separation

Data is encrypted at every layer where encryption is meaningful, and separated so that one compromise is not total.
  • In transitHTTPS with strict transport security applied and preloaded. Internal service-to-service connections are encrypted in transit.
  • At restSensitive fields are encrypted at the application layer with authenticated encryption (AES-256-GCM), with key derivation from a managed root. Database volumes are additionally encrypted at the infrastructure layer.
  • Store separationIdentity data, operational data and audit records live in separately credentialed stores with independent backup and access policies. Cross-store joins are disallowed at the application layer. Compromise of one store does not yield the others.
  • IP addressesIrreversibly pseudonymised before storage. The raw address is never written to our databases.
  • Personal-identifier filteringPersonal identifiers are filtered from content before it is routed to any external recipient, including error monitoring, which we operate on our own infrastructure in Sydney.
  • Key managementSigning and encryption keys are rotated on a documented schedule and on any suspicion of exposure. Every rotation is centrally recorded, and a rotation propagates to every consumer of that key in the same operation.
Raw observations expire on a short window and derived attributes are destroyed at the end of the account-deletion grace period. Encryption defends what exists; retention discipline is what stops it existing.

The cryptographic floor under an identity

ALTER is identity infrastructure, so the integrity of a claim about who someone is has to rest on something better than our own good behaviour. The mechanisms below are published as Internet-Drafts and are open to inspection and attack by anyone.
  • Handles resolve through DNSA ~handle resolves through the public DNS, the same infrastructure that already carries the trust bootstrap for email. Resolution is verifiable by any party without asking us, and without a registry we control.
  • Signatures, not assertionsA sovereign handle holds an Ed25519 keypair. What a reader verifies is a signature, not our word for it. We cannot forge a signed statement on your behalf, because we do not hold the key that makes one.
  • Append-only transparency logEnvelope lifecycle events (mint, caveat, revocation, key rotation) are anchored in an append-only transparency log that emits a signed tree head. The log is cross-anchored to multiple independent surfaces, so substituting a record silently would require compromising all of them at once. This is the same accountability pattern that certificate transparency provides for TLS.
  • Tiered identity classesSovereign, bot and instrument are enforced classes, not labels. A bot acts under bounded, traceable delegation from a sovereign. An instrument carries provenance and no cryptographic agency at all. An action can always be attributed to the human who authorised it.
  • Tamper-evident audit chainThe audit log is a hash chain. Modifying any prior record invalidates every record after it, and the break is detected on read rather than at the next audit.
  • Open specificationThe discovery, attribution and handle-resolution mechanisms are published Internet-Drafts. A closed identity protocol asks for trust; an open one earns it by surviving review.
Verifiability is the point. A reader who does not trust ALTER can still verify an ALTER-anchored claim, which is the property that makes this infrastructure rather than a service.

Our own management system

ALTER runs its internal substrate under its own management system, shaped on the Annex SL chassis that ISO management-system standards share. We built it because the standard shape assumes an organisation with a workforce, an estate and a change-advisory board, and mapping our substrate onto that shape without adaptation would have degraded the controls rather than improved them.
  • A management system, not a policy binderIt carries the full clause body: context, leadership, planning, support, operation, performance evaluation and improvement. It has a control catalogue, a disposition per control, a risk-source taxonomy, and a Statement of Applicability generated from live state rather than hand-maintained.
  • Documents and records never collapseA document is current, mutable and approvable. A record is immutable evidence of what occurred. Treating a record as a document loses history silently; treating a document as a record freezes a stale answer and presents it as current. The two are held apart by design.
  • Observe rather than declareWhere observation is sufficient, the substrate observes and appends. It declares a value and fails closed only where the value is constitutive or enforcing. This keeps status claims honest, because a claim about our own state is read from the substrate that would have to be lying, not from a document that could simply be out of date.
  • Retention is reserved before the reader is builtNothing that reads history is scoped until the retention substrate under it is reserved. Unrecorded history cannot be recovered later, whereas an unbuilt reader over reserved history is only deferred work. This ordering is a rule, not a preference.
  • Every defect is captured before it is fixedAn acknowledged defect is written to the lessons corpus first and remediated second, with prevention encoded at the lowest mechanical level that will hold it. A repeated defect is treated as a failure of the system, not as bad luck.
  • Review is triggered by change, not by calendarAn independent re-verification runs when content changes, and the author of a fix is never the party who verifies it. A calendar cadence re-reads unchanged, already-cleared material and buries what matters.
This management system is our own. It is not certified, it is not a recognised standard, and we do not present it as one. We describe it here because it is the reason the controls on this page can be verified against running substrate instead of asserted from a document.

Frameworks our controls are mapped against

Our controls are mapped, control by control, against the recognised frameworks below. The mapping is maintained against live system state, and each row cites the mechanism that satisfies it, or records honestly that nothing does.
  • SOC 2 (AICPA Trust Services Criteria)All thirty-three Common Criteria, CC1.1 through CC9.2, mapped control by control.
  • ISO/IEC 27001:2022 and 27002:2022Annex A organisational, people, physical and technological controls mapped against implemented mechanisms.
  • ISO/IEC 42001:2023The AI management-system standard, mapped for the AI-specific obligations that a general information-security framework does not reach.
  • NIST Cybersecurity Framework 2.0All one hundred and six subcategories across Govern, Identify, Protect, Detect, Respond and Recover.
  • ASD Information Security Manual and the Essential EightMapped against the Australian Signals Directorate manual and the Essential Eight mitigation strategies, including a self-assessment of maturity against each strategy.
  • CIS Controls v8Mapped across implementation groups.
  • EU AI Act (Regulation (EU) 2024/1689)Assessed article by article, including the Article 5 prohibitions and the Article 9 risk-management obligations.
  • Australian Privacy Principles, GDPR and UK GDPRRecords of processing, data-protection impact assessments and cross-border transfer assessments are maintained.

What we do not claim

ALTER holds no SOC 2 attestation report and no ISO certification. No independent auditor has examined these controls, and nothing on this page should be read as saying otherwise. What exists is a maintained, evidenced control mapping with its gaps recorded rather than smoothed over, and gaps do exist: we are a two-principal company with no board, so criteria that presuppose independent governance oversight are not met and are recorded as not met. An accurate map with named gaps is worth more to you than a badge, and we will publish the attestation the day we hold one, not before. A summary of the mapping is available to prospective organisational customers under confidentiality by writing to security@truealter.com.

Fairness and adverse-impact monitoring

Where an identity system is consulted about a person, the risk is not only that it is breached. The risk is that it is wrong in a patterned way. We monitor for that as a security control, because for the person on the receiving end the harm is the same.
  • The four-fifths ruleWe monitor for adverse impact across protected attributes using the four-fifths rule, the selection-rate threshold from the United States Uniform Guidelines on Employee Selection Procedures. Where a group’s rate falls below four-fifths of the highest group’s rate, that is a finding, and it is treated as one.
  • Intersectional analysisMonitoring runs across attribute combinations, not one attribute at a time. Systems that appear fair on each attribute in isolation frequently are not fair at the intersections.
  • Automated alerting and blockingDrift raises an alert automatically, and the affected result does not proceed. The check is in the path, not in a report reviewed afterwards.
  • A dedicated audit databaseBias auditing runs against a separately credentialed audit store, so the demographic data required to prove fairness is not commingled with the identity data it is auditing.
  • Bias validation is a hard gate in our build pipelineBias validation runs in continuous integration and blocks a release rather than warning about one.
  • Audits are available to organisationsAn organisation relying on ALTER can review our bias auditing for its own compliance obligations.
Numeric scores are never exposed to a querying party. Only qualitative tier labels leave the system, which removes the false precision that invites a reader to treat an indication as a decision.

Limits on automated decisions

The strongest protection against an automated system harming someone is a hard limit on what the system is permitted to decide alone.
  • No solely automated decisions with legal or similar effectNo output of ALTER may be the sole basis for a decision that materially affects you. This is a contractual requirement on every consuming query, not a recommendation to the querying party.
  • Human review on requestAny automated output can be sent for human review, with a documented outcome, by writing to privacy@truealter.com.
  • Prohibited-context gateArticle 5(1)(f) of the EU AI Act forbids inferring emotions in workplace and education contexts. We honour that prohibition globally, not only for EU users, and it cannot be lifted by user consent, organisational consent, or contract. Every affect and affect-proximate dimension is dropped in code before any comparison is computed on those paths, so the gate is structural rather than a policy promise.
  • Integrity signals never cause silent exclusionAn anomaly in connection or session flow affects confidence, never access. You are never quietly excluded on the basis of an integrity signal.
  • Explanation of the logicYou can request an explanation of the logic, the significance and the envisaged consequences of any automated processing that affects you. We answer in plain language, not a model card.
Anti-distillation safeguards run against the identity surface. We watch request patterns for the shapes that indicate model extraction or bulk harvesting rather than legitimate use, and anomalous access triggers rate limiting and investigation.

Build and supply-chain integrity

Most breaches of a small platform arrive through its dependencies or its deployment path rather than through its front door. Those two paths are gated.
  • Hash-pinned dependenciesPython dependencies install from a hash-verified lock file, so a compromised package cannot be substituted for the version we reviewed. Node dependencies are locked.
  • Continuous vulnerability scanningDependency and container scanning run on every pull request and on a recurring schedule, and a critical finding fails the build rather than filing a note.
  • Protected trunkForce-push and branch deletion are blocked on the trunk. A set of required status checks must pass before anything merges, including disclosure-boundary checks that stop internal material reaching a public artefact.
  • Attributed commitsEvery AI-assisted commit carries structured attribution trailers identifying the human who acted, what executed, and what drafted. The attribution is machine-verified in continuous integration. An unattributed change does not merge.
  • Pre-publish gatesAnything bound for a public registry passes an independent pre-publish review of the built artefact before it ships, not of the source it was built from.
  • Least privilege in productionProduction services run as containers from pinned images with no arbitrary execution path, and administrative access is separately credentialed and multi-factor gated.
Our endpoint posture is weaker than our server posture. We are a small distributed team on personally-owned devices, so we do not operate managed endpoints or application allowlisting on workstations, and we record that as an accepted risk rather than describe it as a control we have.

Data residency and sovereignty

Where data sits determines which courts, which regulators and which compulsion regimes can reach it. We state that plainly rather than describe it as global infrastructure.
  • Primary residencyProduction databases and cache are hosted in Australian regions, in Sydney. Identity data rests in Australian jurisdiction.
  • Applicable lawThe Privacy Act 1988 (Cth) and the Australian Privacy Principles, together with GDPR, UK GDPR, the EU AI Act, and CCPA as amended by CPRA where each applies.
  • Cross-border transfersA small number of named recipients operate outside Australia. Standard Contractual Clauses, the UK International Data Transfer Agreement, and transfer impact assessments are in place, and we remain accountable under APP 8.1 for what an overseas recipient does.
  • Edge servicesOur edge provider terminates TLS and provides denial-of-service and bot mitigation. Edge request logs hold an IP address for a short rolling window at the edge only. We do not persist them, and we do not use the edge for analytics or tracking.
  • Device-only processingSignals that would describe you individually from passive observation are processed by software on your own device and never leave it. They do not traverse our servers and are not available to any recipient, any organisation, or to ALTER.
The complete list of recipients, what each receives, and the transfer mechanism that covers it, is published in section 10 of the Privacy Policy.

Monitoring, logging and breach response

Detection matters more than prevention once you accept that prevention eventually fails.
  • Immutable decision and access loggingEvery scoring decision, every data-access event and every bias check is written to an immutable audit log, retained for seven years and hash-chained so that tampering is detectable.
  • Readable by youYou can read who has queried your identity record, and what you earned from it, from the command-line client. The audit trail is not only for us.
  • Destruction is logged tooEvery destruction event is written to the audit chain, so a retention schedule can be proven as well as stated.
  • Breach notificationUnder the Australian Notifiable Data Breaches scheme and GDPR Articles 33 and 34 we notify the relevant supervisory authority within seventy-two hours of becoming aware of a qualifying breach, and affected individuals without undue delay.
  • A low threshold for serious harmGiven the sensitivity of identity data we apply a deliberately low threshold for "serious harm" and for "high risk", and we hold drafted notification statements for the incident classes we consider foreseeable so that notification is fast when speed is what matters.
If you believe your identity record has been accessed without your consent, write to security@truealter.com and we will treat it as an incident from the moment we receive it, not from the moment we confirm it.

Reporting a vulnerability

We would rather hear it from you than read about it. Report to disclose@truealter.com, and include enough detail to reproduce.
  • What we commit toAcknowledgement of your report, an assessment, and a decision communicated back to you. We will tell you what we are doing about it, including if the answer is that we accept the risk.
  • Safe harbourWe will not pursue legal action against a researcher who acts in good faith, works within the scope of their own account, avoids privacy violations and service degradation, and gives us reasonable opportunity to remediate before disclosing.
  • Out of scopeSocial engineering of our people, physical attacks, denial-of-service testing, and testing against accounts you do not control.
  • CreditWe will credit you publicly if you want it and stay quiet if you do not.
Every gate encounter and every accepted report feeds back into the controls themselves. A finding that a gate should have caught is treated as a defect in the gate, not as a reason to congratulate the process.

What we do not do

Some of the strongest guarantees are things that are absent by design, and an absence is only credible if it is stated specifically.
  • We do not send your data to a model providerIdentity is inferred from what you have already shown, not produced by a language model pointed at you. Nothing is shipped to a model provider, ours or anyone else’s.
  • Your data does not train anyone’s modelThere is nothing sitting in a training set to regret later.
  • We do not use Google Analytics or any Google-operated recipientAdvertising networks are never recipients, and we do not track you across the web.
  • We do not expose numeric scoresOnly qualitative tier labels leave the system.
  • We do not sell or share personal dataAs those terms are defined under CCPA and CPRA.
  • We do not ask you to mint credentialsCredential provisioning is an administrative function. No legitimate ALTER surface will ever instruct you to create, paste, or send a token or key.

Changes to this page

Where a control on this page changes materially, we update the version line and the effective date. Where a control is weakened or withdrawn, we say which one and why, rather than quietly editing the sentence that described it.

Report a vulnerability: disclose@truealter.com