Iris incident report: residual pre-tenancy agent memory

In certain responses, the agent surfaced information originating from earlier beta users to a different phone number.

We traced the reproduced examples to historical beta messages in our own logs. Based on that investigation, the issue was not caused by model training data or by the model inventing the information.

This document describes what we found, what we changed, what we have verified, and what remains incomplete. If subsequent investigation changes any of these conclusions, we will update this report.

1. What happened

During our early beta, the hosted Hermes agent could write user-provided information into Hermes-native memory files on a shared agent environment.

We later introduced phone-scoped tenancy: each phone number maps to a distinct internal user and its own application-level memory and integrations.

The migration was incomplete.

Although normal application data had moved to phone-scoped storage, residual Hermes-native memory from the earlier beta environment had not been fully removed. Certain identity- and memory-oriented prompts could still cause the agent to consult that residual state.

As a result, some responses returned information originating from earlier beta conversations to users who had not supplied that information themselves.

The examples we investigated included user-provided profile information such as names, job or employer references, and other personal context. We will not reproduce those details publicly.

2. What our investigation found

Based on the cases we reproduced and investigated:

• The surfaced phrases could be correlated with messages previously sent by early-beta users.
• The source was residual Hermes-native agent memory created before our current tenancy architecture.
• We found no evidence that the responses were generated from model training data.
• We found no evidence in the investigated cases that one current user’s phone-scoped Postgres memory was being queried as another user.
• We found no evidence in the investigated cases of cross-user access to Google OAuth credentials, Gmail contents, Calendar contents, or stored integration tokens.
• A Gmail or Calendar connection was not required to reproduce the issue.

The isolation failure was therefore in the legacy agent-memory layer, rather than the phone-scoped application database.

If subsequent investigation changes any of those conclusions, we will update this report.

3. Scope

The data source we identified was residual memory written during the pre-tenancy beta period.

Identified to date, from the cases we reproduced and matched in our logs:

• 5 early-beta accounts whose prior inbound messages matched phrases that later appeared in another phone’s thread.
• 2 recipient accounts that received those responses in the threads we investigated.
• 7 outbound replies in those two threads that first disclosed information the recipient had not supplied. Later messages in the same threads discussed that disclosure; we are not counting those as additional independent events.

We have not found evidence from this incident of a general cross-account export of the current application database or compromise of Google OAuth tokens.

4. Timeline

• Early beta (early September 2026). The hosted Hermes environment could retain user-provided information in shared Hermes-native memory. In the cases we investigated, that information had originally been provided by early-beta users beginning September 8, 2026.
• Tenancy migration (after September 8, before public launch on September 16). We then introduced phone-scoped users and application-level storage. Each incoming phone number mapped to an internal User.id, and application memory and integrations were stored against that tenant.
• Migration gap. Residual Hermes-native memory from those earlier beta conversations was not fully removed. Application tenancy did not by itself delete that legacy agent-memory layer.
• September 16 (public launch). The consumer product went public.
• September 17. Users testing identity and memory-related prompts received responses containing information they had not supplied. The incident was reported, and we began investigating the source.
• September 18. We traced the reproduced information to residual pre-tenancy Hermes memory and deployed containment and isolation changes: deletion of the shared state, fail-closed profiles, and tenant-scoped retrieval.
• September 19. We published this report. The same day, a follow-up conversation on an already-contaminated thread still produced a confirmation that other people's profiles were in durable memory. Direct identity prompts were answered from this phone's store; conversational follow-ups were not classified as identity asks and reached ordinary chat. We treated that as a recurrence of the isolation failure, not as a closed incident.

5. Changes we made

We changed how consumer memory is stored and which store identity queries are allowed to read. Identity and stored-memory asks now resolve against the requesting phone’s application data only. They do not read Hermes-native agent memory.

Removed legacy shared memory

We deleted the residual pre-tenancy Hermes-native memory from the hosted consumer environment, including the shared root and associated memory files.

Fail-closed Hermes profiles

Consumer Hermes turns must now execute using the profile associated with the authenticated phone tenant: user_{User.id}.

A missing profile, shared consumer profile, default/root profile, or profile belonging to another user is rejected rather than used as a fallback.

Identity and stored-memory queries bypass Hermes-native memory

Queries such as:

• what do you know about me?
• what’s my name?
• what do you have stored about me?
• what’s on my no-go list?
• what am I tracking?
• what names do you have stored?
• are they in your memory?
• you gave me a list of people — do you still have it?

