Introduction

In a web application that incorporates AI, text entered by the user (consultation content, questions, chat messages, etc.) is sent directly to the API, and the results are returned.
These “inputs” and “outputs” are the data most likely to contain personal information within the application.

However, if you increase logging for incident investigation, these inputs and outputs become more likely to be mixed in with the log entries. Conversely, if you reduce logging too much, it becomes impossible to determine what happened.

In this article, we explain how to keep the consultation content itself out of the logs while retaining only the information needed for troubleshooting, using Laravel’s actual configuration and code as the basis.

The Application Used as an Example

I will use “ZEN,” an AI consultation web application that I develop as a personal project. I will include only the necessary background so that it can be understood even if you are not familiar with it.

• When a user enters their concerns in a form, the AI (OpenAI API) returns a response
• Implemented in Laravel 13 / PHP 8.3
• The consultation text is referred to as “concern,” and the AI response as “answer”

In other words, it is a perfectly ordinary web application that passes the user’s free-form input to AI. The same approach applies as-is to any application with the same structure.

Today’s Learning Goals

1. Be able to explain the difference between APP_DEBUG and LOG_LEVEL
2. Understand how Laravel automatically records exceptions in the logs
3. Be able to record the information needed for incident investigation without saving the consultation content

1. APP_DEBUG and LOG_LEVEL Are Different Things

First, let us consider separately the three settings that are often confused. Laravel’s .env file contains lines such as the following.

Settings	Purpose	Basic policy for the production environment
APP_DEBUG	Whether to display error details on the user's screen	Always false
LOG_LEVEL	Which logs of a specified severity level or higher to save	Set according to operational requirements
LOG_CHANNEL	Log output destination (file, syslog, Slack, etc.)	Set according to the operating environment

APP_DEBUG concerns information shown to users, while LOG_LEVEL and LOG_CHANNEL concern information retained on the server side. Changing one does not affect the other.

Order of log levels

Laravel's log levels follow PSR-3 and are listed below in descending order of severity.

Level	Meaning
emergency	System is unavailable
alert	Immediate action is required
critical	Serious failure
error	An error has occurred
warning	Warning or a condition that should be noted
notice	An unusual but important condition
info	Routine operational information
debug	Information for development and detailed investigation

LOG_LEVEL records logs at the specified level and those with a higher severity.
For example, when LOG_LEVEL=warning is set, warning / error / critical … are recorded, while info and debug are not.

Also, Laravel's official documentation explicitly states that APP_DEBUG must always be set to false in production. If it remains true, environment variables and stack traces may be displayed on the error screen, potentially leaking sensitive information to end users.

2. Exceptions are logged even if you "do nothing"

This is the most important point this time.

Re-throwing with throw $exception causes the global handler to log it

ZEN's AI consultation processing includes the following catch. This is the processing used to return consumed credits when an AI call fails.

This code itself does not write a log.
However, when an exception is re-thrown with throw $exception, processing is passed to Laravel's global exception handler,and the exception is reported and logged according to the standard configuration.

In other words, the claim that "because I did not write a log myself, nothing will remain in the log" is incorrect.

report() works the same way

Code that calls report() as follows also logs the exception.

report() is the function to use when you want to "swallow the exception while still leaving it in the log."
bootstrap/app.php でカスタムの報告処理（Slack通知など）を追加しても、例外は引き続き標準ログに記録されます。特定の例外を報告対象から外したい場合は、dontReport() メソッドや ShouldntReport インターフェースを使います。

各対策にはそれぞれ異なる役割があります

ZENでは、相談文をログに残さないための対策を複数重ねています。似たように見えますが、それぞれ守っている場所が違います。

#[\SensitiveParameter] (PHP 8.2+) $exceptions->dontFlash(['concern'])

対策	守っている場所
zend.exception_ignore_args=1 (php.ini)	例外のスタックトレースに 関数の引数 を含めない
特定の引数だけをトレース上で SensitiveParameterValue に置き換える
バリデーションエラー時に相談文を セッションにフラッシュ しない
例外報告の制御（dontReport() など）	どの例外を どこに 記録するかを管理する

実際のコードでは、相談文を受け取る関数の引数に属性を付けています。

3. ログには「相談内容」ではなく「調査に必要な情報」を残す

