Enterprise auditing does not require centrally storing every conversation and source file. The objective is to understand who worked on which project, under what authority, and how security controls were applied.
BatonX’s logging approach separates the operational and security metadata needed for this purpose from the content processed during development.
What is recorded by default?
For relevant operations and supported integrations, BatonX’s audit design aims to record:
- Session information: User, organisation, project and repository identifiers; session start, end and status.
- Policy decisions: The applied policy version, evaluated operation, allow or deny decision, and a reason code.
- Approval events: The approval request, associated operation reference, decision-maker and decision time.
- Runtime events: Operation type, permitted or blocked access attempts, and execution outcome where available.
- Model usage: Provider and model identifiers, request reference, latency, available token usage and cost where it can be calculated.
- Administrative changes: Who changed permissions, policies or configuration, and when.
These records help connect related events within a session without copying their content. Each record is limited to what the reporting component can observe: a model’s proposed action is not evidence that the action actually occurred.
Content not centrally retained by default
The default scope of BatonX’s central audit records excludes:
- Full source-file contents and repository copies.
- Complete user prompts and conversation history.
- Full model responses.
- Complete tool inputs and outputs.
- Terminal output, test logs and full file-change diffs.
- API keys, access tokens, passwords and other secrets.
Raw command lines can also contain sensitive arguments. Recording an operation’s type and outcome is therefore different from retaining its full command text.
What can an audit record tell you?
For example, a record could show:
“A developer’s attempt to access a location outside the workspace during a particular session was blocked by the applicable repository policy.”
Explaining this event does not require retaining the target file’s contents, the complete user prompt or the model’s response.
Similarly, a model usage record can identify the destination model, request duration and reported token usage without containing the conversation itself.
Separate central retention from processing
“Not centrally retained” does not mean content is never processed or stored anywhere.
To perform a task, the agent may need to read authorised source files and send selected context to an approved model endpoint. The local workspace, agent session files, chat history and model provider’s records have separate data lifecycles.
BatonX’s audit policy should therefore be considered alongside local agent settings, Web Chat history, backups and provider retention terms. An audit setting does not automatically change how other components retain information.
Metadata also needs protection
User identifiers, repository names, file paths and error messages can contain sensitive information.
BatonX’s approach is to retain only necessary audit fields and use redaction, safe references and standard outcome codes where appropriate. Access permissions and retention periods should reflect the purpose of the records.
A hash used to track file integrity does not, by itself, establish the file’s contents or prove that a change is correct.
When more detailed recording is needed
Content-bearing diagnostic recording, where offered as a supported capability, should require separate authorisation and explicit configuration.
Define what will be retained, why it is needed, who can access it and how long it will remain available. Detailed recording must not become a blanket exception that permits secrets to be logged.
Exact event fields and retention behaviour should be verified for the deployed version and configuration.