Technical assurance
Evidence a security team can verify, not a summary to take on faith.
Technical assurance at Nexus means signed reports, execution records that can be reproduced, testing practices applied to the AI endpoints we help you run, and a clear route to report a vulnerability.
- reports and findings
- Signedreports and findings
- execution records
- Reproducibleexecution records
- MITRE ATLAS and OWASP LLM Top 10
- Mapped toMITRE ATLAS and OWASP LLM Top 10
- vulnerability disclosure to our team
- Routedvulnerability disclosure to our team
Signed reporting
A report that can be verified, not just read.
Security and compliance findings are only useful if the recipient can trust the report itself has not been altered.
- Signed output
- Reports produced by Nexus Cerberus, including AI red-teaming and AI-BOM scan results, are signed so a recipient can verify the report has not been altered since it was generated.
- Structured findings
- Findings are recorded in a structured format with severity, affected component and remediation guidance, rather than free-text summaries only.
- Framework mapping in findings
- Where a finding corresponds to a known technique, it is mapped to MITRE ATLAS or OWASP LLM Top 10 categories so a security team can cross-reference it against their own tracking.
Reproducible execution records
An execution record should let you reconstruct what happened, not just tell you that something happened.
A record that only states an outcome is much less useful than one that preserves enough detail to walk through the decision again.
Inputs and outputs are retained together
The retrieved data, rule evaluations, model input and output, and reviewer decision for a given execution are stored as a linked record, so the sequence can be reviewed in order rather than reassembled from separate logs.
Versioning ties a record to the configuration that produced it
Workflow and rule versions are tracked, so an execution record can be checked against the exact configuration that was live when it ran, even after that configuration has since changed.
Testing and evaluation
How AI endpoints deployed with Nexus are tested.
Testing practices here describe Nexus Cerberus capabilities, applied to AI endpoints running in your environment.
AI red-teaming
Nexus Cerberus tests deployed AI endpoints against adversarial prompts and known attack patterns, producing findings mapped to MITRE ATLAS.
OWASP LLM Top 10 testing
AI endpoints are evaluated against categories in the OWASP LLM Top 10, with results recorded per endpoint and per category.
AI-BOM and model supply chain scanning
Model artifacts and their dependencies are scanned to produce an AI bill of materials, so a security team can see what a deployed model actually depends on.
Vulnerability disclosure
How to report a vulnerability.
Responsible disclosure
If you believe you have found a security vulnerability in Nexus software, we want to hear about it directly rather than through a public report. Contact our team through the general contact channel and describe the issue; a member of our security team will follow up to coordinate details, reproduction steps and, where relevant, a disclosure timeline.
Relevant capabilities
Where technical assurance is implemented.
Nexus Cerberus
AI endpoint registry, red-teaming, AI-BOM scanning and signed reporting.
ExploreNexus Atlas
External attack surface discovery, enumeration and validation.
ExploreGovernance and Audit
The execution record this page describes.
ExploreCompliance
How records translate into regulatory evidence.
ExploreArchitecture session
Ask us about a specific test or a specific finding.
Whether you are evaluating our red-teaming reports or reporting a vulnerability, our team is the direct point of contact.