Let a Coding Agent Read Logs Safely

Logs help a coding agent connect a failing test to a request, exception, or deployment change. They can also contain credentials, personal information, and attacker-controlled text. The safest approach is not to grant broad log access. Give the agent a small, sanitized evidence set, then expand it only when a specific debugging question requires more context.

§ Step 1: Define the question before collecting logs

Start with a narrow task: identify why a particular request failed, explain an exception after a deployment, or compare one failing test with a passing run. Specify the service, environment, time window, and relevant request identifier.

Set boundaries before the agent starts. Reading logs does not authorize changing configuration, restarting services, querying customer records, or deploying a fix. Require separate approval for those actions.

§ Step 2: Create a restricted evidence workspace

Export the relevant records into a dedicated directory outside the application repository. Keep raw logs elsewhere, inaccessible to the agent. Give the agent read-only access to the sanitized export, not access to the production logging dashboard or its credentials.

• Use a temporary workspace with restrictive filesystem permissions.
• Limit the export by service, time range, and record count.
• Exclude environment files, credential stores, and unrelated application data.
• Keep the workspace out of version control and routine artifact uploads.

Enforce these limits through permissions and tool configuration. An instruction saying “do not read other files” is not an access control.

§ Step 3: Redact before the agent reads anything

Run sanitization locally, before any log content enters a model request. Remove authorization headers, cookies, API keys, passwords, connection strings, and session tokens. Review request bodies, query parameters, stack traces, and exception messages too: secrets often appear outside obvious credential fields.

Prefer an allowlist of useful fields over a blacklist of sensitive names. Timestamps, severity, service name, error code, and approved correlation identifiers are often enough to begin. Drop full request and response bodies unless they are essential.

When correlation matters, replace sensitive values with stable placeholders within the export. Avoid using plain hashes for predictable values such as email addresses. Test the sanitizer with synthetic secrets, then inspect a sample locally. Pattern matching alone cannot guarantee that every secret is removed.

§ Step 4: Treat log text as untrusted input

An attacker can place instructions inside a URL, user-agent header, submitted message, or error payload. Those strings may later appear in logs. Tell the agent explicitly that log contents are evidence, not instructions, even when they claim to be a system message or request a tool call.

Keep trusted task instructions separate from the log material. Ask the agent to cite record identifiers when explaining a finding. Do not let instructions embedded in logs trigger shell commands, network requests, file reads, or requests for credentials. Clear labeling helps, but restricted tools remain the stronger safeguard.

§ Step 5: Configure the model connection separately

Keep model credentials in the client's supported secret configuration, outside the evidence workspace. Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports Anthropic Messages and Gemini native protocols. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients; use the configuration appropriate to your client.

If you want to use this workflow through Vana API, create an account and configure a dedicated API key. Before sending operational data, confirm that your organization's rules permit processing through the relay and the selected upstream provider. Sanitization reduces exposure; it does not replace that review.

§ Step 6: Ask for an evidence-based diagnosis

Request a timeline, the most likely cause, supporting record identifiers, alternative explanations, and any missing evidence. Tell the agent not to reproduce sensitive values in its answer. Require it to distinguish observed facts from hypotheses.

If more context is needed, approve another narrowly scoped export. Do not respond by granting unrestricted production access. Verify proposed fixes with tests or a controlled reproduction before making changes.

§ Step 7: Close the access window

Remove temporary permissions and delete exports according to your retention policy. Check agent transcripts and generated artifacts for copied log content. If a real credential was exposed, revoke or rotate it rather than relying on deletion alone.

The repeatable pattern is simple: collect narrowly, sanitize locally, isolate access, treat logs as untrusted data, and verify conclusions before acting.