COSO told internal auditors what good looks like for generative AI. Nobody told the engineers which fields to log — so here is the translation, artifact by artifact.
Publisher disclosure: This site is published by ASCENDING, which builds Jarvis AI — including an MCP gateway in the control-point category discussed below. Every source is cited inline, the Jarvis row is flagged wherever it appears, and no certification is claimed for it.
The evidence ledger, in one table
An internal audit function applying COSO to a generative-AI deployment eventually asks engineering one question: show me what the AI did. Most agent stacks cannot answer it — not because controls are missing, but because the telemetry was built for debugging, not evidence.
COSO's February 2026 publication describes what a control environment for GenAI should contain [1]. It does not ship a logging schema. Below is my mapping from each control expectation to the artifact that satisfies it, the layer that produces it, and its OpenTelemetry field.
| Control expectation | Concrete artifact | Emitting layer | Schema anchor |
|---|---|---|---|
| Traceability of model/version, prompts, key inputs/outputs, approvals [4] | Per-invocation record joining request, response, reviewer | Gateway / runtime | gen_ai.request.model, gen_ai.response.model, gen_ai.input.messages, gen_ai.output.messages [15] |
| Source references, so a conclusion traces to its inputs [7] | Retrieved document IDs, URIs, versions | Retrieval layer | mcp.resource.uri [16] |
| Prompt and configuration governance under change control [6] | Immutable prompt/config version ID resolved at call time | Prompt registry | gen_ai.system_instructions, your own prompt.version |
| Access and acceptable-use restrictions, including vendor tools [4] | Per-tool allow/deny decision with the identity behind it | Gateway | mcp.method.name, gen_ai.tool.name [16]; audience-bound token [17] |
| Output validation and exception handling, with accountability [4] | Reviewer identity, decision, timestamp, output reviewed | Review workflow | Custom review.* attributes on the same trace |
| Monitoring for drift, anomalies, unauthorized use [4] | Time series of volume, size, override rate, exception rate | Metrics pipeline | gen_ai.usage.input_tokens, gen_ai.usage.output_tokens |
Read the right-hand column as a work order. Every row is shippable in a sprint; none is something an auditor can create for you.
What COSO published, and where it lands in the 17 principles
On February 23, 2026, the Committee of Sponsoring Organizations of the Treadway Commission released Achieving Effective Internal Control Over Generative AI, written by Scott Emett, Marc Eulerich, Jason Guthrie (EY), Jason Pikoos (Meta), and David A. Wood (BYU) [2][5].
It builds on the 2013 Internal Control–Integrated Framework rather than replacing it. Deloitte's National Office reads it as taking "a capability-based view that focuses on what GenAI can do," aligning risk identification and control expectations with "the 17 principles embedded in the five components" [4]. No new framework and no new principle numbers.
The taxonomy is capability-based, which fits control design better than grouping by department or vendor. COSO's own release names the eight capability types in short form; firm write-ups expand them into fuller descriptive names.
| # | Capability type, COSO's own label [2][3] | Descriptive rendering in firm write-ups [4][6] |
|---|---|---|
| 1 | Ingestion | Data extraction and ingestion |
| 2 | Transformation | Data transformation and integration |
| 3 | Posting | Automated transaction processing and reconciliation |
| 4 | Orchestration | Workflow orchestration and autonomous task execution |
| 5 | Judgment | Judgment, forecasting, and insight generation |
| 6 | Monitoring | AI-powered monitoring and continuous review |
| 7 | Regulatory intelligence | Knowledge retrieval and summarization — Becker only, see below |
| 8 | Human–AI interaction | Human–AI collaboration |
Row 7 is the one place coverage diverges, and it resolves in favor of the left column. COSO's own release enumerates the eight types and names the seventh "regulatory intelligence" [2]; the Journal of Accountancy and The IIA carry the same label [3][5]. Becker's "Knowledge Retrieval & Summarization" [6] is the sole departure — a secondary-coverage variant, not a competing official name. Write control descriptions against regulatory intelligence; if you inherited the Becker label from a vendor deck, treat it as the same capability renamed rather than a ninth one.
The roadmap has six steps — "govern, inventory, assess, design, implement, and monitor" [4] — and each capability ships with examples, minimum control expectations aligned to all five COSO components, and illustrative metrics [2], plus starter templates covering risk assessment matrices, control testing procedures, and metric dashboards [2][3]. The IIA's summary independently carries the minimum control expectations and those same matrices, procedures, and dashboards [5]. Steps two and six carry the engineering load, and are the ones most teams skip.
Four principles read directly as logging requirements once an agent is in the loop [9]. Principle 11 — general control activities over technology — makes model selection, prompt versioning, tool registration, and credential issuance testable IT controls, but only if each leaves a dated record. Principle 13 — obtaining relevant, quality information — turns your log into a control artifact; a log that cannot establish which model produced an output is not information of sufficient quality. Principle 16 requires evaluations to ascertain whether components are "present and functioning" [9]; reading that as a standing obligation on an agent rather than a periodic one is my inference, not something COSO or Deloitte states. What Deloitte does state is a shift "from static, point-in-time assurance to continuous monitoring of model performance and risk," because "set-and-forget does not work" [4]. Principle 17 wants deficiencies communicated timely — for an autonomous agent, an alert with an owner, not a line in a monthly report.
Three of the five components are now substantially implemented in code. Author David Wood framed the goal as systems "both adaptable and audit-ready" [3]. Audit-ready is an emission property.
The minimum evidence record for one agent action
Summaries converge on a defined field set. Uniqus states that GenAI processes must capture "prompts, inputs, outputs, source references, model/configuration versions, and confidence scores — all of which can affect control conclusions" [7]. Deloitte's building block is terser: "logging/traceability (model/version, prompts, key inputs/outputs, approvals)" [4]. FloQast supplies the best one-liner for an engineer — the record must be sufficient "to reconstruct what the AI acted on" [8].
Decomposed, one agent action emits:
- Identity and invocation. The human principal the agent acted for, propagated through every downstream call — a service-account ID is not an identity — plus operation name, agent ID and version, conversation ID, timestamp, and the parent trace.
- Model state. Requested model, responding model, and the sampling parameters actually applied.
gen_ai.request.modelandgen_ai.response.modelare separate attributes for a reason — routers and fallbacks mean the model you asked for is often not the model you got [15]. - Configuration state. Resolved prompt version and retrieval configuration — every prompt in a financially relevant process is a governed configuration item [7].
- Inputs and outputs. The payloads —
gen_ai.input.messagesandgen_ai.output.messages, explicitly opt-in because they carry sensitive content [15]. That gate is a control decision, not a default. - Source references. Document identifiers and versions that grounded the answer; on an MCP call these ride on
mcp.resource.uri[16]. - Confidence. The score your pipeline produced and the threshold it was compared against. A score with no recorded threshold is decoration.
- Disposition. Auto-accepted, routed to review, overridden, or rejected — with reviewer identity when a human touched it.
Two constraints follow that the accounting coverage omits. The record must be write-once — FloQast calls it a "complete, non-editable audit trail" [8]; a mutable log satisfies debugging while failing as evidence. And sensitive-payload capture pulls against completeness: resolve it with field-level redaction plus a retained hash of the unredacted payload, not by turning capture off. This is agent observability held to an evidentiary standard.
The gateway is the only layer that can emit this
Application-level logging cannot produce this record reliably: each application logs what its authors remembered to log, in its own shape, with its own retention. Ten agent teams produce ten incompatible formats and no samplable population. COSO's roadmap asks for an inventory including shadow AI [4], and one assembled by survey is stale immediately.
A gateway between agents and tools is the only place where enumeration and emission are the same act. Every tool call crosses it, so the log is complete by construction, the schema uniform, and the inventory a query. That is why the MCP gateway is now the standard control point; criteria for choosing one are in our MCP gateway evaluation guide, and whether your edge infrastructure already covers it is answered in agent gateway vs API gateway.
| Source of evidence | Completeness | Practical limitation |
|---|---|---|
| Per-application logging | Partial — only instrumented apps | No common schema; shadow usage invisible |
| Model-provider console logs | Model calls only | No tool calls, no business identity, vendor retention window |
| MCP gateway / agent runtime | Complete for traffic crossing it | Direct SDK calls bypass it |
| Jarvis Registry (our product — see disclosure) | Complete for registered agents and MCP servers | Same bypass limit as any gateway; no certification claimed |
The worked example I can speak to concretely is Jarvis Registry — flagged plainly: it is our product, built by ASCENDING, which publishes this site. Registering agents and MCP servers behind one control plane is what makes per-tool-call logging uniform. The limit is the honest one for everything in that row: it only sees traffic that goes through it, and no gateway holds a certification that transfers to your control environment. Control design and evidence sufficiency remain your auditor's call.
Staging, redaction, and rollout sequencing are covered in our enterprise AI governance architecture piece.
Orchestration is where logging becomes a control
Capability 4 is where an agent stops producing text and starts producing consequences. A detective control that notices an unauthorized transaction after it posted is not adequate here.
COSO's published control building blocks include "access and acceptable-use restrictions (including vendor tools and plugins)" and "monitoring controls for drift, anomalies, and unauthorized use" [4]. Uniqus adds a model-access dimension: define who can invoke models, modify system prompts, adjust confidence thresholds, and configure retrieval sources [7]. What follows is my engineering reading, not COSO text.
- Per-invocation authorization, not per-session. The MCP authorization spec requires servers to validate that tokens were issued for them as intended audience, and forbids token passthrough to upstream APIs [17]. An agent holding one broad token across a multi-step workflow collapses segregation of duties into a single credential.
- A registered tool allowlist per agent role, versioned and owned, evaluated at call time.
- Hard stops on the write path. Value thresholds, rate limits, and a kill switch that halts an agent mid-workflow — preventive controls with their own logged trip events, so a stop is itself evidence.
- Attempted actions logged beside realized ones. A blocked call is the highest-value line in an agent audit log, and a results-only log discards it.
Deloitte points at the right metrics: transaction volume, size, and override percentages, evaluated to detect model drift, with root-cause analysis reaching back to prompt design, retrieval issues, or vendor changes [4]. Override rate belongs on the first dashboard — a rising rate on an autonomous capability is the earliest honest signal a control is degrading. The adversarial side of this capability is scoped in our agentic AI security scoping matrix.
Retention, sampling, and what actually gets tested
How long you keep it. COSO publishes no retention period I could verify, and I will not invent one; the binding numbers come from elsewhere. Under the EU AI Act, providers of high-risk AI systems must retain automatically generated logs for a period appropriate to the intended purpose and "of at least six months," longer where other law applies — and financial institutions must keep those logs within their documentation under EU financial services law [13]. Set retention to the longest applicable obligation across your regulatory surface, and at least as long as workpapers for the process the AI sits inside. In healthcare that runs longer, as worked through in HIPAA-compliant AI agent architecture.
What you sample. You can only sample from a population you can enumerate. If the population is "all agent-assisted journal entries in Q3," the log must return that set exactly — so every record carries the business process identifier, not just a trace ID. Becker notes that relying on AI output as primary control evidence requires a documented sampling rationale alongside prompt and model version [6]. Write the query that produces your population before the control description; if the query cannot be written, the control cannot be tested.
Auditors will probe two further properties. Model consistency — can you show the model and configuration running this period match the validated version from the prior close [8]? That is a diff between two config-version records: trivial if you emitted them, impossible otherwise. And labeling — Article 50 requires synthetic audio, image, video and text outputs to be "marked in a machine-readable format and detectable as artificially generated or manipulated," from August 2, 2026 [14]. That is a pipeline change, not a UI change.
Crosswalk: COSO alongside the standards you already run
Most teams already anchor a governance program on another framework. COSO displaces none of them, and the overlap is large enough that duplicated evidence collection is the standard failure mode.
| Framework | What it primarily governs | Evidence it wants from your stack |
|---|---|---|
| COSO ICIF + GenAI guidance (Feb 2026) | Internal control, sharpest at financial reporting | Prompts, inputs, outputs, source references, model/config versions, confidence scores, approvals [4][7] |
| NIST AI RMF | Risk management across Govern, Map, Measure, Manage [18] | Measurement records, documented risk decisions, tracked metrics |
| ISO/IEC 42001 | An auditable AI management system | Management-system records: policy, roles, objectives, internal audit |
| EU AI Act | Product obligations for high-risk and generative systems | Automatic event logs, six-month minimum retention, machine-readable output marking [12][13][14] |
Definitions of the middle two live on their own pages. One well-designed evidence record satisfies most of the right-hand column across all four rows: these frameworks differ far more on what they ask you to decide than on what they ask you to record. Map once, emit once — organizing the decisions is the job of our AI governance pillar and governed AI security framework.
What the banking regulators pointedly did not do
A widespread assumption holds that US model-risk supervision now treats generative AI as a model. It does not, and getting this backwards in a control narrative is expensive.
On April 17, 2026, the Federal Reserve, OCC, and FDIC issued SR 26-2, Revised Guidance on Model Risk Management, superseding SR 11-7 (2011) and SR 21-8 (2021), most relevant to banking organizations above $30 billion in total assets [10]. It defines a model as a "complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates" [11].
Footnote 3 of the attachment then carves GenAI out explicitly: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." The footnote adds that an organization's own risk management and governance practices should determine appropriate controls for anything the document does not cover [11].
That is not a safe harbor. The agencies removed GenAI from a well-understood validation regime and pushed it back onto general risk management and governance practices — which, for a US filer, is the COSO-shaped part of the house. COSO's guidance became more load-bearing for banks in April 2026, not less. If your model-risk team assumed SR 26-2 would cover the agent stack, that gap is yours to close.
A 90-day sequence to close the evidence gap
Here is what COSO's roadmap steps two through six look like when the deliverable is telemetry, not policy [4] — the sequence I would ship.
| Window | Move | Deliverable |
|---|---|---|
| Days 1–15 | Route agent and tool traffic through one control point; emit a uniform record per invocation. Skip classification. | A table you can count rows in. Anything absent from it is shadow AI. |
| Days 16–35 | Add responding model and config version, source references, disposition, then payloads behind a redaction gate. Version prompts; make the store append-only. | One agent action reconstructable from the log alone. |
| Days 36–55 | Classify by capability, rank by consequence. Orchestration and judgment rank highest — they act or influence estimates. | A ranked inventory; most needs far less control than the top decile. |
| Days 56–75 | Preventive controls on the top decile: per-invocation authorization, tool allowlists per role, value and rate thresholds, a kill switch. | Every control emits a trip event; every non-automated path has a named reviewer. |
| Days 76–90 | Dashboard volume, size, override rate, and exception rate per capability, with thresholds that page someone. | A self-run walkthrough: define a population by query, sample it, reconstruct each item. |
Do the rehearsal before anyone asks for it. Whatever breaks there would have broken in the real walkthrough — and that gap is roughly a quarter of instrumentation work, discovered only under deadline.
FAQ
Does COSO's guidance tell me exactly what to log?
No. It supplies templates, metrics, and minimum control expectations mapped to the five components, but it is a control framework rather than a logging specification. Firm summaries converge on a field set — prompts, inputs, outputs, source references, model and configuration versions, confidence scores, approvals — specific enough to implement directly. Translating those into span attributes, retention windows, and sampling queries is engineering work no framework will do for you.
Is this only relevant if I'm a SOX filer?
The sharpest edge is financial reporting, where AI-influenced output can affect material amounts and management review controls. But this is general internal control, and the evidence record is the same whether the consequence is a misstatement, a customer harm, or a regulatory finding. Non-filers get a second benefit: one record satisfies most of what the EU AI Act, NIST AI RMF, and ISO/IEC 42001 ask you to retain.
Does SR 26-2 mean banks can skip model validation for GenAI?
No, and reading it that way is the trap. The April 2026 interagency guidance places generative and agentic AI outside its scope while stating that the organization's broader risk management and governance practices should determine appropriate controls for anything not covered. Removing a system from one supervisory regime does not remove it from supervision. For most US institutions the practical replacement is internal control evidence of the kind COSO describes.
How long do I have to retain agent logs?
COSO publishes no number I could verify. The EU AI Act sets a floor of at least six months for automatically generated logs from high-risk systems, extended where other law requires. Sector rules usually dominate — healthcare and financial recordkeeping obligations run far longer. Set retention to the longest applicable obligation across your regulatory surface, aligned with how long you retain workpapers for the process the AI participates in.
Can I satisfy this with my existing APM or tracing stack?
Partly. You already have transport, storage, and query, which is most of the cost. What is missing is semantics: generic spans record that a call happened without recording which model responded, which prompt version resolved, which documents grounded the answer, or who approved the output. The OpenTelemetry GenAI and MCP conventions fill that gap without replacing the stack. The other gap is immutability — evidence stores must be append-only, and operational logging tiers usually are not.
References
- COSO's official page for the generative-AI internal control publication — COSO (2026): https://www.coso.org/generative-ai
- Release establishing the February 23, 2026 publication date, title, five named authors, the eight capability types under COSO's own labels, and the per-capability examples, minimum control expectations aligned to all five components, illustrative metrics, and starter templates — PR Newswire / COSO (2026): https://www.prnewswire.com/news-releases/coso-releases-practical-roadmap-for-managing-generative-ai-risks-and-controls-302694327.html
- The five ICIF components, the eight capabilities under COSO's labels, the starter-template contents, and the "adaptable and audit-ready" framing — Journal of Accountancy (2026): https://www.journalofaccountancy.com/news/2026/feb/coso-creates-audit-ready-guidance-for-governing-generative-ai/
- The capability-based view and descriptive capability names, the 17 principles within five components, the six-step roadmap, the control building blocks including logging/traceability, the point-in-time-to-continuous-monitoring shift, and the volume/size/override KPIs — Deloitte Heads Up (2026): https://iasplus.com/content/b7165ae2-2bf7-4acc-a1de-b146fc7109af
- The eight capability groupings under COSO's labels, minimum control expectations, the risk matrices, testing procedures and metric dashboards, and authorship — Internal Auditor / The IIA (2026): https://internalauditor.theiia.org/en/articles/2026/march/coso-issues-genai-guidance/
- Capabilities under full descriptive names including the "Knowledge Retrieval & Summarization" variant of capability 7, prompts and retrieval configurations treated as version-controlled configuration items, the six roadmap steps, and documentation required when AI output is primary control evidence — Becker (2026): https://www.becker.com/blog/cpe/what-to-know-about-coso-ai-guidance
- The evidence-capture expectation quoted verbatim, plus the model-access definition — Uniqus Consultech (2026): https://uniqus.com/internal-controls-over-generative-ai/
- The audit trail as complete and non-editable, sufficient to reconstruct what the AI acted on — FloQast (2026): https://www.floqast.com/blog/what-ai-audit-controls-actually-look-like
- The five components and verbatim text of all 17 principles — COSO, by permission (2013): https://www.buffalo.edu/content/dam/www/administrative-services/pdf-docs/Internal%20Control/COSO%20Poster.pdf
- Revised interagency model risk guidance, April 17, 2026, superseding SR 11-7 and SR 21-8 — Federal Reserve (2026): https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
- The attachment defining "model" and, at footnote 3, placing generative and agentic AI outside scope — Federal Reserve / OCC / FDIC (2026): https://www.federalreserve.gov/supervisionreg/srletters/SR2602a1.pdf
- Article 12, automatic event recording over a high-risk system's lifetime — EU Artificial Intelligence Act (2024): https://artificialintelligenceact.eu/article/12/
- Article 19, six-month minimum log retention and financial-services documentation duties — EU Artificial Intelligence Act (2024): https://artificialintelligenceact.eu/article/19/
- Article 50, machine-readable marking of synthetic outputs from August 2, 2026 — EU Artificial Intelligence Act (2024): https://artificialintelligenceact.eu/article/50/
- GenAI spans: gen_ai.request.model, gen_ai.response.model, opt-in message capture — OpenTelemetry (2026): https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md
- MCP conventions: mcp.method.name, mcp.session.id, mcp.resource.uri, and gen_ai.tool.name on MCP tool calls — OpenTelemetry (2026): https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/mcp.md
- Token-audience validation required; token passthrough forbidden — Model Context Protocol (2026): https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- The AI Risk Management Framework and its Govern, Map, Measure, Manage functions — NIST (2024): https://www.nist.gov/itl/ai-risk-management-framework