Log who started the session, which repository and branch it used, every tool call and command, network requests allowed and blocked, git operations, and the resulting pull request. Link the session record to the pull request so a reviewer can trace output to its run. Keep logs where the agent cannot edit them.
Why it matters
OWASP's guidance for excessive agency says logging and monitoring extension activity, with rate limiting, helps limit damage, though it does not prevent the issue. If a cloud agent does something unexpected while you are away, the log is how you reconstruct it.
Platforms already expose some of this. One documents that its firewall adds a warning to the pull request or a comment showing the blocked address and the command that made the request. Another gives each session a transcript URL and an environment variable carrying the session ID so you can put a traceable link in pull request bodies and commit messages, letting a reviewer open the run that produced a change. Use those hooks.
Fields worth keeping
| Group | Fields |
|---|---|
| Identity | Who requested the task, which agent identity ran it, which approver |
| Scope | Repository, base branch, task branch, environment name |
| Commands | Command text, working directory, exit code, duration |
| Tools | MCP server and tool name, arguments, result status |
| Network | Destination, method, allowed or blocked, bytes |
| Credentials | Which credential was used for which host, never the value |
| Git | Pushes, branch names, pull requests opened |
| Environment | Image version, setup script hash, runtime class |
| Outcome | Pull request link, checks run, who approved |
What not to log
- Secret values, tokens, or full request headers.
- Large response bodies that may contain customer data.
- Whole file contents when a hash will do.
OWASP's secrets guidance asks for audit logs that record who requested a secret, when it was used, and authentication or authorization errors, and that the logs be resilient to tampering or deletion. Ship logs out of the sandbox as they are written.
Make the logs useful
- Use one session ID across all records.
- Put the session link in the pull request description.
- Alert on blocked egress that repeats, new hosts, and access to unexpected repositories.
- Keep logs for as long as your review and audit needs require, which is a policy decision for you.
- Test the trail: pick a past agent pull request and try to answer who, what, where, and why from logs alone.
How logs help in review
A reviewer who sees a pull request that touched a workflow file can open the session and check which commands ran and which hosts were contacted. If the diff looks clean but the session shows an unexpected download, that is worth a pause.
Worked example: answering four questions from logs
An illustrative investigation. A pull request from an agent touched a build script. A reviewer wants to know whether anything unusual happened.
Who? The session record shows the agent identity, the person who requested the task, and the approver who released workflows.
What? The command list shows an install, a build, a test run, and a download of a helper tool from a host the reviewer does not recognize.
Where? The network log shows the download host as blocked on the first attempt, then allowed after the agent retried through a different path. That deserves attention.
Why? The tool call records show the agent read a file containing a comment telling it to fetch that helper for "faster builds."
With those four answers the reviewer can reject the change, remove the instruction from the file, and tighten the network rule. Without the logs, the pull request looks like a routine build tweak.
Event schema you can adopt
| Field | Example value | Why |
|---|---|---|
| session_id | Opaque ID | Joins all records |
| actor | Agent identity and requesting user | Attribution |
| repository | Name and branch | Scope |
| event_type | command, tool_call, network, git, approval | Filtering |
| timestamp | UTC time | Ordering |
| target | Host, tool, or path | Where it acted |
| decision | allowed, blocked, approved, rejected | Control outcome |
| detail | Command text or tool arguments, with secrets redacted | Reconstruction |
| outcome | Exit code or result status | Success or failure |
Keep it simple and consistent. A common schema across agents lets you write one alert rule instead of many.
Alerts worth writing
- A session with repeated blocked requests.
- A first ever destination for a given repository.
- A command that reads environment variables in bulk.
- A change to a workflow file in an agent pull request.
- A push attempt to a protected branch.
- A tool call outside the declared tool list.
Redaction and privacy
Command text and tool arguments can include sensitive values. Redact known patterns before storage and restrict access to the logs. Avoid storing raw response bodies unless needed. Consider whether personal data appears, and treat the logs as sensitive records in their own right.
Retention and integrity
Choose retention to match your review and audit needs, which is a policy decision. Write logs to storage the agent identity cannot modify, and consider append only or tamper evident storage so an incident does not erase the evidence. OWASP's guidance asks for auditing that is resilient to tampering or deletion, which fits this exactly.
Where Safeguard fits
Safeguard provides agent identity, MCP Guardrail, and compliance and evidence automation, which help attribute agent actions and collect evidence of controls.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and note which actions an assistant takes on your behalf, then ask whether your own logs would record each one.
Quick check
Should I log the model's reasoning text?
It can be useful but may hold sensitive content. Decide by sensitivity, and keep command and tool records either way.
Where should logs live?
Outside the sandbox, in storage the agent cannot modify.
How much of the session transcript should we keep?
Keep structured command, tool, network, and git events for as long as your review needs. Keep full transcripts for a shorter time if they hold sensitive content, and restrict who can read them.
Sources
- OWASP LLM06:2025 Excessive Agency
- OWASP Secrets Management Cheat Sheet
- Customize the Copilot cloud agent firewall (GitHub Docs)
- Configure cloud environments (Anthropic documentation)
Last reviewed: 19 October 2026.
