/ LLM Lab

LLM Lab › Security

Dimension · Security

Security

Are data, runtimes, tools and model actions constrained to explicit boundaries?

What this page will show

planned

Each boundary as a confinement result from a probe that ran against it. Until that view lands, no page shows a Security result.

  • Data privacy and exposure
  • Runtime isolation
  • Network confinement
  • Tool and capability boundaries
  • Prompt injection
  • Model and artifact protection
  • Safety and control a sub-area of Security Read versus write permissions, approval gates, action limits, fail-safe defaults, audit and rollback.

One vocabulary for every result

  • verified only on positive evidence that the boundary acted
  • failed the probe saw the boundary breached
  • unknown the instrument could not tell

Why it matters

Security here means classic boundaries: data privacy and exposure, runtime isolation, network confinement, tool and capability boundaries, prompt injection, and model and artifact protection. Safety and control — read versus write permissions, approval gates, action limits, fail-safe defaults, audit and rollback — sits beneath Security as a sub-area, not as a dimension of its own.

First release

A confinement result reads in one vocabulary: verified only on positive evidence that the boundary acted, failed when the probe saw it breached, and unknown when the instrument could not tell. The page never shows a confinement claim the instrument did not verify.

run evidence

The view of a confinement result is planned: until it lands, no page renders a Security payload. Each committed run is listed here with its own reason. To read a bundle of your own, open it on the Performance page.