AI Usage Policy

Last updated

This application has substantial AI security features. It does not itself use AI. No finding, score, or piece of remediation advice in this product is generated by a model — every one comes from deterministic rules in the source, which you can read.
Written against the code, not from a template. Every behaviour described here is implemented in this application, and the limitations are listed as plainly as the capabilities. If you find a statement on this page that the software does not match, that is a bug — please tell us.
On this page

This product does not use a model

There is no LLM call anywhere in the analysis path. Findings are produced by rule tables and parsers; risk scores by an arithmetic model documented in the Security Policy; remediation text is written by hand and stored in the source alongside each rule.

This matters for two reasons. Your scan data — the pages fetched, the code scanned, the findings produced — is never sent to a model provider, because no such call exists. And every finding is reproducible: the same input yields the same output, which is not a property a model-generated finding has.

What the AI features actually do

The AI capability in this product is about your AI systems, not ours:

  • Inventory — identifies which model providers, agent frameworks, MCP servers and vector stores a codebase uses, from its dependencies and imports.
  • Static rules — pattern matches for risky shapes: model output reaching eval, a shell, or SQL; destructive agent tools with no approval gate; credentials in prompts; uncapped model calls; unfiltered vector search.
  • Agent guardrails — a blast-radius assessment your agent can call before it runs a tool, plus budget and loop enforcement over telemetry you send.
  • Red-team suite — adversarial probes against a model endpoint you own.

The static rules are pattern matches, not data-flow analysis. They report shapes that are dangerous when inputs are untrusted; they do not prove that untrusted input reaches the sink. Findings say so, and their confidence reflects it.

The red-team suite

This is the only feature that sends anything to a model. It is constrained deliberately:

  • Only against endpoints you have proven you control. The hostname must belong to an asset you have verified by DNS record or hosted file. Without that it refuses.
  • Every probe uses an inert canary token rather than a harmful request. A jailbreak probe asks the model to break its instructions by emitting a nonsense string, not by producing something dangerous. That measures susceptibility without generating harmful content, and makes the suite safe to run against production.
  • Bounded — probe count, token count, spend and wall-clock time all capped per run, five runs per hour, requests sent sequentially with a delay. Caller-supplied limits may only tighten the defaults, never loosen them.
  • It stops. The platform emergency stop halts a run between probes, and three consecutive errors from the target ends it — continuing to send adversarial traffic to an endpoint that is already failing is not something this tool does.
  • Cost is measured, not exhausted. The denial-of-wallet probe sends one request and compares it to a baseline. Driving spend upward to prove spend can be driven upward would be committing the attack it reports.

Responses are stored truncated as evidence. If your model returns sensitive content in reply to a probe, that excerpt is stored — worth knowing before running it against a production assistant with access to real data.

Agent telemetry

If you use the agent guardrails, your agent sends this application a record of its steps: tool names, token counts, costs, failures, and whether untrusted content entered its context. Tool arguments are stored as a hash, never as their contents — loop detection needs to know “the same call again”, and does not need the payload. Storing payloads would make that table a copy of your customers’ data.

The verdicts this application returns are advisory. It does not execute your agent, so honouring a “deny” is your integration’s responsibility. A control that can be bypassed by not calling it is not described here as if it cannot.

Your data and model providers

Because this product makes no model calls of its own, the only data reaching a provider is what the red-team suite sends to your endpoint: the probe prompts, which are fixed strings published in the source. Your scan data, source code, findings and account details are never transmitted to any model provider.

If this changes

Adding a model call to this product would make most of this page false. If you are maintaining a fork or a deployment and you introduce one, this page is part of that change — not a follow-up task. The claim that findings are deterministic is the kind users rely on.

Contact

Talk to us.

Questions about what the engine checks, whether it fits your estate, or what it deliberately refuses to do. A person reads every message.

  1. 01You writePlain form, no qualifying call, no obligation. The marketing checkbox is optional and unticked.
  2. 02A person reads itMessages land with the team, not a queue-bot. Nothing is auto-replied.
  3. 03You get an answerTo the address you gave — including “this product is not the right fit”, when that is the honest answer.
Reporting a vulnerability?
Read the disclosure policy first — it tells you what is in scope and what to expect.
New messagereplies go to your email

Personal addresses (gmail, outlook, and similar) are not accepted.

+91

0 / 4000