Canonical contracts are the product boundary
The Workbench should not need to know whether an incoming evidence object came from Verno, Dreadnode, a scanner provider, OpenTelemetry, or a future partner. Likewise, the AI Security Workbench scanner should not contain partner-specific fields. Three canonical models sit at that boundary:
- Finding — a security finding from a scanner, test engine, analysis engine, or normalized external scanner.
- Evidence / Attack Trace — a provenance-bearing observation, explicitly separating observed state, grounding eligibility, provenance, and taxonomy mappings from anything inferred.
- Attack Path Result— AI Security Workbench's canonical return structure for evidence-qualified attack clusters, grounded vs. speculative boundaries, validation state, chokepoints, and retest conditions.
Protocol-first, then vendor binding
If two vendors share an interchange protocol, the protocol is implemented once, not once per vendor:
| Protocol | Vendors on it today |
|---|---|
| SARIF | scanner-compatible workflow, StackHawk-compatible workflow, GitHub/GitLab code scanning |
| OpenTelemetry | Verno and Pallma lineage; future agent/runtime platforms |
| ATIF | Dreadnode; future trajectory-producing systems |
A vendor binding may rename fields, normalize enums, preserve vendor identifiers, and select protocol capabilities — it should not reimplement JSON Schema validation, provenance mechanics, or generic severity normalization; those live once in the protocol layer.
Four-stage claim boundary
Every vendor binding is explicit about how confirmed its claims are:
| Stage | Meaning |
|---|---|
| Vendor documented | A field, endpoint, or behavior explicitly documented by the vendor. |
| AI Security Workbench projection | A AI Security Workbench-defined representation shaped to interoperate with the publicly documented vendor model — not asserted to be a valid native request. |
| Partner confirmation required | A write path, private API, webhook body, or ingestion schema that public material does not establish. |
| Native partner confirmed | A contract supplied or explicitly confirmed by the partner — the only stage a native adapter should be built against. |
This is why current Verno and scanner-provider adapters do not claim a final native schema, webhook contract, or confirmed rescan/ingestion path — see partner pilots.
Scanner extension
The partner owns scan orchestration, customer/target context, product interface, finding lifecycle, remediation workflow, and first-line support. AI Security Workbench adds AI-native code and workflow analysis, structured findings, SARIF where supported, and evidence references.
Offensive-platform enrichment
The partner owns attack generation, campaign workflow, execution, and the operator interface. AI Security Workbench adds architecture and authority context, evidence and sequence qualification, chokepoint analysis, and structured return objects — while keeping grounded and speculative steps distinct.
Pilot before native integration
A native adapter is never the first deliverable. First prove input compatibility, output usefulness, identity/provenance retention, and lifecycle fit — see partner pilots.