Add AI-native security coverage to the scanner your customers already use.
Extend an existing AppSec or vulnerability-scanning product with AI-specific code findings, retrieval and agent context, tool and authority relationships, optional Attack Path Analysis, remediation context, and evidence lifecycle support—without replacing the scanner, workflow, or customer experience you already own.
Bounded, partner-native, evidence-linked, and expandable.
Add findings across AI application code, prompts, retrieval, agents, MCP, tools, permissions, outputs, and consequential actions.
Return structured findings and context through the scanner's existing schema, issue identity, reports, and lifecycle.
Start with findings. Add system, authority, validation, or path analysis only when it improves the scanner product.
Preserve source evidence, claim state, remediation, rescan, and retest context.
HOW IT WORKS
One finding in. Connected context out.
The scanner sends a structured finding, scan result, repository selection, or approved evidence object. The OEM Engine adds the selected AI application analysis and returns a partner-native result through the scanner's existing workflow.
Partner Findings Lifecycle
AI-native findings return into the partner product with lifecycle state preserved through review, remediation, rescan, and retest.
Round-trip integration showing partner finding or scan evidence, Workbench enrichment, partner-native return, and the rescan or retest loop.
- 1Partner finding or scan evidenceTarget • Request/response evidence • Workflow observation • Stable issue identity
- 2Workbench enrichmentAI-native path • Evidence qualification • Authority context • Validation state • Remediation
- 3Partner-native returnPreserved issue identity • Reporting state • Remediation status • Retest condition
- 4Rescan or retestLifecycle history remains connected to the original issue
From partner finding to rescan.
- Stable finding identity
- Affected target or component
- Location or request evidence
- Current severity or priority
- Current lifecycle state
- AI-specific finding context
- Code-risk or authority relationships
- Optional path membership
- Evidence and claim state
- Remediation and validation requirements
- Original finding identity preserved
- Native schema projection
- Reporting and lifecycle state
- Remediation context
- Retest requirement
- Original issue remains correlated
- New evidence is attached
- Path and remediation state are updated
- History remains visible
The scanner remains the system of engagement. The OEM Engine adds selected analysis behind it and returns the result through the scanner’s own workflow.
Keep the finding identity. Add the context required to act.
The test is not whether the Workbench can produce another report. The test is whether one scanner object can return with materially better technical context, evidence, remediation, and lifecycle state without losing its native identity.
1{2"finding_id": "partner-98271",3"severity": "High",4"component": "agent/tool-runner",5"location": "services/agent/runner.py:142",6"description": "Retrieved context can influence a consequential tool call."7}
1{2"return_id": "workbench-demo-018",3"finding_id": "partner-98271",4"evidence_refs": ["source-path-142", "tool-policy-07"],5"code_risk_path": "retrieved_context -> agent_decision -> consequential_tool",6"path_state": "candidate_requires_validation",7"claim_state": "supported_code_finding",8"remediation": "Constrain tool arguments and require approval before execution.",9"lifecycle_state": "enriched_retest_required",10"validation_state": "not_validated_pending_retest"11}
Sanitized reference shape · not a customer result
Sanitized reference example. Exact fields and mapping depend on the partner's finding model and the agreed pilot contract.
Optional expansion: Where supported findings and relationships may form a consequential route, Attack Path Analysis can qualify the path, preserve explicit inference, and identify shared remediation chokepoints.
Attack Path Analysis: what a scanner can receive
Scanner findings may be individually valid but operationally disconnected. Attack Path Analysis determines whether supported findings, authority relationships, runtime traces, system context, and control weaknesses combine into a meaningful path. It does not replace the scanner's detection engine or generate exploit instructions.
Scanner findings to connected path analysis
- Existing scanner finding
- AI-specific Workbench findings
- Optional code, authority, system, or runtime context
- Attack Path Analysis
- Candidate, supported, validated, reproduced, rejected, or residual path state
- Evidence grounding and explicit inference labels
- Remediation chokepoints and retest conditions
- Existing scanner UI, report, and lifecycle
Supported paths, related candidate paths, and explicit validation state — never a claim of universal graph coverage.
Start with findings. Expand into attack paths.
Code Scanner identifies supported code findings and code-risk paths involving prompts, retrieval, models, agents, MCP, tools, permissions, data, outputs, and consequential actions.
Partner value
New AI-specific findings inside the scanner's existing issue model.
Outputs
- Structured findings
- Code references
- Code-risk paths
- Evidence references
- Remediation guidance
- Validation requirements
- JSON or SARIF where supported
Authority Graph and related analysis can add approved relationships among applications, agents, identities, credentials, tools, permissions, approval gates, controls, and consequential actions.
Partner value
Better reachability, blast-radius, authority, and control context around findings.
Outputs
- Authority relationships
- Authority paths
- Approval boundaries
- Dangerous composition
- Control context
- Evidence references
Attack Path Analysis determines whether supported findings, relationships, traces, and preconditions form a defensible route toward consequential impact — only where the underlying relationships justify it.
Partner value
Connected prioritization beyond flat finding severity.
Outputs
- Candidate, supported, or validated attack paths
- Reproduced or rejected paths where determined
- Related candidate paths
- Evidence grounding and explicit inference labels
- Remediation chokepoints
- Review state
Remediation, evidence, rescan, and retest state return through the partner's own workflow, preserving the original finding identity end to end.
Partner value
One lifecycle the partner's team already works in — not a second system to check.
Outputs
- Remediation guidance
- Rescan status
- Retest conditions
- Evidence references
- Partner-native return
Explicit lifecycle state, not a single Validated flag.
- 1.Detected candidate
- 2.Deduplicated
- 3.Evidence supported
- 4.Claim state assigned
- 5.Validation required or not required
- 6.Machine-validated where applicable
- 7.Analyst accepted, constrained, or rejected
- 8.Reportable within stated scope
Start with a bounded contract, not a platform replacement.
Detailed format maturity and adapter registries live on Partner Interoperability. This is the bounded contract the pilot actually tests.
Versioned JSON preserves issue identity, evidence references, claim state, lifecycle state, validation state, remediation, and mapping decisions.
SARIF and other supported vulnerability shapes may be emitted where they fit the scanner workflow. Projection availability is not the same as native partner acceptance.
The pilot tests the scanner's actual finding object, severity model, lifecycle, deduplication, rescan, remediation, and retest behavior before any production compatibility claim.
A scanner pilot should prove uplift, evidence quality, lifecycle fit, and production viability.
Optional deliverables when Attack Path Analysis is in scope.
- Partner findings
- Connected context
- Path and claim state
- Evidence and inference labels
- Relevant mappings
- Remediation chokepoints
- Retest conditions
- Partner-native return
Analysis uplift
Where additional context or Attack Path Analysis is in scope, the pilot demonstrates measurable value beyond flat finding generation through improved context, path qualification, authority analysis, evidence quality, or remediation prioritization.
What the pilot asks from each side.
Supply one sanitized finding, schema, representative scan result, or bounded target. The Workbench adds connected context and returns an agreed object so both sides can determine whether the added coverage is useful inside the existing scanner workflow.
- 1–2 engineering contacts
- Sample findings or fixture set
- Schema review
- Mapping approval
- Test environment
- Engine invocation
- Finding enrichment
- Evidence handling
- Adapter configuration
- Pilot readout and production recommendation
Production adapter included only after conversion
Productize only if the result improves the scanner.
Exact pilot, implementation, and licensing terms depend on the selected capability, integration burden, deployment model, customer scope, and support requirements.
- 1
Pilot
Prove one finding and one native return path.
- 2
Productize
Harden the adapter, lifecycle, release, monitoring, and support boundary.
- 3
License
Agree the selected capabilities, deployment model, customer scope, update entitlement, support boundary, and any negotiated OEM or white-label branding rights.
Start with one representative finding.
Prove the contract, the enrichment, and the return path before you commit to a deeper integration.