Base44 exposed the non-human identity gap in AI platforms

At a glance

What this is: This analysis says Base44 exposed a broader non-human identity gap in AI platforms, where public identifiers and implicit trust replaced authenticated access.

Why it matters: It matters because IAM teams cannot secure service calls, bots, workloads, and AI-driven access flows with human-only controls or user-first assumptions.

Context

Base44’s flaw was not simply a broken login flow. The platform allowed access to private applications through a public app_id, which meant the security model had no effective identity proof for non-human access paths.

That gap matters for NHI governance because modern platforms increasingly blend human users, services, and automated actors in the same access path. When identity is only enforced for people, the platform can still expose sensitive functions, internal APIs, or private applications to unauthenticated non-human requests.

The article’s central point is that the control failure is structural, not isolated. In environments that move faster than human review cycles, security teams need to treat non-human identity as part of the access model itself rather than an add-on to user IAM.

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. That allows unauthenticated requests to reach private functionality, which defeats auditability, least privilege, and offboarding. The fix is not stronger user login alone. It is to require verified identity before any request can traverse into protected application or API paths.

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. Service calls still need their own identity, scope, and revocation model. Without that separation, teams end up protecting the front door while leaving machine-to-machine access governed by assumptions instead of verification.

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. Every entitlement should have an owner, a business purpose, and a planned removal path. Separate human access from service accounts and automation credentials so machine identities do not disappear inside employee workflows. That approach reduces privilege creep and makes revocation far easier during role changes or offboarding.

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.

Technical breakdown

Public identifiers are not identity

A public app_id is a locator, not an authenticator. If a platform accepts that identifier as sufficient to reach private functionality, it has turned metadata into access control. In identity terms, the system is missing cryptographic proof of actor identity, so every request is treated as implicitly trusted. That is why the Base44 issue is better understood as an NHI design failure than a simple application bug. The platform assumed that knowing where to reach the app was equivalent to knowing who or what was calling it.

Practical implication: require proof of identity before any request can reach sensitive APIs or private application objects.

Human IAM controls do not cover service-to-service access

Human IAM tools such as SSO and MFA protect interactive users, but they do not automatically govern services, workloads, bots, or AI-driven components. In the Base44 model, authentication was effectively siloed to users while internal service calls were assumed to be trusted. That creates a split trust model where the front door is protected but the backplane is open. For NHI governance, the critical question is whether every non-human caller is bound to a distinct identity that can be verified, scoped, and revoked.

Practical implication: inventory non-human callers separately from human users and enforce distinct authentication and authorization paths.

Unverified onboarding becomes an access path

If registration and onboarding flows allow account creation or environment entry without verification, an attacker can manufacture legitimacy. In Base44, the issue was not only endpoint exposure but also the absence of identity checks during onboarding into restricted environments. That is a classic NHI lifecycle failure: the system creates an actor relationship without proving who the actor is. Once that happens, privilege assignment, audit trails, and later offboarding all start from a false identity assumption.

Practical implication: bind onboarding, service registration, and environment enrollment to verified identity before any privileges are issued.

Threat narrative

Attacker objective: The attacker objective is to reach private applications and protected platform functionality without possessing a verified identity or valid credentials.

1. Entry occurred when the platform accepted a public app_id as enough to reach private applications, so no credential theft was needed.
2. Escalation followed because the request path lacked identity verification, allowing an unauthenticated actor to interact with protected functionality.
3. Impact was unauthorized access to private applications with no alerting and no credential-based barrier to entry.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Public identifiers are a weak substitute for governed non-human identity. A visible app_id can support routing, tenancy, or lookup, but it cannot carry trust by itself. The broader lesson is that identity proof must be separable from exposure, because anything public will eventually be probed. Practitioners should treat public identifiers as discovery data, not as proof of entitlement.

Identity governance fails when lifecycle controls stop at the human boundary. Service registration, onboarding, privilege assignment, and revocation all need the same governance discipline that IAM applies to people. The article makes clear that when non-human actors are implicitly trusted, the control gap appears before the first user ever logs in. The practitioner conclusion is to govern non-human access as a first-class lifecycle, not as an implementation detail.

Identity everywhere is now a platform design requirement. The article’s strategic point is that access control must move from the edge into every service call, API call, and automated interaction. That aligns with zero standing trust assumptions for non-human access and with NHI governance patterns that bind proof to every request path. The practitioner conclusion is that identity must be enforced at the infrastructure layer, not patched into application logic later.

Implicit trust in automated systems is the new attack surface. When platforms assume that internal calls are trusted, they create a governance gap that scales with automation. That is why NHI programs increasingly need to map trust assumptions, not just assets, because the problem is often invisible until a public or internal identifier is accepted as proof. The practitioner conclusion is to eliminate trust by context and replace it with verifiable actor identity.

What this signals

A platform that treats public metadata as sufficient proof of access is already outside a defensible identity model. The practical signal for IAM and NHI programmes is whether verification exists at every request boundary, not only at human login.

Base44 is a reminder that identity governance has to extend into onboarding, service registration, and automated request handling. When those paths are left implicit, the organisation inherits a trust model that cannot be audited or revoked cleanly.

For practitioners

• 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. Require authenticated proof before any private application or API can respond.
• Verify onboarding before privilege issuance Bind service registration, environment enrollment, and workload creation to a verified actor identity before allowing access to restricted resources.
• Audit trust assumptions in internal calls Look for internal APIs and service-to-service flows that rely on network location, tenant context, or deployment state instead of explicit identity checks.

Key takeaways

• Base44 exposed a structural identity gap because private application access could be reached with a public identifier and no proof of identity.
• The failure matters beyond one platform because human IAM controls do not cover service, workload, and AI-driven access paths by default.
• Non-human identity governance has to start at onboarding and request verification, otherwise private functions remain accessible by assumption rather than entitlement.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.
• Service-To-Service Authentication: A pattern where one application or workload authenticates directly to another without a human in the loop. It is central to modern API-driven systems and depends on machine identity, least privilege, and short-lived credentials. Poor governance here creates broad exposure if a token, key, or certificate is compromised.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.