Case study: security validation
Pentest agents that leave an auditable evidence trail.
Use RushDB as the shared evidence graph for authorized security testing: sandbox scope, targets, findings, evidence, red-team log events, triage state, and defensive dashboards all stay queryable from one datasource.
Security validation falls apart when findings and logs split.
A pentest agent can produce useful observations, but the value disappears when findings live in a report draft, log evidence lives in another system, and red-team replay data becomes a disconnected dashboard. The security team needs one place to inspect what happened, what evidence supports it, and what still needs triage.
Before
- Agent notes, screenshots, and logs stored in separate tools
- Findings copied into reports without durable evidence links
- Red-team event views rebuilt from a different datasource
- Triage state tracked outside the testing record
With RushDB
- Authorized sandbox scope, targets, findings, evidence, and logs stored as records
- Findings stay linked to supporting evidence and related log events
- Breach-abuse visualization reads the same RushDB datasource
- Triage dashboards use filters, select, groupBy, and relationship queries
Graph intelligence on ingest
Incoming data becomes queryable graph context.
RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.
01
Normalize as data arrives
Import JSON or CSV. RushDB infers property types and adds new fields to the live, queryable ontology without a schema migration.
02
Auto-link nested structure
Nested objects become connected records automatically, preserving the parent-child graph structure already encoded in your payload.
03
Enrich scattered sources
After flat imports or schema changes, analyze the project ontology. RushDB can suggest join patterns and semantic relationship types for your review.
Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.
Review suggested relationship patternsData model
One flexible graph for the workflow.
Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.
The graph keeps scope, findings, evidence, logs, controls, and triage connected for defensive review.
{
"assessmentRunId": "rt-sandbox-42",
"environment": "sandbox",
"authorizationId": "auth-2026-06",
"TARGET": [{
"targetId": "web-app-sandbox",
"systemType": "training-web-app",
"FINDING": [{
"findingId": "finding-017",
"category": "access-control",
"severity": "high",
"status": "open",
"EVIDENCE": [{ "evidenceId": "ev-017", "kind": "log_summary" }]
}],
"LOG_EVENT": [{ "eventId": "log-884", "tactic": "privilege-misuse", "severity": "high" }]
}]
}Working example
Commit a finding. Visualize the related abuse events.
An authorized sandbox agent records one access-control finding with evidence. The red-team UI reads open findings and groups related log events by tactic and severity.
ASSESSMENT_RUN rt-sandbox-42
TARGET web-app-sandbox
FINDING finding-017 severity: high status: open
EVIDENCE ev-017 kind: log
LOG_EVENT log-884 tactic: privilege-misuse severity: high{
"labels": ["LOG_EVENT"],
"where": {
"ASSESSMENT_RUN": { "assessmentRunId": "rt-sandbox-42" }
},
"select": { "events": { "$count": "$record" } },
"groupBy": ["$record.tactic", "$record.severity"],
"orderBy": { "events": "desc" }
}[
{ "tactic": "privilege-misuse", "severity": "high", "events": 12 },
{ "tactic": "suspicious-session", "severity": "medium", "events": 7 }
]TypeScript SDK
Commit findings and query abuse telemetry from one graph.
The agent writes only authorized sandbox observations. The same RushDB records power evidence review, red-team event visualization, and defensive reporting.
Implementation blueprint
Build the authorized security-validation path.
Use this sequence to keep pentest findings, evidence, triage, and red-team visualization grounded in one defensive datasource.
- 01Define authorized ASSESSMENT_RUN scope and sandbox targets
- 02Import TARGET, FINDING, EVIDENCE, LOG_EVENT, CONTROL, and TRIAGE records
- 03Attach findings to evidence and related log events
- 04Group breach-abuse events by tactic, severity, target, and control
- 05Render the UI from RushDB queries over the same records used for reporting
Build path
- Restrict ingestion to authorized sandbox assessments and approved red-team exercises.
- Keep FINDING records linked to EVIDENCE and LOG_EVENT records.
- Use dashboards for defensive triage, control validation, and reporting.
- Do not store exploit payloads or operational abuse instructions in the public workflow.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
Relationships API
Attach findings to evidence, controls, targets, triage records, and related log events.
Open docsSelect expressions
Aggregate defensive telemetry by tactic, severity, target, control coverage, or triage status.
Open docsSuggested relationship patterns
Review relationship suggestions for scattered security data without silently mutating graph meaning.
Open docsHow it works
Build the smallest useful workflow first.
01
Record authorized scope
Store assessment authorization, sandbox boundaries, targets, and allowed test windows before any agent writes findings.
02
Commit evidence as records
Write findings, evidence summaries, triage state, controls, and log events as connected records instead of scattered report notes.
03
Visualize from the same graph
Use one datasource for breach-abuse timelines, severity breakdowns, affected targets, and remediation status.
Know where it fits.
Authorized defensive scope only
This pattern is for sanctioned sandbox testing, red-team exercises, control validation, and defensive reporting. It does not describe exploit execution or unauthorized activity.
Evidence beats agent prose
The useful output is not a confident agent paragraph. It is a finding linked to evidence, logs, affected targets, triage state, and a remediation owner.
Questions developers ask.
Next step