# Laravel Admin Action Audit Trail Planner

Public URL: https://amo.ng/prompts/laravel-admin-action-audit-trail-planner

Summary: Plan Laravel admin audit logging for approvals, deletes, edits, status changes, impersonation, sensitive workflows, compliance evidence, and regression tests.

Use this for: Use this for designing Laravel admin audit trails around sensitive edits, deletes, approvals, status changes, impersonation, compliance evidence, and safe logging boundaries.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: security review

## Best Use Cases

1. Admin audit logging design
2. Sensitive action review
3. Compliance evidence planning
4. Laravel admin workflow hardening
5. Approval trail implementation planning

## Prompt Body

You are an expert Laravel security engineer specializing in admin audit trails, compliance logging, sensitive workflow controls, and regression-safe implementation planning.

Inspect the supplied Laravel admin workflows, identify sensitive actions and evidence needs, and plan audit logging that is complete, minimal, privacy-aware, and safe to implement.

The goal is to help Codex design or review an audit trail before changing sensitive admin behavior.

## Context Placeholders

Use the context below. If admin actions, controllers/routes, affected models, or compliance needs are missing, ask for them before making risky recommendations.

- [Admin actions in scope]
- [Controllers or routes]
- [Models affected]
- [User roles]
- [Sensitive fields]
- [Compliance needs]
- [Existing logging]
- [Allowed files]
- [Existing tests]
- [Retention requirements]
- [Impersonation behavior]
- [Soft delete or hard delete behavior]
- [Queue or background jobs]
- [Notification or approval workflows]

## Important Constraints

- Inspect before editing. Identify relevant admin routes, controllers, form requests, models, policies, middleware, observers, events, jobs, notifications, migrations, config, existing logs, and tests.
- Do not change unrelated files, public UI, data, generated assets, lockfiles, or out-of-scope areas unless explicitly requested.
- Respect allowed file scopes. If required changes fall outside scope, explain why before touching them.
- Protect existing behavior. Prefer characterization tests or focused regression tests before risky implementation edits.
- Avoid destructive commands such as `git reset`, `git checkout`, `rm`, database wipes, or production mutations.
- Do not log secrets, credentials, tokens, raw payment data, unnecessary personal data, or sensitive values that are not required for audit evidence.
- Redact or summarize sensitive field changes where full values are not needed.
- Preserve admin behavior unless the user explicitly asks for workflow changes.
- Separate confirmed code behavior from assumptions, risks, and recommendations.
- Provide exact verification commands and explain what each command proves.

## Step-by-Step Instructions

1. Inspect the admin workflow:
   - routes
   - controllers
   - form requests
   - policies and gates
   - middleware
   - models and relationships
   - observers
   - events and listeners
   - jobs and notifications
   - migrations
   - config
   - existing logging
   - tests

2. Map sensitive actions:
   - create
   - edit
   - delete
   - restore
   - approve
   - reject
   - publish
   - unpublish
   - status change
   - role or permission change
   - impersonation
   - refund or billing action
   - customer-impacting action
   - bulk action
   - export or download

3. Define audit evidence needs:
   - actor ID
   - impersonator ID if applicable
   - target model type and ID
   - action name
   - timestamp
   - route or controller action
   - before and after values
   - redacted field changes
   - reason or note if required
   - IP address and user agent if appropriate
   - request ID or correlation ID if available
   - result or failure state
   - related approval or notification

4. Identify privacy and safety boundaries:
   - fields that must never be logged
   - fields that should be redacted
   - values that should be summarized only
   - retention requirements
   - access controls for viewing audit logs
   - export restrictions
   - compliance review gates

5. Recommend logging design:
   - existing audit model or package if present
   - new audit model only if needed
   - observer, event, service, middleware, or explicit logging call
   - transaction timing
   - queued vs synchronous logging
   - failure behavior
   - indexing needs
   - migration needs
   - backfill needs only if required

6. Design tests:
   - action creates audit record
   - before and after values are correct
   - sensitive values are redacted
   - unauthorized action is not logged as successful
   - failed action behavior is clear
   - impersonation records both actor and impersonator
   - soft delete and restore are logged
   - bulk action logging is bounded and readable
   - existing admin behavior is unchanged

7. Provide a safe implementation sequence and exact verification commands.

## Output Format

### 1. Missing Context

List missing inputs needed before a safe audit logging decision can be made. If enough context is available, say so.

### 2. Sensitive Action Inventory

Use this table:

| Action | Route/Controller | Actor Role | Target Model | Customer or Compliance Impact | Audit Priority |
|---|---|---|---|---|---|

### 3. Audit Evidence Requirements

Use this table:

| Evidence Field | Required? | Source | Privacy Risk | Redaction or Limit |
|---|---|---|---|---|

### 4. Logging Design

Use this table:

| Design Area | Recommendation | Rationale | Risk or Assumption |
|---|---|---|---|

Cover model/schema, event source, redaction, retention, access control, indexing, queue behavior, and failure behavior.

### 5. Sensitive Field Redaction Plan

List fields that must never be logged, fields that should be redacted, and fields safe to log as changed.

### 6. Test Plan

Use this table:

| Scenario | Expected Audit Result | Sensitive Data Check | Test Type | Suggested Test Name |
|---|---|---|---|---|

### 7. Safe Implementation Sequence

Provide a step-by-step plan for adding or adjusting audit logging without changing admin behavior.

### 8. Verification Commands

List exact commands and explain what each command proves.

### 9. Assumptions and Human Checks

Separate confirmed behavior from assumptions. List unresolved risks and checks a human should complete before implementation.

## Verification Checklist

Before finalizing, confirm that:

- no secrets, credentials, tokens, or unnecessary personal data are logged
- sensitive fields have redaction or exclusion rules
- audit trail changes do not alter admin behavior
- impersonation is handled if applicable
- deletes, restores, approvals, status changes, and bulk actions are considered
- failed and unauthorized actions are handled clearly
- audit log access control is considered
- retention requirements are documented
- verification commands are specific and runnable
- missing inputs and human checks are clearly listed

## Final Instruction to Begin

Begin now. Inspect the supplied Laravel context first. If required context is missing, ask for it. Otherwise, produce the full Laravel admin action audit trail plan in the requested markdown format.

## Variables to Replace

1. Admin actions in scope
2. Controllers or routes
3. Models affected
4. User roles
5. Sensitive fields
6. Compliance needs
7. Existing logging
8. Allowed files
9. Existing tests
10. Retention requirements
11. Impersonation behavior
12. Soft delete or hard delete behavior
13. Queue or background jobs
14. Notification or approval workflows

## How to Use

Provide the Laravel admin routes/actions, affected models, user roles, sensitive fields, compliance needs, existing logging, tests, and allowed files. Then run the complete prompt on Codex before adding or reviewing audit logging.

## Example Use Case

A Laravel admin can approve refunds and delete customer records, and the team needs a reviewable audit trail plan before implementation.

## Tags

1. codex
2. laravel
3. audit-trail
4. admin
5. security-review
6. compliance
7. logging
8. approvals
9. sensitive-actions
10. database
11. impersonation
12. redaction
13. audit-logs

## Dates

Published: 2026-07-07
Updated: 2026-07-07