This document collects the canonical artifact set for a future external security review, architecture review, or equivalent third-party assessment.
It is a preparation package, not the review itself.
No external assessment has been completed from this repository yet, and roadmap item #22 remains open until that changes.
- a truthful briefing set for an external reviewer
- the current control-truth, threat, and limitation documents
- the commands needed to regenerate current evidence locally
- buyer-safe language for explaining the difference between preparation and completed third-party validation
- a completed audit, penetration test, architecture assessment, or attestation
- certification of SOC 2, ISO 27001, FedRAMP, CMMC, or equivalent programs
- proof that customer-environment controls were reviewed by an outside party
| Question | Answer |
|---|---|
| Has ACP completed an external assessment yet? | No |
| Can buyers reference a third-party review today? | No |
| Is ACP prepared for an external review briefing? | Yes |
Does this close roadmap item #22? |
No |
Give an external reviewer these artifacts first. make assessor-packet copies these ten tracked documents verbatim into the generated dated run so operators no longer have to gather them manually.
| Artifact | Why it matters | Path |
|---|---|---|
| Threat model and security whitepaper | Explains architecture, trust boundaries, abuse paths, mitigations, and residual risks | docs/security/SECURITY_WHITEPAPER_AND_THREAT_MODEL.md |
| Compliance crosswalk | Maps ACP evidence and ownership to SOC 2, ISO 27001, and NIST-style controls | docs/COMPLIANCE_CROSSWALK.md |
| Go-to-market scope | Defines validated, conditionally ready, and not-yet-validated claim boundaries | docs/GO_TO_MARKET_SCOPE.md |
| Known limitations register | Shows current material gaps and open findings | docs/KNOWN_LIMITATIONS.md |
| CVE governance policy | Shows how vulnerabilities are triaged, accepted temporarily, reviewed, and communicated | docs/security/CVE_REMEDIATION_AND_RISK_ACCEPTANCE_POLICY.md |
| Shared responsibility model | Makes customer vs ACP control ownership explicit | docs/SHARED_RESPONSIBILITY_MODEL.md |
| Pilot/control ownership matrix | Clarifies implementation and operating ownership lines | docs/PILOT_CONTROL_OWNERSHIP_MATRIX.md |
| Evidence workflow | Shows how current local readiness proof is regenerated | docs/release/READINESS_EVIDENCE_WORKFLOW.md |
| Evidence map | Connects repo claims to commands and source artifacts | docs/evidence/EVIDENCE_MAP.md |
| Go/No-Go criteria | Shows release decision rules and the still-open independent-review expectation | docs/release/GO_NO_GO.md |
After regenerating current evidence, assemble the reviewer handoff packet with:
make assessor-packet
make assessor-packet-verifyThis workflow packages:
- the 10 canonical reviewer documents listed above
- the latest verified successful readiness evidence run
- the release bundle tarball and checksum referenced by that readiness run
- a machine-readable
summary.json - a human-readable
assessor-summary.md - a packet inventory and latest-run pointer
The assessor packet is preparation infrastructure only. It does not mean an external assessment has been completed, and it does not close roadmap item #22.
Run these commands before handing material to an external reviewer:
make security-gate
make release-bundle
make readiness-evidence
make readiness-evidence-verify
make assessor-packet
make assessor-packet-verifyThe assessor-packet step is a packaging workflow only. It does not execute the gates above for you.
Use the latest dated outputs under:
demo/logs/assessor-packet/assessor-packet-<TIMESTAMP>/
The packet includes copied tracked documents plus generated readiness and release artifacts. Generated evidence remains local-only and intentionally not committed. See docs/ARTIFACTS.md.
Best when the buyer wants an expert review of boundaries, design choices, and residual risk.
Typical scope:
- architecture and trust boundaries
- enforce-vs-detect truthfulness
- control ownership split
- key limitations and compensating controls
Best when the buyer wants a structured security opinion tied to current implementation and operating evidence.
Typical scope:
- threat model review
- vulnerability governance review
- evidence workflow review
- deployment hardening and operational recovery review
Best when the buyer wants hands-on testing of a named deployed environment.
Typical scope:
- exposed surfaces in the target environment
- auth, ingress, and runtime misconfiguration testing
- environment-specific findings and retest requirements
Important: a penetration test is environment-specific and does not replace the broader architecture or control review by itself.
Use this statement when asked whether ACP has been independently reviewed:
AI Control Plane has not yet completed a third-party security or architecture assessment that we can cite as completed external validation. What we do have today is a structured external-review readiness packet: current threat model, control crosswalk, known limitations, governed CVE process, ownership boundaries, and regenerable readiness evidence. The correct claim is that ACP is prepared for external review, not that external validation is already complete.
- ACP has a structured, reviewer-ready evidence packet
- ACP can regenerate current local readiness and security evidence on demand
- ACP documents current limitations and control boundaries explicitly
- ACP has completed an external review
- ACP has independent certification or auditor approval
- ACP has third-party validation covering every customer environment
Roadmap item #22 is complete only when a real security review, architecture review, or equivalent external assessment has been completed and can be referenced in buyer conversations.
Until then, this readiness package is preparation work only.