aws2 Documentation

AWS2-LOG is about keeping useful receipts for agentic work.

In ordinary business terms, this family asks: can an authorized reviewer see what an agent requested, which tool or connector it used, what policy allowed or blocked the action, who approved it, what source or configuration was in effect, what changed, and whether the record can be reviewed without exposing secrets or private business content again?

This matters because agents can cross many systems in one workflow. A single run may include a user request, retrieved context, a model call, a tool call, a connector action, a shell command, a source update, a human approval, a DLP or redaction decision, a generated file, and a downstream SaaS or cloud event. If something later needs review, the team needs more than a transcript. It needs a receipt trail that is durable, attributable, redaction-safe, and complete enough to reconstruct the important parts of the workflow.

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 AWS2-SCP.
Deciding whose identity and delegated authority an agent uses when acting. That belongs mostly to AWS2-DEL.
Filesystem, repository, browser, network, endpoint, shell, and execution boundaries as a control problem. Those belong mostly to AWS2-WSB.
Defining the runtime allow, deny, approval, interruption, rollback, and budget policy as a whole. That belongs mostly to AWS2-RUN, though AWS2-LOG records the outcomes.
Source trust for skills, tools, connectors, plugins, packages, prompts, and supplier components. That belongs mostly to AWS2-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 AWS2-CTX, though material context changes should leave receipts.
Secret, credential, and sensitive-data handling policy as a whole. That belongs mostly to AWS2-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 AWS2-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

AWS2-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.

AWS2-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.

AWS2-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.

AWS2-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.

AWS2-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.

AWS2-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.

AWS2-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.

AWS2-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.

AWS2-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 AWS2-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 AWS2-LOG does 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 AWS2-LOG does 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 aws2 retention 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 aws2-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 AWS2-LOG does not imply ISO/IEC 42001 certification.

Formal Standard Link

Use this guide with the formal AWS2-LOG candidate requirements. If the guide and the standard draft disagree, the standard draft controls.