Security and trust

Security
you can check

Screenshot of Mulholland’s Vanta Trust Center showing compliance programs and security controls.

Vanta monitoring is live.

A clear view of where we stand

Before anything runs, we agree with your team on what the software can read, what it can change, and who approves it.

The trust center keeps the current documentation and the detail behind each program below.

Visit the trust center

SOC 2 Type 2

Audit underway

An independent audit is underway. Until it’s complete, we say exactly that and nothing more. The trust center always shows the current status.

ISO 42001

In progress

ISO 42001 is the management system standard for AI. Our work toward it is in progress, and the trust center shows where it stands.

HIPAA

Under a business associate agreement

Healthcare clients that handle protected health information work with us under a Business Associate Agreement. You’ll find it with the other agreements at Legal.

The database keeps customers apart.

One table, one tenant per sessionSessionsRow-level securityOne table, every customertenant_idrecordTenant AA dental practiceApatient 1042Apatient 1043Aclaim 4471Tenant BA retailerBorder 5531Breturn 0212Tenant CAn accounting firmCpay run 0917Cpay line 212Cpay run 0918A session reads and writes only the customer it is bound to One tenant per sessionRLSTenant AApatient 1042Aclaim 4471Tenant BBorder 5531Breturn 0212Tenant CCpay run 0917Cpay line 212Enforced by the database

01

Row-level security, by tenant.

Every record carries a tenant identifier that can’t change. Forced row-level security in the database lets each customer’s sessions read and write only the rows that carry that customer’s tenant identifier. Named Mulholland engineers can reach data across customers for support, operations, and security.

02

Least privilege, by service.

Each service reaches the database under its own identity and the narrowest role that does its job. Administrative access needs multi-factor authentication.

03

Encrypted, at rest and in transit.

Customer data sits encrypted where it’s stored, and it travels over TLS 1.2 or higher.

04

Training, by agreement.

Under version 1.4 or later of our Master Services Agreement, we may de-identify customer data that we first receive or generate on or after the effective date of the order form or amendment by which the customer first agrees to one of those versions, and use the resulting de-identified data to train our own models, which we may sell or license. Those versions bar us from using identifiable customer data to train any model used for another customer, and from letting outside model providers, such as OpenAI and Google, train their own models on customer data or on de-identified data made from it. Customers on earlier versions keep the terms they signed.

A receipt,
or it didn’t happen.

Every write Marzy makes carries what it came from, who approved it, and when. The receipt sits next to the record it changed, not in a log line in a separate system. It only ever appends, and it outlives the person who left.

Six months later, the question is never about the software. It’s about one claim, and whether you can show who approved it.

  • The source document or screen, stored exactly as Marzy saw it
  • The field by field extraction, and what it changed
  • The person who approved it, or the standing rule that let it pass
  • The model call behind it, its version and what it cost
  • A timestamp on a record that only ever appends

Receipt Claim 4471, refiled

Source
Payer portal, eligibility screen captured 09:14
Extracted
Member ID, plan status and annual maximum. Three fields changed.
Corrected
Member ID had two digits transposed.
Approved by
The front desk lead, under the practice’s standing rule for refiles
Model call
One call, its version and cost on the record
Filed
09:14:38, beside the claim. Append only.

Every browser session,
on tape.

Some systems never shipped an API. Marzy works these the way a person does, in an isolated browser session, with the whole session recorded.

When something goes wrong, you don’t read a stack trace. You scrub the recording, find the mistyped field, and correct the rule that produced it.

The session opens.

Marzy stores credentials encrypted for your organization and retrieves them for the authorized session.

The work happens.

Marzy records every page, click, and keystroke, as video and as structured events, not as a log line.

The fields land.

Values land on the ontology object itself, not in a spreadsheet somebody has to reconcile on Friday.

The run closes.

The recording, the extraction, and the approval file together, as one receipt beside the record.

Session recording eligibility / nightly, 04:12

00:03
Signed in to the payer portal
01:27
Opened the patient, read coverage and maximums
02:44
Transposed digit caught, corrected against the chart
03:58
Fields written to the record, run closed

Working means a run is open. Marzy is mid-session and has filed nothing yet, and it writes nothing until the run closes.

Your requirements

We fit each deployment to the way your operation runs.

We agree the data connections, access permissions, and human review boundaries with your team. The engagement includes a review of the documentation and contractual commitments.

Talk through your setup

In writing, at its own address.

Agreements

Security matters

You’ll find the agreements at Legal, and every version keeps its own address. For security matters, write to security@mulholland.ai.

Read the agreements Read the policies Open the trust center