Every Finding Now Names Who Recorded It
August 29, 2026 · InfraScout Team
An insight is a finding. A memory entry is something the AI decided your organization should remember. Both are durable records that outlive the conversation that produced them, and neither carried a trail to its author.
You could see who a finding was assigned to. You could not see who found it.
Recorded by, last edited by
Both are now recorded on every insight and every memory entry, and the insights list can be filtered by creator.
Where the write came from an agentic workflow rather than someone typing in chat, the record names the responsible person and the workflow. That is what makes a scheduled assessment's output attributable: a finding recorded by a workflow overnight and assigned to nobody is exactly the row that needs picking up in the morning, and now it is a row you can find.
Assigned to and recorded by are different questions and both are worth filtering on. Assignment is who owns fixing it; the creator is who found it.
Two cases read differently on purpose:
- The background memory rollup attributes to the system rather than to whoever happened to chat last. Rollup is a scheduled pass over idle conversations, and naming a user would credit them with a write they did not make.
- Records that predate this show no author. We could have inferred a plausible one from timestamps and chose not to, because a provenance trail that is sometimes a guess is worse than one with gaps you can see.
A write with no identifiable author is refused rather than saved unattributed. That is a deliberate trade: a store whose entries cannot be traced is worse than a write that fails visibly.
And which exchange it came from
Recording who turned out to be half the answer. The records also now carry where — which conversation or client session the write happened in — and an agentless cloud query records which tenant connection it resolved.
That last one matters more than it sounds if you assess more than one tenant. Most cloud tool calls omit the connection and take your default identity connection, so the most common case was precisely the one that recorded nothing about which customer tenant had been queried. Answering "which tenant produced this finding?" meant matching on a user and a timestamp. It is now a lookup.
This is write-time data by nature: a record created without it can never have it added afterwards, which is why it was worth doing as its own change rather than deferring.
What this does not change
Nothing about visibility. Nobody can see a finding they could not see before, and when this post was written no access decision consulted any of this.
Update, October 19, 2026
The recorded author now also decides who can change a finding through the AI: you can change the findings you recorded, and operators can change any. See Reading a Secret Is an Operator Action.
Creator names and email addresses are visible to whoever can already see the finding, the same as the assignee has always been.
The AI does not receive provenance in its own tool results. It is audit data the model cannot act on, and sending it cost roughly 180 tokens per finding. The portal carries it; the model does not.
Questions or feedback? Reach us at info@infrascout.cloud.