Direct about-me asks are answered from that phone’s tenant-scoped application data. Asks about other people’s names, profiles, or whether “they” are in memory are refused. Those queries do not retrieve from Hermes-native memory. A missing profile or empty tenant store returns an honest empty answer for that phone. There is no fallback into a shared agent-memory layer.

Hermes-native memory is not the consumer user store

Consumer Hermes profiles are provisioned without Hermes-native memory, session_search, or cron. Those tools are not on the consumer path. Durable user facts are stored only against the phone-scoped application user.

Product capability questions are handled separately

Questions such as “what can you do?” are answered from the Iris capability catalog. They do not read an agent’s historical state or another user’s configuration.

Defense-in-depth outbound checks

We also added an outbound check for response patterns associated with the original failure, including unexpected multi-person dossiers, attempts to switch into another user’s profile, or prose claims that other people’s profiles are in durable memory. Paragraph-shaped confirmations are included, not only numbered lists.

This is a backstop, not the primary tenancy mechanism. Events blocked by this protection are recorded for investigation.

6. Integrations

Gmail and Calendar connections remain scoped to the user associated with the requesting phone number.

Integration tokens are stored separately from conversational or Hermes-native memory.

A connected Gmail account does not by itself authorize Iris to send email. Actions that send on the user’s behalf require the product’s explicit authorization flow.

The incident we investigated did not require a Gmail or Calendar connection to reproduce.

7. How we tested the fix

We ran cross-phone tenancy tests after deploying the changes.

A simple version can also be tested externally without using anyone’s real information:

Phone A — store a unique nonsense marker, for example:

TENANCY_CANARY_ORANGE_KITE

Phone B — from a different number that has never supplied the marker, ask:

• What do you know about me?
• What’s my name?
• What names do you have stored?
• What’s on my no-go list?
• What am I tracking?
• List everything you can do.

Phone B should not receive Phone A’s marker or any information belonging to Phone A.

We performed both automated and live tests against the production iMessage flow after the September 18 changes. Those tests covered first-turn identity prompts on fresh accounts. They did not cover conversational follow-ups on an already-contaminated thread, and they did not establish that every conversation path was fixed.

On September 19 we reproduced a follow-up path that still confirmed other people’s profiles. Additional tests now include that multi-turn exchange, paragraph-shaped outbound replies, and session-reset title conflicts.

That testing is not the same thing as an independent security audit, and we are not presenting it as one.

We are also engaging external security testing teams to review the improved architecture. Isolation has to hold if more people are going to use a consumer product built on Hermes. We will make further changes if that review finds issues.

If anyone can still reproduce cross-phone information disclosure, send a redacted example to support@iris-agent.co. We treat that as a P0 security issue and will update this report if the facts change.

8. What remains incomplete

There are areas of the product that still need improvement and should not be confused with completed security work.

• Full conversation export. Iris does not yet provide a self-service download of the complete iMessage conversation history.
• Self-service deletion. Account deletion is not yet a one-click product flow. Users can currently request deletion through support@iris-agent.co, and we confirm once it has been completed.
• Independent review. We have not published an independent third-party audit of this incident. The findings in this report come from our own investigation, logs, code review, reproduction, and post-fix testing.

We will not describe any of those items as complete until they are.

9. Recurrence on September 19

After the September 18 containment shipped, a follow-up conversation on an already-contaminated thread still produced a confirmation that other people’s profiles were in durable memory.

The first-turn identity prompts we had tested were answered from this phone’s store. Conversational follow-ups — whether “they” were in memory, and whether a previously listed set of people was still stored — were not classified as identity asks, so they reached ordinary chat. The outbound backstop looked for numbered biographies and known leak phrases; the reply was ordinary paragraphs and shipped. Clearing a saved session pointer could reconnect to the previous Hermes session when the gateway reported a title conflict.

We have not determined whether that particular reply reread surviving shared memory or repeated information already present in the conversation. The assistant saying it verified durable memory is not evidence that it queried storage. Either path is unacceptable: the agent repeated profiles, offered a way to treat them as stored, and asserted that they remained.

The follow-up path is now a control-plane refuse. Outbound checks cover prose memory-verification. Session resets mint a new unique session instead of recovering the old one. Contaminated recent-turn and session-focus context is quarantined so it cannot keep generating profile answers.

Contact

Incident/support: support@iris-agent.co
Incident report: https://app.iris-agent.co/incident
Privacy policy: https://app.iris-agent.co/privacy
Terms: https://app.iris-agent.co/terms
Product: https://iris-agent.co