Family Guides
AWOSS-LOG: Logs, Receipts, And Traceability
Teams need receipts, not just transcripts. AWOSS-LOG defines what should be traceable when an agent requests an action, uses a tool or connector, receives a policy decision, gets approval, changes something, or relies on a particular source or configuration.
The record also has to be usable. An authorized reviewer should be able to reconstruct the important parts of the workflow without reopening secrets or private business content that should stay redacted.
One agent run can span a user request, retrieved context, model call, tool call, connector action, shell command, source update, human approval, DLP or redaction decision, generated file, and downstream SaaS or cloud event. When something later needs review, the organization needs a trail that is durable, attributable, redaction-safe, and complete enough to explain what happened.
What This Family Covers
In scope:
- Runtime traces, tool-call records, connector records, workflow records, policy-decision logs, approval receipts, denial records, and error records.
- Records for high-impact action requests, production writes, access-control changes, external communications, sensitive-data movement, source changes, boundary changes, validation runs, incidents, disclosure events, and escalations where applicable.
- Minimum receipt fields for high-impact action events, including timestamp, actor or system identity, runtime or workflow identifier, action class, resource scope, policy outcome, approval state, stable event identifier, and redaction-safe reference where available.
- Log and receipt locations that must avoid raw secrets, credentials, confidential payloads, sensitive prompts, retrieved content, screenshots, media, tool outputs, and derived summaries unless explicitly protected.
- Retention rules for reviewable records, including retention owner, period, export path, deletion or mutation constraints, and documented gaps.
- Attribution and correlation across users, roles, service accounts, agent identities, sessions, workflows, tools, connectors, source versions, policy versions, approval identities, and downstream request IDs where available.
- Structured exports or review packets that let reviewers inspect the record sequence without receiving raw secrets, credentials, private personal data, confidential payloads, or unrelated business content by default.
- Protection for high-impact action and approval records against unauthorized modification, deletion, or unreviewed retention changes.
- Reconstruction tests that sample a high-impact workflow and check whether records, approvals, policy outcomes, source or configuration state, sensitive-data handling records, and evidence artifacts tell a coherent story.
- Tamper-evident, independently retained, write-once, separation-controlled, monitoring-linked, or incident-linked logging where feasible for high-impact environments.
Out of scope:
- Deciding the complete scoped system boundary, resource list, owners, and exclusions. That belongs mostly to
AWOSS-SCP. - Deciding whose identity and delegated authority an agent uses when acting. That belongs mostly to
AWOSS-DEL. - Filesystem, repository, browser, network, endpoint, shell, and execution boundaries as a control problem. Those belong mostly to
AWOSS-WSB. - Defining the runtime allow, deny, approval, interruption, rollback, and budget policy as a whole. That belongs mostly to
AWOSS-RUN, thoughAWOSS-LOGrecords the outcomes. - Source trust for skills, tools, connectors, plugins, packages, prompts, and supplier components. That belongs mostly to
AWOSS-SRC, though source approvals and update receipts should be logged. - Prompt, memory, retrieval, handoff, and instruction-boundary controls as a whole. Those belong mostly to
AWOSS-CTX, though material context changes should leave receipts. - Secret, credential, and sensitive-data handling policy as a whole. That belongs mostly to
AWOSS-SEC, though log redaction and sensitive-data receipts are essential to this family. - Complete validation-program design, red-team method, or finding lifecycle. That belongs mostly to
AWOSS-VAL, though validation records and reconstruction tests should be retained. - Complete legal, privacy, eDiscovery, regulatory logging, employment monitoring, sector-specific retention, or incident-notification analysis.
- Guaranteeing that a provider, SIEM, trace tool, compliance export, or cloud audit log captures every relevant event.
Level Summary
Levels are cumulative. Level 2 builds on Level 1, and Level 3 builds on both.
| Level | Plain-language meaning | Why this level exists | Typical evidence |
|---|---|---|---|
| Level 1 | The organization knows which agent events are recorded, which events are intentionally not recorded, what a high-impact action receipt should contain, and where sensitive payloads should not appear. | Logging cannot support review until sources, receipt fields, no-log choices, and redaction expectations are visible. | Log source inventory, unlogged-event rationale, receipt schema, sensitive-field policy, redaction expectations. |
| Level 2 | Production workflows retain important records, make them attributable, and can export review packets that are useful without exposing raw sensitive content. | Managed production use needs repeatable records that connect actions, approvals, denials, policies, sources, and identities. | Retention policy, sampled runtime receipts, approval receipts, policy-decision records, correlation map, redacted review packet. |
| Level 3 | High-impact records are protected against silent change, sampled workflows are reconstructable, and critical log signals can reach monitoring or incident review where applicable. | High-impact environments need stronger proof that records remain reviewable and that serious workflows can be explained after the fact. | Integrity control note, write-once or independent retention evidence, reconstruction test result, monitoring map, incident or alert record. |
Candidate Controls
AWOSS-LOG-L1-001: Logged Event Inventory Level 1
Requirement summary
Identify which runtime, workspace, tool, connector, approval, source-change, and validation events are logged or otherwise recorded. Also identify events that are intentionally not logged because logging them would create unnecessary sensitive-data exposure.
Why it exists
Reviewers need to know where the record trail starts and stops. Without a log source inventory, teams may assume that a chat transcript, tool trace, SIEM event, or cloud audit log captures more than it really does. The inventory also makes no-log decisions explicit, such as not retaining raw prompts, screenshots, credentials, full document text, or unrelated payloads when a safer derived receipt is enough.
Why this level
This belongs at Level 1 because visibility comes first. The control does not prove records are complete, retained, or tamper-resistant, but it names the sources and gaps that later retention, attribution, redaction, and reconstruction controls depend on.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Log source inventory | Evidence or audit owner with runtime, workspace, and source owners | Before production use and after adding tools, connectors, runtimes, workflows, source repositories, or evidence stores | Runtime traces, compliance logs, tool-call logs, connector logs, approval records, policy-decision logs, source-change records, validation records, incident records, and known gaps | Identifies likely record sources; does not prove every event is captured. |
| Unlogged-event rationale | Evidence or audit owner with data owner input | During scope review and after sensitive-data or retention changes | Events, payloads, screenshots, prompts, media, or tool outputs intentionally not retained, plus the reason and any safer derived record | Explains no-log choices; does not prove omitted events were low-risk or legally sufficient. |
| Event taxonomy | Runtime platform owner or evidence owner | Before production use and after event model changes | Event classes such as request, tool call, connector action, approval, denial, policy trigger, source update, context change, validation run, incident, disclosure, and escalation | Defines vocabulary; does not prove the taxonomy is enforced across every product. |
AWOSS-LOG-L1-002: Minimum High-Impact Action Receipt Format Level 1
Requirement summary
Define a minimum receipt format for high-impact action events, including timestamp, actor or system identity, runtime or workflow identifier, action class, resource scope, policy outcome, approval state, stable event identifier, and redaction-safe reference where available.
Why it exists
A log line is not automatically a reviewable receipt. A reviewer may need to connect a user request, runtime session, tool call, policy decision, human approval, source version, sensitive-data handling outcome, and downstream effect. A minimum receipt format helps different systems preserve the fields needed for review without depending on one vendor's trace format.
Why this level
This belongs at Level 1 because a receipt schema can be defined before the organization has perfect automation. Later levels ask whether those receipts are retained, attributable, exportable, protected, and reconstructable.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| High-impact action receipt schema | Evidence or audit owner with runtime owner input | Before production use and after action taxonomy or policy changes | Required fields for timestamp, actor, runtime, workflow, action class, resource scope, policy outcome, approval state, stable ID, and redaction-safe reference | Defines expected receipt fields; does not prove all systems emit them. |
| Sample receipt | Runtime platform owner or evidence owner | During implementation review and periodic sampling | A representative high-impact action record with required fields populated or gaps documented | Supports field review; does not prove all receipts are complete. |
| Trace or span field map | Runtime platform owner | Before relying on trace exports and after telemetry changes | How runtime traces, spans, decision IDs, approval IDs, source versions, and downstream request IDs map to the receipt schema | Supports correlation design; does not prove downstream products preserve the same identifiers. |
AWOSS-LOG-L1-003: Sensitive-Safe Log And Receipt Boundaries Level 1
Requirement summary
Identify log or receipt locations that should not contain secrets, credentials, or unnecessary confidential payloads. Define redaction expectations for sensitive prompts, tool outputs, retrieved content, screenshots, and derived summaries where applicable.
Why it exists
Logs can become a second data leak. A trace may store a private prompt, a connector response, a screenshot, a token, a file path, a customer record, a retrieved document, or a generated summary that reveals sensitive content. Review evidence should preserve useful facts without turning every reviewer into a recipient of raw secrets or unrelated confidential material.
Why this level
This belongs at Level 1 because every scoped system needs a clear rule for what logs should not contain. Automated masking, protected evidence stores, redaction tests, and structured review packets can mature later, but the sensitive-safe boundary must be named early.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Sensitive-field and no-payload policy | Evidence or audit owner with data owner input | Before production use and after adding logging, tracing, memory, screenshots, media capture, or evidence exports | Fields, payloads, prompts, retrieved content, screenshots, outputs, and derived summaries that should be omitted, masked, tokenized, summarized, or stored only in protected locations | Defines redaction expectations; does not prove all logs are safe. |
| Redaction or masking configuration | Runtime, logging, or security owner | Before relying on review exports and after pipeline changes | Masked fields, DLP or pattern rules, trace capture settings, prompt/output capture settings, and protected exception handling | Supports redaction review; does not prove transformed, image, voice, or out-of-band content is fully covered. |
| Sanitized export sample | Evidence or audit owner | During evidence packet preparation and review sampling | That a sample receipt or review packet preserves event sequence and decisions while withholding raw secrets and unrelated payloads | Supports review packet quality; does not prove every export is safe to disclose. |
AWOSS-LOG-L2-001: Retained High-Impact Records Level 2
Requirement summary
Retain reviewable records for high-impact action requests, approvals, denials, policy triggers, tool invocations, and material source or boundary changes for an approved retention period. Include disclosure, incident, sensitive-data access, and validation events where applicable.
Why it exists
A receipt that disappears before review is not useful. Production agent workflows may need investigation days, weeks, months, or longer after the event, depending on business, security, legal, and governance needs. This control makes retention explicit for the records most likely to matter.
Why this level
This belongs at Level 2 because managed production use should retain records for review, not only know which records could exist. The requirement still allows retention periods and payload choices to be scoped locally and reviewed for privacy and sensitivity.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Retention policy for agent records | Governance or evidence owner with security and legal input where needed | Before production use and after retention, logging, or scoped-system changes | Retention period, covered event types, protected stores, deletion rules, exception process, owner, and review cadence | Shows intended retention; does not prove product exports are complete or legally sufficient. |
| Sample retained runtime, approval, and policy receipts | Evidence or audit owner with runtime owner input | During operation and periodic sampling | High-impact action request, approval or denial, policy trigger, tool invocation, sensitive-data event, source change, or validation record retained for the approved period | Supports retention sampling; does not prove all records are retained. |
| Evidence custody record | Evidence or audit owner | During review packet creation and after transfer to evidence storage | Where authoritative records or derived receipts live, who controls access, and which raw payloads are withheld or protected | Supports custody review; does not prove the underlying event was complete. |
AWOSS-LOG-L2-002: Attributable Review Records Level 2
Requirement summary
Ensure that records needed for review are attributable to a runtime, user, role, service account, workflow, agent identity, tool or connector, source version, policy version, or approval identity where applicable.
Why it exists
Agent records are hard to review when every action appears to come from the same shared account, one generic integration, or an opaque session. A reviewer needs to connect the human request, delegated authority, agent runtime, service account, tool, connector, source version, policy version, and approval identity where those details exist.
Why this level
This belongs at Level 2 because production records should support accountability and correlation. Level 1 defines the receipt fields; Level 2 expects important records to be attributable enough for real review.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Correlation field map | Runtime platform owner with evidence owner input | Before production use and after identity, policy, source, connector, or telemetry changes | User ID, role, service account, agent identity, runtime session, workflow ID, trace ID, decision ID, approval ID, source version, tool/connector ID, and downstream request ID where available | Supports attribution design; does not prove every product preserves all IDs. |
| Sample attributable receipt set | Evidence or audit owner | During operation and review sampling | A high-impact event linked to requester, approver, runtime, workflow, tool, policy version, source or config version, and downstream action where applicable | Supports accountability review; does not prove the action was authorized or safe. |
| Shared-account or attribution-gap register | Governance, identity, or runtime owner | During scope review and after account or connector changes | Places where records rely on shared accounts, delegated identities, vendor-owned IDs, missing request IDs, or manual correlation | Documents gaps; does not by itself reduce the risk. |
AWOSS-LOG-L2-003: Structured Review Exports And Summaries Level 2
Requirement summary
Provide structured exports or summaries that allow review without exposing raw secrets, credentials, confidential payloads, private personal data, or unrelated business content.
Why it exists
Raw logs are often too sensitive, while over-redacted logs are often useless. A structured review packet should preserve the event sequence, classifications, policy decisions, approvals, denials, source references, validation links, and protected-material references needed for review while withholding raw payloads by default.
Why this level
This belongs at Level 2 because production review needs a repeatable export or summary process. It builds on Level 1 redaction boundaries and Level 2 retention by making the retained records reviewable in practice.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Redacted review packet | Evidence or audit owner | During review, audit sampling, incident review, or release gate | Event sequence, actor/runtime/tool/resource references, policy outcomes, approvals, denials, sensitive-data handling state, validation links, and withheld-material rationale | Supports review without default raw payload exposure; does not prove the packet contains every relevant event. |
| Structured export template | Evidence or audit owner with runtime owner input | Before review packet generation and after schema changes | Required sections, receipt fields, redaction handling, protected-reference rules, reviewer notes, and missing-field handling | Supports repeatable exports; does not prove exports are accurate. |
| Reviewer access record | Evidence or governance owner | During evidence review and after sharing | Who received the packet, what sensitivity level it had, which protected originals were not shared, and what escalation path exists for protected review | Supports access review; does not prove disclosure was legally or contractually sufficient. |
AWOSS-LOG-L3-001: Protected High-Impact Records Level 3
Requirement summary
Protect high-impact action and approval records against unauthorized modification, deletion, or unreviewed retention changes. Document any gaps where authoritative records remain outside the assessed boundary.
Why it exists
Important records can be weakened after the fact if an administrator can delete logs, shorten retention, rewrite evidence, change export settings, or remove source-system records without review. High-impact workflows need stronger custody and explicit gap records when authoritative logs are owned by another product, provider, team, or boundary.
Why this level
This belongs at Level 3 because tamper resistance, independent custody, separation of duties, and retained gap evidence are stronger assurance expectations. They are not always feasible for every system, but high-impact environments should use them where practical and document where they cannot.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Log protection control note | Security, evidence, or platform owner | Before high-impact use and after retention or storage changes | Immutable, write-once, append-only, access-restricted, independently retained, signed, hashed, or separation-controlled storage for selected records | Supports tamper-resistance review; does not prove the original event was captured. |
| Retention-change approval record | Governance or evidence owner | Before changing retention, deletion, export, or custody rules | Requested change, affected records, approver, reason, risk acceptance, and rollback or migration plan | Supports change governance; does not prove old records remain complete. |
| Authoritative-record gap register | Evidence or audit owner | During Level 3 review and after provider, product, or boundary changes | Logs retained outside the assessed boundary, provider-retained records, non-exportable logs, local-only traces, missing integrity controls, and compensating evidence | Documents limitations; does not make outside-boundary records controlled. |
AWOSS-LOG-L3-002: High-Impact Workflow Reconstruction Test Level 3
Requirement summary
Test whether reviewers can reconstruct a sampled high-impact workflow from records, approvals, policy outcomes, source or configuration state, sensitive-data handling records, and evidence artifacts.
Why it exists
Separate logs can look adequate until someone tries to use them together. A reconstruction test checks whether a reviewer can build a timeline from the user request through agent runtime, tool or connector action, approval decision, policy outcome, source or configuration state, sensitive-data handling, downstream effect, validation evidence, and monitoring or incident record where applicable.
Why this level
This belongs at Level 3 because it tests the evidence chain, not just the existence of logs. It is especially important for high-impact, connector heavy, multimodal, production-writing, sensitive-data, or incident-relevant workflows.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Reconstruction test result | Evidence or audit owner with runtime, security, and data owner input | Before Level 3-style reliance, after material changes, and during periodic sampling | A sampled high-impact workflow timeline with records, approvals, policy decisions, source/config state, sensitive-data handling, downstream effects, and missing fields | Demonstrates one sampled reconstruction; does not prove every workflow is reconstructable. |
| Missing-field remediation record | Evidence or runtime owner | After reconstruction testing | Missing receipt fields, broken joins, redaction problems, non-exportable logs, attribution gaps, and assigned remediation tasks | Supports improvement; does not prove remediation is complete until retested. |
| Protected-material escalation path | Evidence, security, or legal owner where applicable | During reconstruction test design and after review | How reviewers can request protected originals when a redacted packet is insufficient, including access controls and approval criteria | Supports deeper review when needed; does not authorize broad disclosure of sensitive content. |
AWOSS-LOG-L3-003: Tamper-Evident Logging And Monitoring Linkage Level 3
Requirement summary
Use tamper-evident, independently retained, write-once, or separation-controlled logging for high-impact environments where feasible. Map critical log sources to monitoring, incident, or alert review where applicable.
Why it exists
Some agent events should not only be retained for later review. Denied high-impact actions, approval anomalies, source drift, redaction failures, context-boundary violations, retention changes, policy changes, and incident indicators may need routing into monitoring or incident review. Stronger retention also helps prevent one actor from quietly changing the story after a serious event.
Why this level
This belongs at Level 3 because it adds stronger custody and operational linkage. The standard keeps the language flexible because not every environment can use the same SIEM, object-lock, audit-log, or monitoring pattern, but high-impact workflows should show what critical signals are protected and reviewed.
Evidence examples
| Evidence | Likely owner/provider | When collected | What it should show | Claim limit |
|---|---|---|---|---|
| Tamper-evidence or independent-retention evidence | Security, platform, or evidence owner | Before high-impact use and during periodic review | Write-once retention, signed bundles, append-only logs, independent evidence custody, object or bucket lock, digest validation, or separation-controlled storage where feasible | Supports stored-record integrity; does not prove record completeness. |
| Monitoring and incident linkage map | Security operations, incident response, or evidence owner | Before high-impact use and after event taxonomy, tool, connector, or policy changes | Critical event classes, queries, alert rules, owners, escalation paths, incident ticket links, and sample results | Supports monitoring coverage review; does not prove all agent-specific risks are detected. |
| Alert or incident sample | Security operations or incident owner | During monitoring review, tabletop, or actual incident handling | A denied action, approval anomaly, source change, redaction failure, trace gap, policy change, or high-impact event routed to review | Supports operational linkage; does not prove alert tuning is complete or low-noise. |
External Mapping Notes
The completed crosswalk treats AWOSS-LOG as a candidate-control family shaped by retained logs, disclosure events, incident escalation, tamper-evident action receipts, policy decision logs, interaction metadata, action-chain audit records, evidence packets, observability, provenance, monitoring, and AI-incident detection signals.
Relevant external-source signals include:
- EU AI Act official sources inform logging, monitoring, disclosure, and incident-escalation evidence angles, but
AWOSS-LOGdoes not by itself prove Article 26, Article 50, high-risk-system, transparency, GDPR, or other legal compliance. - CSA AARM informs runtime action receipts and policy-decision records where a real runtime emits those artifacts, but
AWOSS-LOGdoes not imply AARM conformance. - OWASP AISVS informs interaction metadata, policy/safety logs, and action-chain audit records, but public AISVS material does not define the full
awossretention or receipt semantics. - AIUC-1 is useful as a commercial evidence-model comparator, including log extracts, review packets, and testing records, but there is no AIUC-1 certificate equivalence.
- CSA MAESTRO, NIST AI 600-1, Five Eyes agentic AI adoption guidance, and MITRE ATLAS inform observability, provenance, incident, monitoring, behavior-audit, and detection-mapping angles, but they do not create an
awoss-specific required log format or certification path. - ISO/IEC 42001 informs management-system records, review minutes, traceability, and transparency evidence at a governance level, but
AWOSS-LOGdoes not imply ISO/IEC 42001 certification.
Formal Standard Link
Use this guide with the formal AWOSS-LOG candidate requirements. If the guide and the standard draft disagree, the standard draft controls.