financial-services-interest-group

Context On 23 Sep I offered in #financial-services-ig to take the open topic "Regulatory audit & attestation: portable, verifiable event/claim models". @vinoo999 put it on the 24 Sep agenda in the meeting notes for champion assignment and asked for an outline the group could review. This is that outline, for the 22 Oct call. The FSIG charter's compliance and auditability line asks for "tamper-evident, portable records of what a tool call did" to meet "regulatory audit and incident-review obligations". The outline proposes what that record says about a tool call, and how an implementation shows it conforms. The problem Today the record of a tool call is usually a log kept by the firm that ran it, so an examiner has to trust the party being examined. The record is useful at audit only if a third party can check it offline, without access to that firm's systems. What the record answers For each tool call the record says who acted, what the request was (the action and a digest of its arguments), whether it was permitted or denied, what was written or that nothing was, and how that was observed: from whose vantage, and whether the observer committed to that before the call. A verifier checks it offline. The signature covers the record's canonical JSON bytes (RFC 8785), the request digest must match the action, each write must start from the state the previous write left, and a record may only claim the authoritative tier when it was observed from outside the agent and the observer committed before the call. Every other record is voluntary. The record names these as fields, so two implementations mean the same thing by them: vantage (who observed), tier (voluntary or authoritative), binding (whether the arguments are covered by a digest), observed effect and enforcement. Conformance as a test corpus "Conformant" should be a pass or fail answer, not a reading of prose. I maintain a public corpus for this record, vectors-agent-audit-record, in a repository I run with tagged releases: 68 vectors, of which 17 are valid records a verifier must not reject, 49 are malformed records it must reject, and 2 accept either "valid" or "indeterminate" as the answer. The record format is my individual IETF draft, draft-gilda-wimse-agent-audit-record-02, and its predicate is . Pinned install (Python 3.12 or later): Or as a CI step against your own verifier: I propose the workstream define conformance as passing a pinned release of the corpus, and add finance cases to it as new vectors by pull request. Where the corpus and the record definition live long term is a question for the group. For the group to fill in Asks Comments here before the 22 Oct call would help. I would also like to be listed as champion for "Regulatory audit & attestation". @kingyewchoo offered on 12 Oct to help with this item, and I would welcome him as co-champion if he wants it. Edited 2026-10-21: changed @kychooo to @kingyewchoo after his account rename.

Summary MCP does not guarantee that the tool metadata shown to a human in the approval dialog matches the metadata sent to the model, and it does not require re-approval when that metadata changes afterwards. I think that is a spec-level gap rather than something we should paper over with an extension, and I want to check that reading with the group before taking it further. The behaviour is documented in arXiv:2607.05744. The gap A server advertises tools through , returning a name, a description and a JSON input schema. The client renders that once in an approval dialog, then injects it into the model's context on every later turn. From the paper: Nothing in the protocol requires the rendered approval view and the bytes delivered to the model to match. The demonstration uses Unicode's TAG block (U+E0000 to U+E007F), which has no glyph in mainstream terminal, chat or IDE renderers, so a payload written in it never appears to the reviewer but reaches the model's tokenizer intact. What was measured The proof of concept runs against a real MCP client and server over JSON-RPC/stdio, covering 5 metadata surfaces with 8 techniques: 8 of 8 deliver an attacker-controlled payload into model context 4 of 8 evade a representative string-matching sanitiser 1 of 8, the TAG-block encoding, is invisible in the approval view and still reaches the model verbatim 0 of 8 trigger re-approval, including under a time-of-check to time-of-use rug pull** The last line is the one I care about. The catalogue was re-run against 3 independently developed Python MCP server libraries and agreed across all 32 cross-library outcome cells, so this looks like protocol behaviour rather than one library's bug. The sanitiser flagged 0 of 25 benign descriptions, so the sanitiser was discriminating and the evasion numbers hold. Why it matters to us specifically Plenty of people have covered the security angle. What I want to raise is what happens at audit. A regulated firm has to show afterwards that an action was authorised, and on what understanding. That runs through the approval event. If the approved bytes and the in-use bytes can differ, and metadata can change later without the approval lapsing, the approval record does not describe the thing in use. The record then proves nothing, which is a worse position in an examination than a control everyone agrees is weak. EU AI Act Article 14 assumes the human is overseeing the deployed system. GDPR Article 22 assumes an identifiable basis for the processing. FINRA's 2026 agent guidance and model risk documentation assume a control description matches the control. arXiv:2606.29142, written from a production KYC deployment, ends up in the same place: the hard part of regulated agent deployment is making auditability and least-privilege authorisation real at production scale. Why not an extension An extension sits on top of the gap without closing it, and it would not be portable. If some institutions adopt one and others do not, "approved tool description" means different things in different places, which is the opposite of what this group exists for. Render fidelity is a general requirement that finance can state precisely, because we are where an unfalsifiable approval record causes visible trouble first. Metadata routinely changes after approval arXiv:2608.00997 tracked the official MCP registry over 88.6 days and 19,099 servers, and recommends content binding, meaning revalidate when a description's hash moves. The authors call this scanner hygiene rather than a runtime trust signal and I would keep that distinction. arXiv:2608.23763 benchmarks servers that behave normally through review and switch payloads later. arXiv:2606.27027 splits malicious instructions across several tool descriptions so none looks bad on its own. What I am asking for allows proposals by issue, discussion on GitHub, lazy consensus, and decisions recorded in issue threads, so I am raising it here instead of asking for agenda time. 1. Does the group read this as spec-level? Objections here. 2. I will draft a short position paper making the accountability case: informed authorisation needs render fidelity and re-approval on material metadata change. The security research already exists, so this is drafting rather than research. 3. puts the liaison step with maintainers. Someone would need to take it to @dsp-ant, or tell me I can. Caveats arXiv:2607.05744 is a preprint. I checked its ID, title, date and abstract against the arXiv API, but the figures are the authors' and I have not reproduced the harness or reviewed the method. Read it before leaning on it. I have not checked author affiliations either, so the neutrality points in apply. https://arxiv.org/abs/2607.05744

