Topic starter
25/06/2026 1:06 am
TL;DR: Wiz’s Base44 findings show that private apps could be accessed with only a public app_id, with no authentication, no SSO, and no identity verification, according to Defakto Security. The lesson is broader than one platform: when non-human actors drive access, human IAM controls stop being a sufficient security model.
Editorial analysis by NHI Mgmt Group, based on content published by Defakto Security: “Wiz’s Base44 Vulnerability Findings Spotlight a Fixable Gap: Non-Human Identity”.
Key questions
Q: What breaks when private applications can be reached with only a public app_id?
A: Access control breaks because the identifier becomes a lookup key rather than proof of entitlement.
Q: Why do human IAM controls fall short for service-to-service access?
A: Human IAM controls are built for interactive users, so they authenticate a person rather than a workload, bot, or automated actor.
Q: How should security teams handle onboarding so it does not create NHI sprawl?
A: Treat onboarding as a controlled access lifecycle, not an administrative checklist.
Practitioner guidance
- Map every non-human access path Inventory service calls, bot interactions, workload credentials, and AI-driven requests separately from human logins so you can see where identity is missing.
- Remove public identifiers as access proof Treat app IDs, object names, and environment labels as routing data only.
- Verify onboarding before privilege issuance Bind service registration, environment enrollment, and workload creation to a verified actor identity before allowing access to restricted resources.
Bottom line: Base44 exposed a structural identity gap because private application access could be reached with a public identifier and no proof of identity.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:17 am
Base44 exposed an identity boundary problem, not just a platform bug. The article shows what happens when non-human actors are allowed to reach private functions without a verified identity layer. That failure matters because the access model was designed around human logins, then stretched to cover automated and service-driven access without redesign. The practitioner conclusion is simple: if a platform cannot distinguish a legitimate non-human actor from a random request, it has not implemented identity at all.
A question worth separating out:
Q: How should IAM teams decide which access requests can be automated?
A: Start by classifying requests by sensitivity, entitlement scope, and business impact. Routine access with clear role alignment can often be delegated to an AI-assisted workflow, but privileged, cross-functional, or unusual requests should stay under human review. The key test is whether the policy is explicit enough to support a repeatable decision.
👉 Read our full editorial: Base44 exposed the non-human identity gap in AI platforms