Notifications
Clear all
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.
NHIMG editorial — based on content published by Defakto Security: Real-World Lessons Wiz’s Base44 Vulnerability Findings Spotlight a Fixable Gap: Non-Human Identity
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when platforms treat public identifiers as access control?
A: Public identifiers can name a resource, but they do not prove identity.
Q: Why do non-human identities complicate traditional IAM models?
A: Traditional IAM is designed around interactive users, browser sessions, and human-centric controls such as SSO and MFA.
Q: What do security teams get wrong about service onboarding?
A: They often treat service onboarding as an operational shortcut instead of a security boundary.
Practitioner guidance
- Inventory every service-facing endpoint List APIs, internal calls, onboarding flows, and automation hooks that currently rely on public identifiers, environment trust, or naming conventions instead of verified identity.
- Remove self-approval from onboarding flows Require explicit verification before services, workloads, or AI-enabled actors can create accounts, obtain credentials, or enter restricted environments.
- Bind access to cryptographic proof Replace implicit trust with request-level identity proof so that each call can be evaluated against a known actor and policy boundary.
What's in the full article
Defakto Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific Base44 request path and why a public app_id was enough to expose private applications.
- The practical examples Defakto uses to show where identity checks were missing across onboarding and API access.
- The team-ready control shifts for enforcing proof of identity on non-human access paths.
- The article's broader defensive checklist for finding hidden trust assumptions in AI-enabled platforms.
👉 Read Defakto Security's analysis of the Base44 non-human identity flaw →
Base44 and AI platform identity gaps: what IAM teams missed?
Explore further
25/06/2026 10:17 am
Public app identifiers are a broken trust primitive for modern platforms: A public app_id was treated as enough context to grant access, which means the system was authorising by name rather than by identity proof. That pattern collapses once services, bots, and AI-assisted workflows can reach the same interfaces as users. The implication is that platform teams must stop treating visible resource identifiers as authentication signals.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most teams are governing machine identities without complete inventory data.
A question worth separating out:
Q: Who should own non-human identity governance in an organisation?
A: Ownership should be shared across security, IAM, platform engineering, and the teams that operate the workloads, but it must be assigned explicitly. Non-human identity governance fails when no one owns lifecycle, entitlement review, and access proof for services, bots, and automated workflows. Clear accountability is the control that prevents hidden trust from accumulating.
👉 Read our full editorial: Base44 exposed the non-human identity gap in AI platforms
