rest-fuzzer). Additional agents ship on their own cadence; the architecture stays the same.
GraphQL quality modules
Input Fuzzer
Test how your API handles bad input using five mutation strategies:
- Type coercion: strings where integers are expected
- Boundary values: MAX_SAFE_INTEGER, empty strings, zero, negatives
- Injection strings: SQL injection, XSS payloads, GraphQL abuse
- Null and empty: null arguments, empty arrays, missing required fields
- Malformed Unicode: invalid UTF-8, zero-width characters
Response Validator
Validates every response against the declared schema:
- Type mismatches: field declared as
Intreturns string - Unexpected nulls: non-nullable field returns null
- Extra fields: response contains undeclared fields
- Missing fields: declared field absent from response
RBAC Matrix
Tests every mutation against every role:
- No token: request with no auth header
- Expired token: past its TTL
- Wrong role: valid token, unauthorised role
- Correct role: should succeed
Rate Limit Validator
Tests whether rate limiting is enforced:
- Whether rate limiting exists at all
- Approximate threshold before throttling
- Presence of
X-RateLimit-*andRetry-Afterheaders - Proper 429 status codes
Error Code Validator
Validates error response quality:
- Format consistency: Do all errors follow the same structure?
- Information leakage: stack traces, file paths, internal state?
- GraphQL error classification: proper
extensions.codevalues? - HTTP status codes: appropriate 400 vs 500?
Deprecation Tracker
Tracks deprecation lifecycle:
- Active — field is live
- Deprecated — has
@deprecateddirective - Sunset — scheduled for removal
- Removed — gone from schema
REST: rest-fuzzer
When OpenAPI-backed REST operations are present, the pipeline runs rest-fuzzer19 strategies across six attack surfaces:
Quick CI presets may run a subset; full mode exercises the complete strategy set.
REST: OpenAPI response validation (validateResponseAgainstSpec)
The validateResponseAgainstSpec function in @dino/agents compares a captured REST response to the OpenAPI document (inline JSON schemas). It returns six ordered checks:
This API is shipped and tested for programmatic use (for example, tying validators into your own runners).
dino scan currently drives REST findings primarily through rest-fuzzer plus shared modules such as error-code-validator where REST traffic is exercised, not through a separate rest-response-validator tool name on the CLI.More agents coming
Dino’s architecture is built to support multiple quality dimensions: correctness, security, performance, compliance, and more. Each agent goes through the same quality pipeline before shipping: thousands of tests, false-output validation, and deterministic verification. New agents ship with each release.How modules work together
Modules are independent. They do not share state, do not depend on each other, and do not run in a fixed order. The pipeline runs all selected modules and collects findings when they complete. This means:- A defect in one module cannot corrupt another’s results
- You can turn off individual modules without affecting the rest
- New modules can be added without modifying existing ones
- Each module can be tested in complete isolation
AI reasoning (optional)
On top of the deterministic modules, Dino offers AI reasoning strategies that analyse findings across modules:
AI reasoning is optional and requires
DINO_AI_KEY. The deterministic engine always runs, AI enhances but never overrides.