MCP Community Engagement We flagged the lab and this proposal to the MCP Financial Services Interest Group on 2026-09-24, and the group supported raising it here as an RFC. This issue continues that conversation. It is the written proposal, with the code to test it. Thank you to the Maintainers and attendees of that meeting for their support and guidance: @sambhav + @PederHP + @vinoo999 +@karth295 We first raised the topic in April as #2638 on the specification repository. It was closed the same day, for no AI disclosure and no concrete mapping to MCP concepts. We took that feedback and built a reference implementation. It models the requirements of a CDAO in a regulated industry, and an evidence matrix traces each requirement to the code and a command that tests it. We have also mapped how the data flows through to the other standards. We hope this makes the link to MCP concepts clear. This issue discloses AI use and proposes a specific key, with a schema and code that reads it. Our position Governance, observability and management are three different things. Governance says what should happen, and observability shows what is happening. We set that out in gov!=o11y and, for AI, in aigov!=aio11y. The open standards each have a job. MCP connects the agent to the tool. OpenTelemetry is the standard for software and infrastructure observability. OpenLineage holds the lineage record: which run reached which data. In a regulated firm that record is what an auditor asks for. We think each standard should keep its own job, hold its own data, and carry only a reference at its boundary. MCP is the boundary between the caller and the server. A server can record what it reached. It cannot know which unit of work the call belongs to, unless the caller says so. The proposal 1. A documented key that carries the caller's run and job: parent run id, job namespace and job name. No protocol change is needed. The rules already allow keys with a vendor prefix, so is valid today. An extension adds agreement on the name and the shape across implementers. 2. A schema for the value, and not only a name. A server must tell an absent key from a malformed one. An absent key is the normal case for an older client, and the server handles it silently. A malformed key is a broken integration, and the server must report it. Without a schema each server defines "malformed" for itself. We found this when we ran the code, and tests show it. 3. A narrow use. The key serves a caller that emits its own run. A caller with no run has nothing to name, and is its link. The lab The BearingNode lab runs an instrumented server against synthetic insurance data. For each SQL statement an agent runs, it sends an OpenLineage to Marquez. The lab has 112 unit tests and 20 integration tests. Its evidence matrix scores it against eleven requirements: two met, nine partly met, none unmet. Each row has a command that reproduces it. What we built The caller can send two references in , one for each record. links the server's span to the caller's trace. The second key links the server's lineage run to the caller's run. The server copies it into the standard OpenLineage : The two references back each other up across the call. If a client sends no , the lineage parent is the only link to the caller. If the caller emits no run, the trace is the only link. Scope The lab holds the server side only. It reads the key and fills the facet. No client sends the key today, and our own test driver does not. We ran MCP SDK 1.28.1 against protocol revision . We did not run . That revision reserves in , and what we say about it is a reading of the text. The lab covers MCP over Postgres through SQL. What we do not ask Who authorised the call. The key points to a run and does not name a principal. We found no attribute that records authority in OpenLineage, MCP or OpenTelemetry. We list that as a gap. Anything for work declared in advance, such as a scheduled pipeline or a scheduled agent. The existing job and producer model serves it. Any change to how works. Work in the other standards The same principle guides what we ask elsewhere. OpenLineage: our comment on #4484 proposes two Run facets: a link from a run to its trace, and a reference to the caller. OpenTelemetry: semantic-conventions-genai#589 sets out the reference from the span to the lineage run, with no data names on the span. We have also updated the EDM Association (EDMA) AI Governance Working Group. Break it We would like the lab challenged before any extension is agreed. Run it, and tell us where it fails. The cases most worth trying are a gateway or proxy in front of the server, a chain of more than one client and server, a client that sends the key in a shape we did not expect, and data that reaches a decision without a tool call. Please open issues on the lab repository. A confirmed break goes into the lab's public RAID log. Next step We ask the group to review the proposal and comment here. The group's contributing guide says to get feedback before implementation. Once there is broad support, we are happy to raise the necessary pull request. AI assistance was used throughout the lab's code and documents, and it helped to pull this post together. The standing declaration is in .