Security automation should keep a record of every action it takes: which rule or person triggered it, what object it changed, the before and after values, the reason, the time, and the result. If a bot closes a ticket, you must be able to say why.
Why bots need their own trail
Humans leave traces in ticket history. A bot that acts under a shared account leaves traces that say "automation" and nothing more. When an auditor or a colleague asks why a finding was closed on a Tuesday night, "the integration did it" is not an answer.
Fields to record for each action
| Field | Example |
|---|---|
| Timestamp | Time in UTC, to the second |
| Actor | The automation identity, not a shared admin account |
| Trigger | Which rule, schedule or person started it |
| Action | Created ticket, changed status, opened pull request |
| Target | Ticket id, finding id, repository |
| Before and after | Old and new values of changed fields |
| Reason | The rule text or policy version that allowed it |
| Inputs | The event id or scan id that caused it |
| Outcome | Success, failure, skipped, with an error if any |
| Approver | A person, where the action needed approval |
The MCP specification, for tool based automation, says clients should log tool usage for audit purposes. The same principle applies to every integration: logging is something you decide to do, not something you get free.
Keep the log apart from the thing it describes
If the automation can edit its own log, it is weak evidence. Write to an append only store or a log service the automation cannot modify, and restrict who can delete entries.
Link to the policy version
Rules change. Record which version of a rule made the decision, so that a later reader can see the rule as it was. A short rule id and a change history is enough.
Retention and access
Keep records for as long as your audit and legal obligations need, and set that period deliberately. See how long to keep audit evidence. Limit access, because logs may contain repository names and finding details.
Test the trail
Pick a random closed ticket and try to answer: who or what closed it, why, and on what evidence. If you cannot, add the missing field.
Quick check
Is the ticket history enough as an audit trail?
Often not. It may show only a generic bot account. Keep a separate record with trigger, reason, rule version and outcome.
Why record before and after values?
They let you reverse a wrong change and show exactly what the automation altered.
Safeguard includes compliance and evidence automation and policies and gates, and a free scan is at gold.safeguard.sh/scan.
Sources
- Model Context Protocol, Tools specification
Last reviewed: 19 October 2026.
