Nothing is trusted by default. Not even NEBU.
Every identity proves itself on every request, models only ever see shielded data, and everything runs where your infrastructure runs.
Book a callFollow one request through your boundary.
A service account key has been exposed. This is the path its data takes on the way to a fix.
-
01 Inside your boundary
It starts where your systems are.
NEBU is installed in your own environment, so the finding is read where it lives instead of being copied out to be analyzed.
-
02 Identity check
Every request proves who is asking.
Each call between NEBU’s components is authenticated and authorized for that one action. Being inside your network earns nothing.
-
03 Shielding
Names, addresses and secrets become tokens.
The values that identify you are replaced before any model reads the record. The type of identity, its permissions and its state stay, because the model needs them to reason.
-
04 Private inference
The model reasons on tokens.
It runs on an endpoint inside your boundary and writes its plan in tokens. It never learns which account, host or person it is working on.
-
05 Back to real names
Real names return only inside NEBU.
The tokens are swapped back on NEBU’s side, so the fix your approver reviews names your actual resources.
-
06 Just-in-time access
A credential for one step, then gone.
Once the fix is approved, NEBU borrows a short-lived credential from your privilege or secrets manager, scoped to that one step.
-
07 Recorded
Every step is on the record.
Who asked, what the model saw, who approved, which credential was used, and whether anything crossed the boundary.
Where does NEBU run?
Inside your own environment: on-premises, in your private cloud or fully air-gapped.
All three layers run there, supervision, orchestration and knowledge, on infrastructure you already govern. Your team keeps custody of the platform and of the data it works on.
Your infrastructure data stays in your environment, and so in your jurisdiction.
Models only see shielded data.
Replaced before any model call
- Secrets and key identifiers
- IP addresses and DNS names
- Account, resource and identity names
- Tags and labels
- People’s names and email addresses
Kept, so the model can reason
- Identity and resource types
- Permissions and what they reach
- States and configurations
- Metrics and timings
The same value always becomes the same token, so the model can still tell that two findings involve one host without knowing which host it is.
You decide what crosses your boundary.
You set what may cross, in either direction, and to which tool. Each crossing is recorded and can be revoked, and your team can review them in the NEBU console.
No standing write access, for any identity.
People sign in through your identity provider, and roles decide who may request, approve or only view.
Between fixes, NEBU can only read. Write rights are issued for one step and expire with it.
NEBU’s own team has no access by default. When you grant it, access follows your governance and policies, is limited in time, and every session is recorded.
Raw infrastructure data is never retained or used for training.
Only anonymized and contextualized metadata can help improve NEBU, and only if you opt in under a signed agreement. You can withdraw that consent at any time.
Questions
Which model does NEBU use?
One that runs on a private endpoint inside your boundary. Because every prompt is shielded first, the model is never trusted with your names, addresses or secrets.
Can NEBU run with no internet connection?
Yes. In an air-gapped site, updates arrive as signed offline bundles that your team verifies and imports. Nothing calls out.
What if a part of NEBU is compromised?
It can act only within the single action it was authorized for, it holds no write rights to reuse, and whatever it attempts is recorded.
See where your own estate stands.
A posture assessment is a read-only review of your environment, scoped with your team, with a written report.
Walk your own boundary with us.
On a call, we take one of your findings through your environment and show what each component, and each model, would see.