Accountability and attribution after an agent has acted

Proposer: Oleh Vasylenko, Management Company Elixir LLC (Ukraine)

Problem

The six candidate themes raised at the 1st preparation meeting address how an agent is designed, discovered, attested, authorized and identified. All of them concern the moment before or during an action.

None addresses what a party is able to reconstruct afterwards.

This gap was named during that same meeting: the observation was made that at minimum the operating side should know what was acting and who or what was responsible. The point was raised in the context of a real incident and its post-mortem, and it did not become one of the six candidate themes (minutes of the 1st preparation meeting).

Recent evaluation work published by the UK AI Security Institute makes the shape of the problem concrete: where agents took unsanctioned actions, establishing what had happened required an investigation rather than a lookup. The evaluation was conducted with safeguards disabled and with internet access granted, so the conditions do not reflect a public deployment; the relevant point here is not the level of risk but the reconstruction problem itself.

Why this belongs in FG-TIDA rather than elsewhere

Trust and identity are usually framed as an admission question: may this agent act. The same identity and delegation structures also determine whether anyone can later establish, in a verifiable way, that a particular agent acted and under whose authority.

If FG-TIDA defines the architecture for the first question and not the second, the two will be designed separately and will not fit together.

Scope to explore
What must be recorded at the time of an action so that a party who was not present can later establish which agent acted, under whose delegated authority, and within what declared scope.
What properties such a record needs in order to survive multi-step delegation, where the acting agent is several hops away from the human or organization that authorized the chain.
How a relying party establishes that a record has not been altered since it was made, without relying on the good faith of the party that produced it.
Where the boundary sits between what can be standardized technically and what necessarily remains a matter of national law and organizational policy.
How the answers relate to the transparency and record-keeping obligations that are beginning to take effect in several jurisdictions.
Non-goals
Not a protocol specification.
Not concerned with model internals or with how any value is computed.
Not a replacement for existing logging and audit practice. The question is narrower: what makes a record verifiable by someone who was not there.
Not a liability framework. Determining legal responsibility is out of scope; the question is what technical record makes that determination possible.
Relation to other candidate themes

This theme sits downstream of Design-based Agent Identity, Remote Attestation and the Agent Identity and Trust Stack, and consumes their outputs rather than competing with them. It is closest to the trust stack proposal, and could be developed either as a layer within it or as a separate theme, depending on how the group decides to consolidate.

Note

Raising this as a Proposer only. I am not seeking a chair or leadership role, and I would be glad to see this taken up and developed by others.