MRTY's sovereign AI suite: what NZ firms should ask first

What MRTY launched

Auckland company MRTY has launched a "Sovereign Intelligence" platform for New Zealand organisations with between 5 and 1,000 staff, IT Brief reported on 13 November 2026. Founder Tamawera Owens unveiled the platform at a private event at Gibbs Farm, north of Auckland. The suite bundles several tools:

• iScrape, for searching business records
• Email Link, which turns incoming mail into tasks
• LENZ, for communications
• FLOW, for workflow
• LIRP, for customer relationship management
• MRTY Si, an intelligence layer that answers staff questions from internal information and drafts emails and tasks for a person to approve

Security Brief's report says customers can run the platform on their own computers, on dedicated MRTY hardware, or in a New Zealand-owned local cloud. MRTY is aiming at professional services, engineering, construction, legal, financial services, agribusiness and Māori organisations.

The first product on the market is MRTY Vault, a password manager that keeps credentials on the user's own device. MRTY says Vault uses AES-256 encryption and three authentication factors: a master password, a key held on the device and passkey biometrics. The company also says it can't see inside a customer's vault.

What MRTY hasn't published

The launch coverage doesn't name the AI models behind MRTY Si, the operator of the New Zealand-owned cloud, pricing, or release dates for products beyond Vault. For a buyer, those gaps carry more weight than the feature list. An assistant that answers questions from internal records needs a language model running somewhere, and the sovereignty claim depends on where that model runs and who operates it.

If MRTY Si runs an open-weight model on hardware in the customer's office or in a New Zealand data centre, prompts and documents can stay onshore the whole way through. If the assistant calls an overseas model API for some tasks, any documents included in those prompts leave the country, even when the database stays in Auckland. A vendor selling on sovereignty should answer the model question in writing, and buyers should ask for that answer before agreeing to a pilot.

Why the hosting detail matters

Amazon's Auckland region is a useful benchmark for how precise a hosting answer can be. According to AWS's March 2026 post on Bedrock in Asia Pacific (New Zealand), Auckland requests sent through the Australian geographic profile can be processed in Auckland, Sydney or Melbourne. Data at rest stays in the Auckland region, and invocation logs are written there too. A global hyperscaler has documented where prompts are processed down to the city, so a local platform whose main selling point is sovereignty should be able to match that.

Under the Privacy Act, control over the data counts as much as where it's stored. The Office of the Privacy Commissioner's guidance on disclosing information outside New Zealand explains that when a provider holds personal information only as an agent, for safe custody or processing, the law treats the business that engaged the provider as the holder, and that business stays responsible. If the provider uses the information for its own purposes, both parties count as holding it.

Information privacy principle 12 sets the conditions for disclosing personal information to an overseas recipient. One example is a reasonable belief that the recipient must protect the information to a comparable standard. A wholly onshore stack leaves fewer overseas disclosures to assess. Even so, the contract with any local vendor should state that the vendor acts as the customer's agent and won't reuse customer data, for example to improve a shared model.

The consolidation trade-off

Owens built the launch around dependence on technology that can disappear, asking: "what happens when the technology you rely on is no longer available to you?" (Security Brief). The same question applies to any single supplier that would take over email handling, CRM, workflow, document search and credentials at once. Moving core tools from several overseas vendors to one local vendor replaces one concentration risk with another.

A small New Zealand supplier can offer closer support and a clearer legal jurisdiction. Buyers are better protected when the vendor documents its export formats, any source code escrow, and what happens to customer data if the company is sold or winds up.

Device-held credentials need the same testing. Own Your Online's guide to choosing a password manager says locally stored managers make an attacker's job harder. The trade-off is that staff can't reach their passwords from home or a phone, and the business relies on making regular backups. The guide also recommends checking whether a product can export passwords in bulk and how that export file is protected. All of those points apply to Vault's design.

What we'd do next

For owners and IT leads assessing MRTY or any other New Zealand-hosted AI platform:

• Ask the vendor in writing which language models power the assistant, where inference runs, and whether any request ever goes to an offshore API.
• Get the name of the cloud operator, the data centre locations, and a contract clause confirming the vendor acts as your agent and won't train on or reuse your data.
• List which current apps the suite would replace. Run a test export of each data set before cancelling any existing subscription.
• Test Vault recovery after a lost laptop and after a staff member leaves, and confirm bulk export works.
• Complete a privacy impact assessment for the AI layer, because MRTY Si reads email and internal records.
• Price the alternative of running an open-weight model on your own hardware, which we cover on our local AI server page. Firms writing a wider AI policy can find help through our AI consultancy service.