Skip to content
cogniphicSuperintelligenceDownload Forge

SecurityThrough every layer

A layer, not a feature.

Security is not a product of its own here. It runs through every division: sandboxes in the runtime, approvals in Forge, keys in the Keychain, scope in testing, and a record of every decision.

✓ Allowed× Denied→ Routed[ ] Sandboxed( ) Key held
  • Keychain only
  • Scope you confirm
  • Audit for every call

Controls

Six controls,
on by default.

Nothing here is a promise for later. Each control runs in the product today.

  1. Sandbox

    Every command runs in a container: no network, a read-only system, privileges dropped.

    Default
  2. Approvals

    Tools that may change your data wait for you. A tool that changes asks again.

    Every tool
  3. Keys

    Sign-in tokens live in the macOS Keychain, never in a file or a database.

    Local
  4. Proposals

    Changes come back as a diff you apply, reject or undo.

    Every change
  5. Verification

    An edited test runs again against the original before anything passes.

    Every run
  6. Routing

    Afterburn seals endpoint keys at rest, keeps every route change reversible, and records who changed what.

    Compute

The rule

The model can’t
widen its own reach.

A model reads untrusted text all day. So what it may do is fixed outside it, and only your own actions can change that.

The model can

  • Use the fixed tools it was given, with arguments checked against a schema
  • Ask you before anything that may change your data
  • Read what you point it at

The model cannot

  • Add a tool, or a field to a tool
  • Widen its own scope or approve its own request
  • Take a target or a permission from a web page, a file or a tool’s output

Authorised testing

Test only
what you own.

The pentest module (ADR 0039) works inside an engagement: up to twenty hosts, IP addresses or network blocks that you declare and confirm you are authorised to test. Nothing is in scope until you confirm it.

  • Three fixed tools

    A port scan (TCP connect, at most 64 ports), one HTTPS request, and a read-only CVE lookup.

  • No payloads

    Nothing that sends an exploit, tries a password or runs an attack.

  • Checked before the network

    A call to a target outside the confirmed list is refused before a packet leaves the Mac.

  • On the record

    Every call is written to the ledger: target, tool, result and time.

EngagementExample targets

engagement  example-co · 2 targets · confirmed by you
  app.example.com          host
  10.0.4.0/24              network
port_scan   app.example.com   in scope · 64 ports max
http_probe  app.example.com   in scope · one HTTPS GET
port_scan   shop.example.net  not in scope · refused before the network
vuln_lookup CVE search         read-only · touches no target

The record

Every decision,
one line.

Tool calls, plugin calls, sandbox starts and approvals all land in one ledger you can read.

Audit logEvery decision, one line

09:41:02  plugin   linear.list_issues          read-only · allowed
09:41:03  sandbox  start · network none · root read-only
09:41:05  sandbox  curl api.example.com        denied
09:41:07  plugin   slack.post_message          may change data · asking
09:41:09  you      approved
09:41:12  verify   31 of 31 · original tests unchanged
09:41:20  keys     read from macOS Keychain · never written to disk

Questions

What can the pentest tools do?
Three things, and only against targets you confirmed: a TCP port scan of at most 64 ports, one HTTPS request, and a read-only CVE lookup. Nothing sends an exploit or tries a password.
Where are my keys stored?
In the macOS Keychain. Sign-in tokens are never written to a file or a database.
Can a web page talk the model into doing more?
No. What the model may do is fixed outside it. Text it reads cannot add a tool, a target or a permission; only your own actions can.