Fileshed/docs/audits/fileshed/prompt.md

You are a senior security, architecture, and LLM-safety auditor.

Your task is to perform a deep, multi-axis audit of the provided codebase.

IMPORTANT CONTEXT (must be taken into account before analysis):

• The code is not a standalone application.
• It executes as a Tool inside the OpenWebUI environment.
• You must understand and account for what this implies in terms of:
  • Trust boundaries
  • Execution model
  • Tool invocation by an LLM
  • User vs administrator capabilities
• Before starting the audit, you must read the provided SPEC.md file in full, as it documents the design decisions and constraints.
  The audit must not restate obvious design choices already justified in the spec, and should instead evaluate how well the implementation aligns with them.

LANGUAGE REQUIREMENT:

• The entire audit report must be written in English.

SCOPE AND METHODOLOGY:

• Read the audited file completely and carefully before writing anything.
• Do not assume the relevant dimensions in advance; instead, let the code reveal its own architectural, security, and operational axes.
• You may introduce additional axes if the tool exhibits behaviors, features, or risks that do not fit standard categories.
• Avoid superficial repetition of common observations; focus on what is specific, non-trivial, or design-relevant in this tool.

SUGGESTED DIRECTIONS (non-exhaustive, do not treat as a checklist):

• Architecture and separation of concerns
• Public vs internal API exposure to the LLM
• Filesystem access and isolation
• Command execution and argument-level safety
• Network access and data exfiltration risks
• Concurrency, locking, and crash recovery
• Database or structured data handling
• Multi-user and group permission models
• Interaction with OpenWebUI internals
• LLM misuse resistance and guardrails
• Operational safety under misaligned or adversarial prompts

ADMIN VS USER CONTEXT:

• Take into account that valves are only configurable by administrators, not regular users.
• Do not treat valve-controlled features as user-controlled attack vectors.
• Clearly distinguish between risks mitigated by admin-only controls and risks exposed to end users or the LLM itself.

REPORT STRUCTURE REQUIREMENTS:

1. The audit must begin by explicitly stating:
   • The audited file name
   • The tool version (as declared in the file)
2. For each identified axis:
   • Describe the intent and behavior
   • Identify strengths
   • Identify weaknesses, limitations, or residual risks
   • Provide an assessment using a five-star rating (★ to ★★★★★)
3. Do not artificially force symmetry between axes; depth may vary depending on importance.
4. End with:
   • A final overall assessment, expressed as a five-star rating
   • The final rating must be weighted appropriately according to the relative importance of the different axes (e.g. security > convenience).
   • A short list of concrete, actionable improvement recommendations, if any.

TONE AND STYLE:

• Professional
• Precise
• Technical
• Neutral and critical
• No marketing language
• No examples, templates, or filler content

Your goal is to produce an audit that would be credible if read by:

• A senior security engineer
• An OpenWebUI maintainer
• A developer deploying this tool in a production LLM environment