From the NVIDIA edition of October 2, 2026
Creative AI News: OpenShell policy prover tested—9 caught, 9 unsupported, CI exit-3 risk
Creative AI News · Independent AI engineering journalism · Global
- Publisher
- Creative AI News
- Original publication
- 2026-09-28T18:31:00Z
- Source retrieved
- 2026-10-03
- Event date
- 2026-09-28
What happened
Why now (Oct 2): Anomity’s same-day production-defaults guide elevates CI gating of OpenShell policies; this Sep 28 Creative AI News hands-on test remains unarchived and is the only measured prover coverage complementary to that advice. Authors ran openshell-prover 0.1.2 (SHA-256 verified) against 19 permission-widening edits on a coding-agent boundary: 9 exceeded with concrete counterexamples, 9 returned unsupported (exit 3)—including every filesystem widening, enforce→audit switches, and GraphQL endpoints—and 1 within_boundary because the runtime always blocks cloud-metadata. Checks finished under 200 ms. Verdict: prover is honest about limits; risk is CI that treats “not rejected” as safe—gate on exit 0 only.
Why it matters
Gives SLED platform teams a concrete CI acceptance rule (fail on exit ≠ 0) and documents which loosenings the prover will not catch—directly actionable beside Oct 2 defaults guidance.
Evidence and measured results
Opened Creative AI News article with datePublished 2026-09-28T18:31:00Z (modified 2026-09-29). Body includes tabulated 19 widening edits, exit codes, and explicit CI guidance.
Limitations and uncertainty
Single-lab hands-on on v0.1.2; not a formal red-team of OpenShell runtime escapes; Sentry not tested; publication is two research nights before Oct 2 but newly paired with Oct 2 defaults guidance and still absent from archive.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-03; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Buyers need evidence that OpenShell’s formal prover catches real policy loosenings—and where it does not.
- Stakeholders
- AI platform lead
- DevSecOps
- CISO
- Discovery questions
- Do you gate policy PRs with openshell-prover?
- Fail on exit 3 or only exit 1?
- Who reviews filesystem policy changes?
- Value hypothesis
- Hands-on 9/9/1 results bound a CI control story without claiming Sentry or full escape resistance.
- Potential engagement
- Short prover CI design review using the published harness pattern.
- Unsupported claims
- Guarantee all risky edits are caught
- Sentry millisecond quarantine proof
- SLED measured outcomes
Pre-sales engineering
Role takeaway
- Fit
- CI integration of openshell-prover with exit-0-only gate.
- Architecture and integration
- Keep boundary and candidate YAML in git; run prover offline without gateway.
- Prerequisites
- OpenShell 0.1.2+ pinned
- x86_64/arm64 Linux runner
- Boundary policy reviewed by security
- Constraints
- Filesystem changes return unsupported
- GraphQL/MCP uncheckable
- Exit 3 ≠ safe
- Security
- Treat enforce→audit as high-risk loosening requiring human review even when prover is inconclusive.
- Proof of value
- Reproduce audit-mode exit 3
- Reproduce GraphQL exit 3
- Confirm metadata runtime always-block behavior
Delivery
Role takeaway
- Work
- Implement prover CI, document exit codes, train reviewers.
- Dependencies
- DevSecOps pipeline owners
- AI platform
- InfoSec policy authors
- Ownership
- Platform eng owns CI job; InfoSec owns boundary policy.
- Skills and adoption
- Adopt NVIDIA OpenShell skills optionally; pin install versions.
- Governance checkpoints
- CI policy merged
- Exit-code runbook published
- Sample failing PR demonstrated
- Acceptance criteria
- PR blocked on exit ≠ 0
- Manual filesystem review checklist live
- Risks
- Naive fail-on-exit-1 gate
- Unpinned install from main
- Assuming prover proves least privilege
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Wire openshell-prover into policy CI with pass-only-on-exit-0; review filesystem and audit-mode changes manually.
Governance
Who approves, reviews and stays accountable for outcomes?
Document prover coverage limits in security control descriptions so auditors do not equate exit 3 with safe.
Security and privacy
What data, permissions and controls need testing?
Enforce→audit and GraphQL additions can bypass a naive fail-on-exit-1 gate; metadata host rules may look allowed while runtime blocks them.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Prover CI is specialist DevSecOps work; plan shared templates so smaller SLED teams can reuse gates.
Procurement
What should contracts, pricing and exit terms secure?
Ask vendors/integrators for prover CI evidence and exit-code policy, not only OpenShell install demos.
Operating model
Which teams own the service once it runs?
Policy changes become code-reviewed artifacts with automated gates plus manual filesystem review.
Publication history
- 2026-10-02NVIDIA · Issue 286 resources
Stable resource ID: creativeainews-openshell-prover-20260928