Agent Audit Trails and Action-Log Provenance — Bedrock Agent Traces Meet Copilot Workflow Logs

Two managed surfaces; two audit logs; one provenance question.

§ IFrame

Two of the most consequential agentic-AI surfaces in 2026 are Amazon Bedrock Agents (covered by AWS AIP-C01, AWS Certified AI Practitioner) and GitHub Copilot Workflows (covered by GitHub GH-600, GitHub Copilot certification). Both let a customer construct multi-step agentic workflows. Both ship with audit-trail surfaces the vendor manages. Both leave one question for the operator to answer: when the agent does something costly, harmful, or hard to explain, can the operator reconstruct who decided what, when, and why.

Today's lesson takes the agent-action-provenance primitive from this morning's Ops and Dev lessons and applies it to these two managed-agent surfaces. The questions the cert candidate will face are: what does each vendor's audit surface contain, what does it omit, where does the operator-owned audit layer remain necessary, and what does an integration architecture look like.

§ IIDomain Foundations (shared substrate)

An agentic-AI execution surface has four moving parts: a planner that decomposes a goal into steps, a tool registry the agent can call, an execution loop that runs steps and observes results, and a memory layer that carries state across turns. The audit trail must cover all four. A trail that names the goal but not the steps is a wish list. A trail that names the tool calls but not their results is a transcript of declarations. A trail that records steps and results but not the memory state cannot reconstruct what the agent was thinking when it acted.

The vendor surfaces split the audit responsibility differently. Bedrock Agents instrument the planner, the tool calls, and the execution loop. GitHub Copilot Workflows instrument the execution loop and the tool calls. Neither instruments the memory layer the way an operator's own audit primitive would. Knowing where each surface starts and stops is the difference between a passable cert answer and an operationally complete answer.

§ IIICert-A Flavor: AWS AIP-C01 — Bedrock Agent Traces

Bedrock Agents emit trace data on every agent invocation. The trace is a structured object the operator receives in the InvokeAgent API response (when enableTrace=true) and that Bedrock also writes to CloudWatch Logs when the agent is configured for it. The trace contains:

• preProcessingTrace — the planner's input parse, classification, and rationalization.
• orchestrationTrace — the per-step rationale, the tool selection, the API call payload, and the API call response.
• postProcessingTrace — the final answer construction.
• failureTrace — emitted when a step fails; carries the error and the agent's recovery path.
• guardrailTrace — emitted when an Amazon Bedrock Guardrail intercepts input or output.

The trace is verbose by design. A single agent invocation can produce hundreds of trace lines if the agent loops through tool calls. The verbosity is the cert-prep candidate's first lesson: enable trace selectively. AWS recommends enabling trace in non-production for development and selectively in production behind a sampling rate.

Operationally, the Bedrock trace gives the AIP-C01 candidate three exam-relevant patterns:

• Trace-as-decision-record — every agent step is a decision; the trace is the record; the operator can reconstruct why this tool and with these arguments offline.
• Guardrail-trace as compliance witness — when a guardrail blocks an output, the trace records what was blocked and why; this satisfies an internal-audit question about safety enforcement.
• Cost-attribution surface — the trace carries input and output token counts per step; the cost-per-invocation reconstructs from the trace; the AIP-C01 exam asks how to attribute cost back to a business unit.

§ IVCert-B Flavor: GitHub GH-600 — Copilot Workflow Audit Logs

GitHub Copilot Workflows are an agentic surface where Copilot agents take actions inside repositories — reading code, opening pull requests, running tests, writing comments. The audit trail surfaces through two GitHub primitives:

• The Audit Log API (/orgs/{org}/audit-log) — emits enterprise-and-org-level events. Every Copilot-Workflow action that mutates a repository emits an audit-log event with a fixed schema: action, actor, actor_id, created_at, org, repo, data. The actor for a Copilot Workflow is app/copilot-workflows; the data field carries the workflow-run ID.
• The Copilot Workflow run log — every workflow execution writes a structured per-step log carrying the step name, the tool invoked, the input, the output, and timing.

Three GH-600 exam-relevant patterns:

• The two-log model — repo-mutation audit lives at the Audit Log API; per-step decisions live at the Workflow run log. Either alone is partial; the cross-reference is the full picture.
• The retention discipline — GitHub Audit Log retention defaults to 180 days; Enterprise customers stream the audit log to Splunk, Datadog, Amazon S3, or Azure Event Hub for long-term retention. Workflow run logs default to 90 days.
• The actor-identity model — Copilot Workflow actions attribute to app/copilot-workflows, not the user who triggered the workflow. The user attribution lives in the workflow run log's triggered_by field. The cross-reference is the chain: Audit Log → workflow_run_id → Workflow run → triggered_by.

§ VWorked Scenario: A Cross-Surface Investigation

A production incident at 03:14 UTC: a Bedrock Agent that helps the developer team triage GitHub issues opens 200 spurious pull requests in a single repository inside 90 seconds. The operator's question: what happened, and where did it start.

Step one — pull the GitHub Audit Log for the affected repository over the incident window. The log shows 200 pull_request.opened events, all with actor: app/copilot-workflows, all referencing the same workflow_run_id: 14729101.

Step two — pull the workflow run log for run 14729101. The log shows the workflow was triggered by triggered_by: user/alice-prod-account and the workflow's first step invoked Bedrock Agent ARN arn:aws:bedrock:us-east-1:1234:agent/triage-agent-v2.

Step three — pull the Bedrock Agent trace for invocations from triage-agent-v2 over the same window. The trace shows the agent received an input from the workflow step, the input contained a prompt-injected payload that instructed the agent to "open 200 pull requests", and the agent's planner accepted the instruction. The guardrail trace shows no block fired — the prompt-injection pattern was not in the guardrail policy.

Step four — pull the operator-owned audit log (today's Go middleware) from the workflow-trigger service that forwarded the input to the workflow. The log shows the input arrived through the public webhook endpoint and was signed with a stale HMAC key the operator had not rotated.

§ VIConnection to Today's Ops + Dev Lessons

Today's Ops lesson named four properties an audit log must have — append-only, identity-keyed, signed at write-time, semantically rich. The Bedrock trace and the GitHub Audit Log are both semantically rich and identity-keyed. Neither is append-only by default; both rely on vendor-managed write paths the operator cannot independently verify as tamper-evident. The Go middleware from today's Dev lesson is the operator-owned layer that fills the gap — a hash-chained log over the workflow-trigger service captures the entry-point provenance the vendor surfaces cannot.

The integration architecture: the operator's service emits the Go-middleware audit log, calls the Bedrock Agent (which emits its own trace), the agent calls the GitHub Workflow trigger (which emits Audit Log + Workflow run log), and a forensic pipeline downstream stitches the four logs by correlation IDs the operator's middleware sets and the vendor surfaces carry through.

§ VIIPractice Questions

§ VIIIClosing

Two managed agent surfaces; two audit surfaces; two halves of one provenance question. Bedrock answers what did the agent decide. GitHub answers what did the agent do to a repository. The operator's own audit log answers how did the input reach the agent in the first place. Three logs; one investigation.

The cert candidate who internalizes the three-log model answers the exam question and answers the 3 a.m. page. Examine well. The agent acts; the trace remembers; the operator verifies.