Unsafe example

The consultation content, AI response, and API key are written to the log file as-is.

Because log files are copied to backups, log aggregation services, monitoring tools, and other destinations, once written, they are almost impossible to retrieve.

Safe example

Item	Purpose
request_id	Identifies which request the error occurred in
operation	Identifies which operation failed
exception_class	Identify the type of exception

With these three, you can track “when” the failure occurred, “which process” it occurred in, and “what type of error” it was.
There is no need to investigate what the user was asking about.

Automatically attach a request ID to all logs

ZEN provides middleware that issues a request ID and registers it in Laravel's Context. Values placed in the Context are automatically attached to every log entry during that request.

The same ID is also returned in the response headers, so when a user reports that an error has occurred, you can cross-reference the logs using only the ID displayed on the screen. There is no need to ask the user to describe the issue.

Logs themselves must also be protected

Laravel's standard exception handler automatically adds the logged-in user's ID to the exception log context when there is a logged-in user. This is useful for investigations, but it also means thatthe logs contain information that can identify an individual.

Log files also require access restrictions and management of their retention periods.

The OWASP Logging Cheat Sheet also categorizes these as follows:

• What should be logged: Successful and failed authentication, access control failures, application errors, input validation failures, etc.
• What should not be logged: Session IDs, access tokens, passwords, personal information, cryptographic keys, secret keys, etc.

4. Practical exercise: Check environment-specific settings in your own app

No code changes are needed. It is sufficient simply to understand how the settings differ between local and production environments.

Exercise A: Check the local settings

Run this from the project root.

PowerShell:

macOS / Linux:

If LOG_STACK is not output, the default value of single in config/logging.php will be used. In other words, the output destination is storage/logs/laravel.log.

Task B: Check the same settings on the production server

SSH into the production server and run the same grep command in the project directory.

Pay particular attention to the following two points:

• Whether APP_ENV=production
• Whether APP_DEBUG=false

Even in production, leaving LOG_LEVEL=debug does not itself immediately imply a data leak. However, it is worth considering whether it can reduce unnecessary detailed logs or, conversely, result in losing information necessary for operations.

Task C: Classify the information to be logged

Try classifying the information handled by your app as shown in the table below.

Information	Logging policy
Request ID	Record
AI model name	Record as needed
User's input body	Do not record
AI response body	Do not record
API key	Never record
Exception class name	Record as needed
Exception message	Handle carefully after checking for the inclusion of sensitive information
Processing time	Record as needed

The key point is that "Exception message" is marked as "Handle carefully."Exceptions thrown by external libraries may include part of the request body.

5. Review Questions

Question 1: What is the primary meaning of LOG_LEVEL=debug?

1. Display detailed errors to users
2. Record logs of all severity levels, including debug
3. Automatically remove personally identifiable information from logs

Correct answer

2

LOG_LEVEL determines the minimum severity of logs to record. Displaying information to users is handled by APP_DEBUG, which is a separate setting.

Question 2: Which combination is appropriate for troubleshooting issues without retaining the user's inquiry in the logs?

1. Record the inquiry body, AI response, and API key
2. Unconditionally record only the exception messages
3. Record the request ID, process name, exception class name, and similar information

Correct answer

3

This retains identifying information for tracing the processing rather than confidential data. Because input text may sometimes be mixed into exception messages through external libraries, recording exception messages "unconditionally" is dangerous.

Summary

• APP_DEBUG is the setting for "what to show users," while LOG_LEVEL is the setting for "what to retain on the server." They are separate settings.
throw $exception and report() are logged by the global handler even if you do not write logs yourself
• exception_ignore_args, #[\SensitiveParameter], and dontFlash() each protect a different area. None of them can prevent user input from being embedded in exception messages

Logs should record "what happened." There is no need to record "what the user inquired about"

References (Primary Sources)

• Laravel 13 — Error Handling: Reporting exceptions, log levels, and dontReport()
• Laravel 13 — Logging: Log channels and output configuration
• Laravel 13 — Context: A mechanism for adding common information to all logs
• PHP — zend.exception_ignore_args
• PHP — SensitiveParameter attribute
• OWASP — Logging Cheat Sheet: Secure log design, data that should be excluded, and log protection