HighCastle← Back to site
Controlled test app — synthetic users and records only

Live controlled demo

Watch an authorized test run — then prove the fix

This demo executes one bounded check on our own invoice lab: synthetic Alice must not read synthetic Bob's invoice. Same pipeline as the product — scope, model plan, sandbox execution, independent verdict — with every boundary enforced live.

Consent & scope check

This demo will

Scope active
Target
target-lab (HighCastle-owned synthetic invoice app)
Check
bola-invoice-v1 — broken object authorization
Identities
alice, bob — synthetic tenants, seeded records
Limits
GET only · ≤8 requests · ≤30s · disposable sandbox
Workspace
highcastle-demo

What it will not do

No writes, no third-party systems, no real customer data, no persistent environment — the sandbox is destroyed and the cleanup is verified.

What a run looks like

Recorded preview — sample fixture

Event timeline (recorded)

  1. Vultr model proposed BOLA hypothesis

    PlanningModel

  2. Policy validated bola-invoice-v1

    PlanningPolicy

  3. Disposable runner allocated, caps enforced

    PreparingRunner

  4. Alice → own invoice baseline

    ExecutingRunner
    HTTP 200 · own synthetic record

  5. Alice → Bob boundary check

    ExecutingRunner
    HTTP 200 · Bob's protected invoice returned

  6. Oracle verdict: reproduced

    VerifyingOracle

GET /api/invoices/inv_B → 200

Response (redacted) · recorded sample run
Redacted
sha256:9f2cd41b6a0f77e2c8a1b5d39e04c7a2f11e8d2c6b90a4f5e1c3d7b9a2e4f601

Containment ledger

Network egressrestricted
Host mountsnone
Secret accessnone mounted
Request cap4 / 8 used
Policy blocksnone this run

Ready for your own targets?

Verified-target onboarding and GitHub PR checks are the next milestones — the demo scope above shows exactly what authorization will look like when they land.