Security and trust
Security claims should follow the implementation boundary. This page states what the NiGeNje control path enforces, what is only partially implemented 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
Boundary 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.
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.
Buyer 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.
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.
