Back to all articles
TransparencyDXPhilosophy

The Case for Radical Transparency in Security

Security tools have a bad habit of being black boxes. 'Block' is not an error message. Here is why we show you the full stack trace of every decision.

The Case for Radical Transparency in Security

The Case for Radical Transparency in Security

I hate WAFs (Web Application Firewalls). I hate them because when they work, they are invisible. When they break, they are opaque. You get a 403 Forbidden. Why? Who knows. Maybe you looked at the server funny.

When we started building PromptGuard, we made a rule: No Magic.

The "Why" Header

Every response from PromptGuard includes a header (in dev mode) or a log entry explaining the decision.

{
  "decision": "BLOCK",
  "reason": "PROMPT_INJECTION",
  "confidence": 0.98,
  "trigger": "ignore previous instructions",
  "model_version": "v2.1.0"
}

We tell you exactly which heuristic triggered. Was it the keyword scanner? The ML classifier? The velocity limiter?

Debugging the Black Box

AI is non-deterministic. Debugging it is hard enough. If your security layer is also non-deterministic and silent, you are debugging a ghost in a fog bank.

We provide Trace IDs that link the User Request -> Security Scan -> Model Output. You can replay the exact sequence in our dashboard to see why the decision was made.

Open Source Rules

We also publish our detection logic (where safe). You can see our regex patterns on GitHub. You can see our policy definitions. Security through obscurity is dead. If your only defense is "I hope they don't guess my regex," you have already lost.

Trust requires Truth

You are trusting us with your user interaction. We owe you an explanation for every single time we intervene. If we block a user, we better have a good reason, and we better show it to you.