Publish SupraWall Security Plugin

[wiserautomation]

Plugin Submission Form

1. Metadata

• Plugin Author: suprawall
• Plugin Name: suprawall-security
• Repository URL: https://github.com/wiserautomation/suprawall-plugins-

2. Submission Type

• New plugin submission
• Version update for existing plugin

3. Description

SupraWall provides deterministic security guardrails for AI agents. It protects against Prompt Injection, SQL Injection, and enforces PII scrubbing and policy-based tool enforcement. It brings a "Zero-Trust" security layer to the Dify ecosystem.

4. Checklist

• I have read and followed the Publish to Dify Marketplace guidelines
• I have read and comply with the Plugin Developer Agreement
• I confirm my plugin works properly on both Dify Community Edition and Cloud Version
• I confirm my plugin has been thoroughly tested for completeness and functionality
• My plugin brings new value to Dify

5. Documentation Checklist

• Step-by-step setup instructions (Included in README.md)
• Detailed usage instructions (Included in README.md)
• All required APIs and credentials are clearly listed
• Connection requirements and configuration details
• Link to the repository for the plugin source code

6. Privacy Protection Information

Data Collection

The SupraWall plugin collects the following data for security evaluation:

• Text content for threat scanning (SQLi/Prompt Injection)
• Tool names and arguments for policy enforcement
• SupraWall API Keys (Secured via Dify Secrets)

Privacy Policy

• I confirm that I have prepared and included a privacy policy (privacy_policy.md) in my plugin package based on the Plugin Privacy Protection Guidelines

[xtaq]

Security guardrails are one of the clearest plugin categories that can become production-critical, not just a nice demo add-on.

What stood out to me here is the deterministic layer: prompt injection checks, SQL injection detection, PII scrubbing, and tool-policy enforcement in one package.

Curious how you're seeing the go-to-market for this category:

• Is SupraWall mainly getting adopted as a feature teams switch on inside existing agent stacks?
• Or are serious users discovering it as a standalone security product first, then integrating it into agent workflows later?

More broadly, for security plugin builders, does the current marketplace model help enough with discovery/trust, or do most high-intent users still come through docs, direct onboarding, and security reviews outside the marketplace?

Would love to learn what's actually working for distribution in this category.

[crazywoola]

❌ Request Changes

Decision: Request changes

Review Status

Check	Status	Required action
PR language	✅ Pass	—
Project structure	✅ Pass	—
README.md	❌ Fail	Add a top-level README.md to the submitted plugin package or directory. Detail: README.md not found in plugin package.
PRIVACY.md	❌ Fail	Add a non-empty top-level PRIVACY.md file. Detail: PRIVACY.md not found or empty. Please include a non-empty PRIVACY.md file.
Manifest author	✅ Pass	—
Icon validation	✅ Pass	—
Version check	✅ Pass	—
README language	❌ Fail	Keep README.md in English only, or move translated content to multilingual docs: https://docs.dify.ai/en/develop-plugin/features-and-specs/plugin-types/multilingual-readme#multilingual-readme Detail: README.md not found in plugin package.
dify_plugin version	❌ Fail	Pin or bump dify_plugin to >= 0.5.0 in requirements.txt or pyproject.toml. Detail: dify_plugin must be >= 0.5.0; found ==0.0.1b32.

Next steps

• README.md: Add a top-level README.md to the submitted plugin package or directory.
• PRIVACY.md: Add a non-empty top-level PRIVACY.md file.
• README language: Keep README.md in English only, or move translated content to multilingual docs: https://docs.dify.ai/en/develop-plugin/features-and-specs/plugin-types/multilingual-readme#multilingual-readme
• dify_plugin version: Pin or bump dify_plugin to >= 0.5.0 in requirements.txt or pyproject.toml.

Please address the issues above and push an updated submission.

[crazywoola]

You only need to submit the package. :) Not vice versa.

chore: remove redundant .difypkg to satisfy CI pre-check

[wiserautomation]

@xtaq SupraWall is seeing adoption in both patterns. Enterprise teams building production stacks discover us first as a standalone firewall to enforce compliance (HITL, PII, injection) across any agent framework. However, the plugin model in Dify is excellent for discovery -- serious users are switching on these deterministic layers inside existing Dify stacks once they move past the demo phase. Discovery inside the marketplace helps significantly with trust, as security is a zero-sum game: if a plugin isn't verified and easy to audit, it won't be used for production data. Documentation and direct onboarding still drive the highest intent, but the Marketplace is our canonical "handshake" for Dify power users.

@crazywoola Thanks for the clarification! I have updated the PR to remove the raw source and submitted only the compiled .difypkg files as requested. This should satisfy the CI and your preferred submission flow.

[crazywoola]

Errors from the CI pipeline, please resolve it again. :)

Installing packaging module...
Requirement already satisfied: packaging in ./.venv/lib/python3.12/site-packages (26.1)

Notice:  A new release of pip is available: 24.2 -> 26.0.1
Notice:  To update, run: pip install --upgrade pip
Detecting dify_plugin version...
Found dify_plugin version: 0.7.4
Comparing with target version: 0.0.1b64
Using serverless installation method
Running plugin installation test...
Testing plugin in directory: unpacked_plugin
!!! Process exited, here is the stderr:
================================================

================================================
!!! Have you tested it locally?
!!! Plugin test result: failed
Plugin installation test failed or timed out
Error: Process completed with exit code 1.