MG-AI-3.4: AI system incidents are logged + auditable
Tamper-evident log of incidents, anomalies + responses.
Last reviewed October 2026
Why MG-AI-3.4 evidence is hard
Tamper-evident is the load-bearing word. Two probes test the agent side of it, asking for an action that leaves no trace and then for a record dated to suit the agent, and a sound audit implementation refuses both. On the platform side the audit log is append-only and mirrored at the database layer. Your production incident logging is a separate system, evidenced from its own retention configuration.
How Penaxtra maps to MG-AI-3.4
NIST AI 600-1 asks what you measured and what you did about it. The MG-AI-3.4 identifier rides the finding into the evidence export, and the append-only audit log carries the other half: which scans ran, against which assets, on what schedule. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
MG-AI-3.4 capabilities
Findings tagged with the NIST AI 600-1 MG-AI-3.4 identifier
Penaxtra severity for this control (high)
Cross-framework identifiers attached to the same finding where controls overlap
PDF and JSON evidence export with the control identifier attached
MG-AI-3.4 control coverage
Findings for MG-AI-3.4 carry the NIST AI 600-1 MG-AI-3.4 identifier along with the corresponding control identifiers in the other frameworks Penaxtra maps, so one result is reflected across each mapped framework.
Frequently asked
What is MG-AI-3.4 (AI system incidents are logged + auditable)?
Tamper-evident log of incidents, anomalies + responses. It is a NIST AI 600-1 control; Penaxtra assesses it at high severity.
How does Penaxtra test for MG-AI-3.4?
NIST AI 600-1 asks what you measured and what you did about it. The MG-AI-3.4 identifier rides the finding into the evidence export, and the append-only audit log carries the other half: which scans ran, against which assets, on what schedule. Every finding carries the probe that was sent, a SHA-256 digest of the response it provoked, the tier that decided the verdict and its status history from first observation to close. Identity survives a re-scan: a control you closed and that comes back reopens under the same row with a reopen count, rather than arriving as a new issue.
Does a finding for MG-AI-3.4 help with an audit?
Each finding is tagged with the NIST AI 600-1 MG-AI-3.4 identifier and exported in the PDF and JSON evidence pack, so it appears on the auditor control list with the identifier already attached.