Features

Containment & ringfencing

Declare the capability budget each piece of non-binary software is allowed — network, filesystem, shell, secrets — and catch anything beyond it.

Not all risk is "install or don't." Some software is necessary but should be constrained. Ringfencing lets you declare a capability budget for an extension, package, or MCP server — what it's allowed to do — and treats anything beyond that budget as a violation.

What a ringfence controls

A ringfence is a capability budget across four dimensions:

Network — allow a whitelist of hosts, or deny all egress.
Filesystem — read-only, or read-write allowed.
Shell / native exec — permitted or not.
Secrets / environment — access permitted or not.
Child processes — spawning permitted or not.

Create a ringfence

Ringfences are defined from a piece of software's Discovery detail page: open any agent-reported artifact and choose Ringfence. Cernexa pre-fills a suggested budget from the capabilities and egress hosts observed during analysis, which you can tighten before saving.

Each ringfence runs in one of two modes:

Detect — violations are logged but not blocked.
Enforce — violations are auto-blocked on active endpoints.

Where enforcement runs

When a ringfence is in Enforce mode on an active endpoint, the agent applies it as a real per-launch sandbox — it rewrites how the software is started so the budget is contained at the OS level, reversibly:

macOS — seatbelt (sandbox-exec).
Linux — bubblewrap when installed (network-deny is fully contained; install bubblewrap for active containment, otherwise the endpoint falls back to detection).
Windows — an AppContainer launcher (cernexa-fence.exe): the MCP server is started inside an AppContainer with no network capability (so "deny" egress is genuinely blocked) and filesystem access scoped to what it needs. Read-only system locations stay readable; the user profile is deny-by-default.

Network "deny" is the strongest, cleanest guarantee on every platform. Where a dimension can't be enforced by the OS primitive (e.g. a hostname allow-list rather than full egress deny), the budget is still enforced by server-side detection — the violation is caught, just not pre-blocked. This is surfaced honestly rather than presented as containment it isn't.

One Windows nuance: active containment of an approved server is fully supported, but read-only introspection of brand-new local servers stays opt-in there (the deny-by-default cage can't be auto-applied to an arbitrary, unknown launcher). Remote and already-contained servers introspect automatically.

Violations

The Containment page has two parts:

Open violations — each shows the software, the violation kind (network egress, filesystem, shell / native exec, secrets / env, child process, or permission), the detail of what exceeded the budget, the endpoint, a severity, and when it happened.
Ringfences — every budget in force, with its mode, allowed network hosts (or "no egress"), and which capabilities are unlocked ("locked" when all are disabled).

How it relates to drift