FILE · LLAMUS.SECURITY.PRIVACY VERIFIED AGAINST THE CODEBASE ON 2026-08-15
← Llamus

Security & privacy

What Llamus does with your clients' data, what it does not do, and how each claim is enforced.

You are handing us your clients' passports, financial records and health declarations. Most of the controls below are not policy — they are assertions in our test suite, and a change that broke one would fail the build rather than reach your clients. Each says which it is.

Everything we cannot evidence is in what we do not have, further down, rather than left out. That section is the reason to believe the rest of the page.

1,154 Automated tests
11 Controls, each enforced
8 Gaps stated openly

What is in place

These are assertions that run on every change, not a policy document. Project rules require new case-handling logic to ship with tests for the happy path, validation, error handling and authorisation.

Applicant answers are encrypted at rest

Every answer given in the visa wizard (application_data.data_json), the record of agent and applicant edits (field_modifications) and every value read off a passport by OCR (extracted_fields.field_value) are stored as AES-256-CBC ciphertext. The database holds opaque bytes; the values are decrypted only in the application, per request. A dump of the database on its own does not reveal a single passport number.

Enforced by an automated test

Audit logs record what changed, never the value

Audit entries store the field path that changed (for example "personal_info.passport_number") and never the value on either side of the change. Redaction happens before storage, so the log is useful for years without ever becoming a second, unencrypted copy of the applicant's data.

Enforced by an automated test

The audit log is append-only

An audit entry can be written but never modified or deleted — the model rejects both operations, so the rule holds for the admin panel, a console session and any future code path alike. Administrators can read the log; nobody can rewrite it.

Enforced by an automated test

One practice cannot see another practice's cases

Every case, payment, document, key date, template and generated document is scoped to the practice that owns it, enforced in the query layer rather than in the interface. Cross-practice isolation is not assumed — it is asserted explicitly by dedicated tests in each feature that could leak.

Enforced by an automated test

Multi-factor authentication for agent accounts

Registered migration agents and their team members sign in with a second factor — an authenticator app (with recovery codes) or a one-time code by email. It is required, not optional: a new account has a seven-day grace period to set it up, after which the panel is inaccessible until they do.

Enforced by an automated test

Role-based access within a practice

Team members hold one of three roles. Read can view the practice's cases; Write can view and create; Admin can also manage members. Only the practice owner can invite. Roles are scoped per team, so a person who belongs to two practices carries different permissions in each.

Enforced by an automated test

Signatures and consent are recorded with evidence

When an applicant signs a document in the portal, the signed copy is frozen at the moment it was issued and never re-rendered, and a consent record is written with the time, IP address and browser user agent. Agents separately acknowledge the data-handling terms against the same kind of record.

Enforced by an automated test

Security behaviour is enforced by the test suite

The controls above are not a description of intent; they are assertions that run on every change. The suite is 1154 automated tests, and project policy requires new or modified case-handling logic to ship with tests covering the happy path, validation, error handling and authorisation.

Enforced by an automated test

Traffic is encrypted in transit

The application forces HTTPS URLs in production, and every external service it talks to — payments, storage, email, AI — is reached over TLS.

Configuration

Encryption keys can be rotated without downtime

Superseded encryption keys are retained as decryption fallbacks (APP_PREVIOUS_KEYS), so the application key can be rotated while existing encrypted data stays readable. The procedure is written down and kept with the code.

Configuration

Uploaded documents are access-controlled

Documents are held in private object storage and are never served from a public URL. A download is streamed through the application only after it has checked that the requester is the applicant, the agent handling that case, or an administrator.

Configuration

Where AI is used

Three paths, and nothing else. Each is described from the call site rather than from the feature blurb, including the one that sends more than you might assume.

Reading a passport photo

SendsThe passport image or PDF the applicant uploaded.

Returns name, passport number, nationality and expiry date to save the applicant typing them. Every field can be corrected by hand, and the applicant can type them instead of photographing the passport at all.

Translating case notes

SendsThe text of the note or reply being translated, and earlier messages in that thread for context.

Used so an agent and applicant can write to each other in English, Spanish or Portuguese. Only notes shared between the two parties are translated.

Support ticket handling

SendsThe ticket subject and messages, plus account context: the person's name, email, account status, their payments and their applications.

Used to categorise a ticket, summarise it and draft a reply. A drafted reply is never shown to the person who wrote in until a human has approved it.

Provider: Anthropic (Claude).
Never sent: your clients' wizard answers, supporting documents other than the passport image, and Form 80 exports — the export is a deterministic field mapping, and a standing test asserts no AI call site can appear in it.

Sub-processors

Every third party that processes data on our behalf, including one integration that exists in the codebase but is not currently in use.

ServicePurposeData it receives
Stripe Card payment for the case fee Payer name, email and billing details, and the amount. Card numbers are entered directly with Stripe and never reach Llamus. Receives no visa answers and no uploaded documents.
Amazon Web Services (S3) Storage of uploaded documents The documents an applicant uploads — passport pages, bank statements, employment evidence, itineraries, invitation letters — and generated PDFs.
Anthropic (Claude) Passport reading, translation of case notes, and support-ticket assistance See the AI section below for exactly what is sent on each path.
Resend Delivery of transactional email Recipient name and email address, and the contents of the message sent.
Laravel Cloud Application hosting and the database All application data, in encrypted form where stated above.
Google Optional "sign in with Google" The name, email address and profile picture of a person who chooses this sign-in method. Only used if they choose it.
Amazon Web Services (Textract) An alternative passport-reading path A passport image, if the path were enabled. Configured but not currently in use — passport reading runs through Claude. Listed because the integration exists in the codebase.
Office of the MARA (register lookup) Verifying an agent's MARN when they register The agent's own MARN, checked against the public register. No applicant data is sent.

What we do not have

Published here rather than omitted. If you find a gap we did not disclose, you have no reason to trust anything else on this page.

No ISO 27001 or SOC 2 certification Not in place

Llamus holds no independent security certification. The controls on this page are real and tested, but they have not been audited by a certification body.

No published penetration test Not in place

No third-party penetration test has been commissioned or published.

No contractual data-residency guarantee Not in place

Documents are stored in the object-storage region configured for the deployment, and the database is hosted by our platform provider. Llamus does not currently offer a customer-selectable region or a contractual commitment that data stays in a named country.

Nothing is deleted automatically In progress

Each practice sets a retention period, and closed cases past it are listed for the practice owner to decide about. That decision is always a person's: there is no scheduled job that expires or deletes old cases, by design. Llamus does not publish a retention period of its own — the obligation is the agent's, and the default we ship is a starting point rather than legal advice.

Multi-factor authentication is agent-side only Not in place

Agents and their team members must use a second factor. Applicant portal accounts currently sign in with a password, a magic link or Google, without a second factor.

Backups are the platform's, and restores are not drill-tested Not in place

Database backups are provided by our hosting platform under its own schedule. Llamus does not operate an independent backup, and has not run and documented a restore drill.

Document encryption at rest depends on bucket configuration In progress

Uploaded files inherit the object store's default encryption. Unlike the wizard answers, the application does not itself encrypt document contents before storing them.

No per-practice AI opt-out yet In progress

The AI-assisted features described below cannot currently be switched off individually by a practice. Building that, along with a versioned AI policy each practice accepts, is in progress.

For your clients

If anything on this page is inaccurate, it is a bug and we want to hear about it. The claims are checked against the codebase itself, and the date at the top is when that was last done.