Security and trust
Security claims should follow the implementation boundary. This page states what the NiGeNje control path enforces, what is only partially implemented, which invariants must be preserved, how safe degradation is scoped, and what is explicitly outside it — including the actions NARG does not intercept.
Security model
Each property below is either verified in the local demonstration chain or explicitly marked partial. A partial property is not a vulnerability disclosure; it is an honest statement of scope so an evaluator can decide what to test.
Admission carries a caller identity and tenant context. In the reviewed environment this is a local demonstration identity; external OIDC is not configured, so identity strength depends on the deployment environment rather than on a claimed enterprise identity integration.
Permits carry tenant scope and admission evaluates the tenant context. Isolation across a real multi-tenant deployment was not verified in the reviewed evidence, so tenant separation is a boundary to test, not a published guarantee.
Actions are admitted against a declared scope and a registered mediation path. Capability outside that registration is not constrained by the platform, which is why the mediation boundary matters more than the feature list.
Permits are scoped, expiring and single-use, and expiry and invalid-permit paths were exercised. A revocation workflow was not verified in the reviewed evidence; do not assume instantaneous revocation until it is demonstrated in your environment.
The permit is bound to the action digest including its arguments. An altered payload was refused at dispatch with a permit/action mismatch and no effect was written.
Single-use permit enforcement and durable replay/nonce state were verified in the local chain, including recovery across a restart. Replay did not change the recorded result.
Decision, permit, execution and outcome records sit in ordered, hash-linked chains that verify. One signed envelope spanning every component is not implemented, and external anchoring is partial, so evidence continuity is stronger than evidence independence.
External state is read back after an action and reconciled against the required postcondition; divergent and unknown outcomes were verified. The current read-back is performed by NARG itself, not by a separate third-party observer.
Admission blocks when required policy context is unobserved (POLICY_CONTEXT_UNOBSERVED) rather than assuming it is safe. Fail-closed behaviour is not claimed for every failure mode: where the outcome cannot be established, it remains unknown instead of being reported as success.
Immune state participates in admission and containment planning. Autonomous containment and recovery were not demonstrated end to end, and no detection-rate, response-time or coverage claim is made.
Security boundary
The control path runs from the actor through intent, admission, permit, mediation execution, observation and evidence. Enforcement is real at the registered mediation path and partial elsewhere. Everything outside that path is outside the boundary.
Control path
Every step below is part of the registered control path. The status shown is what was verified in the local, non-production demonstration chain; it is not a production assurance statement.
Actor Intent Admission Permit Mediation Execution Observation Evidence
Constraint layer · verification, not enforcement
λ-Safe formalizes supported contracts, compiles supported invariants, verifies admissible transitions and refuses what it cannot decide. Its outputs constrain admission and decisions; the runtime components below enforce them.
λ-Safe does not intercept a live action, revoke a permit or contain a failing dependency. Gatekeeper admits, NARG mediates registered actions, Substrate executes and the Immune Engine contains.
Degraded-mode path
Safe degradation is a published research model and a labelled local simulation. It describes how a system could reduce non-essential capability while preserving mandatory invariants. It is not production runtime enforcement.
The safe-degradation scenario in the interactive demo is a deterministic local simulation of this model. Production runtime degradation enforcement is not implemented or verified.
Open the labelled simulationBoundary of the current implementation
Outside the registered mediation boundary
NARG does not intercept direct shell commands, raw socket traffic or unwrapped filesystem writes. Protection exists only for actions routed through a registered mediation point.
NARG protects registered mediation paths and is not universal interception of arbitrary shell, direct socket or unwrapped filesystem activity. If a component can act without passing through a registered mediation point, the current implementation does not stop it. Treat the mediation boundary as one control among several, alongside sandboxing, least privilege and network policy.
Registered tool actions are admitted against intent and evidence, issued a scoped permit, verified again at dispatch, executed through a bounded adapter and read back so the outcome can be reviewed.
Identity, observation and evidence are partially implemented. External OIDC, hardware-backed keys, a third-party observer and one signed lifecycle envelope are not in place.
Direct shell execution, raw socket traffic and unwrapped filesystem writes are not intercepted. Actions that bypass registration are not governed by this platform.
Invariant preservation and safe degradation
A distributed system can keep serving while violating the property it exists to protect. Availability mechanisms preserve service continuity; invariant preservation asks a different question: given the current operating conditions, which transitions are still admissible, and what must remain true in a reduced mode?
An invariant is a condition that must remain true across every admitted action and every admissible mode — not only while the system is healthy. In a governed system the mandatory properties are derived from declared obligations and kept explicit, so a transition can be checked instead of assumed.
The exact set is system-specific; NiGeNje does not publish a universal invariant list. The labelled safe-degradation scenario in the interactive demo illustrates the shape of the problem:
These are examples from the labelled simulation of the published model, not a claim that every listed invariant is supported by the current compiler. Compiled support today is a bounded numeric fragment; unsupported or indeterminate obligations are refused rather than approximated.
| Availability mechanism | What it preserves | The invariant question it does not answer |
|---|---|---|
| Failover / retry | Service continuity and request progress. | Whether the retried or redirected transition is still admissible. |
| Caching / fallback | Throughput and perceived availability. | Whether the fallback path skips a check the invariant depends on. |
| Graceful shutdown | Orderly release of work and connections. | Whether state left behind is consistent with the declared obligations. |
| Health checks / uptime | Process reachability and readiness signals. | Whether a reachable, serving system is actually conformant. |
Degradation failure modes
An operating assumption — latency, error rate, capacity or topology — is breached, but nothing observes it. The system continues as if the assumption still held, and every later decision inherits the error.
A fallback or degraded path preserves throughput by skipping the invariant check, the reconciliation step or the evidence write. Availability is kept by dropping the protection.
The service is still serving, so it is reported as conformant. A successful response is treated as proof that the invariant held, instead of evidence to be observationally checked.
Safe degradation is a published research model plus a labelled simulation. The λ-safe framework describes invariant-preserving degradation constructs at a conceptual level, and the interactive demo includes a deterministic local scenario that follows the model. Neither is production runtime degradation enforcement: deciding, applying and recovering a degraded mode under live conditions is not implemented or verified. The 3–5% overhead reported in the paper is attributed to the paper, not independently benchmarked here.
What is not claimed
Buyers should be able to subtract marketing from a security page. These are the claims NiGeNje deliberately does not make.
NiGeNje makes no certification, regulatory compliance, universal enforcement, hardware-backed attestation or production security guarantee. The platform is pre-product, and the evidence available today comes from a bounded, non-production demonstration chain.
NiGeNje holds no security certification and publishes no certification badge. No SOC, ISO, FedRAMP or equivalent attestation is claimed.
Nothing on this site claims compliance with a regulatory regime or sector framework. Compliance depends on the deploying organisation, its controls and its evidence.
NARG protects registered mediation paths. It is not universal interception of arbitrary shell, direct socket or unwrapped filesystem activity.
Production key management and hardware-backed attestation are not implemented in the reviewed environment. Local demonstration identity and keys are not a hardware root of trust.
The platform is pre-product. No SLA, security warranty, penetration-test result or production assurance is offered or implied by this page.
Safe degradation is a published research model and a labelled simulation on this site. Production runtime degradation enforcement — deciding, applying and recovering a degraded mode under live operating assumptions — is not implemented or verified.
Security evaluation checklist
Use these questions in a technical evaluation. Ask for the evidence behind each answer; a “yes” without a reproducible test, record or demonstration is not evidence.
Security evaluation checklist
This checklist is offered as an evaluation aid. It is not a certification framework and does not imply that every question has a positive answer for NiGeNje.
Direct questions
If a claim cannot be supported by an implementation boundary and an inspected test, it does not belong on this site.
No. NARG is an application-level mediation point for registered agent and tool actions. It does not replace process isolation, container boundaries, network policy or least privilege. A system using NiGeNje still needs host and network controls; the platform adds a governance boundary in front of actions that are routed through it.
If the compromised component can execute outside the registered mediation paths, the current implementation does not constrain that activity. The security argument therefore depends on all material effects being routed through registered adapters and on host controls preventing unregistered execution. That dependency is stated here rather than hidden behind a general security claim.
Per-component evidence chains are ordered and hash-linked, and the chains were verified in the local demonstration chain. That is not the same as tamper-proof. There is no single signed envelope spanning every component, external anchoring is partial, and tamper resistance ultimately depends on the storage, key management and operational controls of the deployment.
None are claimed. No independent penetration test, security audit, certification or third-party attestation is published for this platform. Evaluation evidence referenced across the site comes from internal engineering acceptance work in a bounded, non-production chain.
None are offered on this website. The platform is pre-product. Production qualification, service-level commitments, support terms and deployment guarantees would be defined, if at all, in a separately agreed engagement and are not implied by a demonstration, a form submission or a design-partner conversation.
No. λ-Safe formalizes supported contracts, compiles supported invariants, verifies admissible transitions and refuses what it cannot decide. It does not intercept a live action, revoke a permit or contain a failing dependency. Gatekeeper admits, NARG mediates registered actions, Substrate executes and the Immune Engine contains. The constraint layer and the enforcement layer are deliberately separate.
No. Safe degradation is a published research model with a conceptual description, plus a labelled simulation in this site’s interactive demo. The model describes how a system could reduce non-essential capability while preserving mandatory invariants. Production runtime degradation enforcement — deciding, applying and recovering a degraded mode under live conditions — is not implemented or verified.
Next step
A useful evaluation starts with one action class, one invariant and one failure mode. We will tell you where the current implementation stops.
