Base44 exposed the non-human identity gap in AI platforms

At a glance

What this is: Defakto Security analyses Wiz’s Base44 findings and argues they expose a broader non-human identity gap in AI platforms.

Why it matters: It matters because IAM, PAM, and platform security teams need to govern services, bots, workloads, and AI-driven access with identity controls that do not assume a human user is at the keyboard.

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.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Defakto Security's analysis of the Base44 non-human identity flaw

Context

Base44’s failure was not a narrow application bug. It exposed a governance gap where a public identifier could stand in for identity, which is exactly where traditional IAM assumptions stop matching how modern AI platforms behave.

For IAM and platform teams, the issue is that services, bots, workloads, and AI-assisted workflows can now reach sensitive functions without the human-facing controls that usually anchor access decisions. That makes non-human identity governance a baseline requirement, not an advanced add-on.

The article’s central point is that the system trusted context and convenience more than verified identity. That is a familiar pattern in fast-moving platform builds, and it is typically a sign that identity has been treated as a user problem only.

Key questions

Q: What breaks when platforms treat public identifiers as access control?

A: Public identifiers can name a resource, but they do not prove identity. When a platform uses them as a trust signal, attackers can reach private functions without credentials or authentication. The result is an access model that authorises by context rather than by proof, which is especially dangerous for APIs, automation, and AI-enabled services.

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. Non-human actors authenticate through keys, tokens, certificates, and signed requests, often at machine speed. If identity and policy do not extend to those actors, the organisation ends up securing people while leaving automated access paths loosely governed.

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. If an actor can self-register, obtain credentials, or enter a restricted environment without verification, the platform is trusting an identity that has not been proven. That creates a lifecycle gap, not just an authentication gap.

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.

Technical breakdown

Public identifiers are not identity proof

The Base44 issue shows what happens when an application treats a public app_id as a sufficient access signal. A public identifier can name a resource, but it does not prove who or what is requesting access. In non-human environments, that distinction matters because APIs, services, and automated workflows need a verifiable identity boundary before they can be trusted. Without cryptographic binding or authentication, the application is effectively authorising by reference rather than by proof. That creates a structural opening for unauthorised access, especially when internal service calls are assumed to be trusted by default.

Practical implication: require identity proof on every service-facing endpoint, including internal and platform-native APIs.

Registration flows become an attack surface when they self-approve

The article notes that onboarding and registration flows lacked verification, which means a restricted environment can be entered through the front door if the front door does not verify the entrant. For non-human actors, self-registration is especially risky because automation can scale abuse faster than manual review can detect it. When platforms allow services or workloads to create accounts or credentials without strong verification, they turn provisioning into an access path. This is not just an authentication issue. It is an identity lifecycle failure that lets unverified actors enter systems designed to be trusted later.

Practical implication: gate onboarding for services and automated actors with explicit verification and approval controls.

Why human IAM controls stop at the machine boundary

Human IAM patterns such as SSO and MFA protect interactive users, but they do not automatically govern machine-to-machine interaction. Non-human actors often authenticate through API keys, tokens, certificates, or signed requests, and those credentials are only useful if the platform understands what they represent and how they should be constrained. When authentication is siloed to users, services inherit trust by default. That is why the article’s broader warning is so important: the identity layer must extend into infrastructure, not sit only at the login screen.

Practical implication: align service identity, access policy, and lifecycle governance in the same control model used for human access.

NHI Mgmt Group analysis

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.

Non-human identity is the governance layer that human IAM leaves behind: Human IAM controls can secure logins, but they do not govern automated actors that call APIs, create workloads, and exchange credentials outside a browser session. That leaves a gap between user-centric access design and machine-centric execution. The practical conclusion is that identity policy has to follow the actor, not just the account type.

Identity lifecycle is now an infrastructure control, not an admin task: When services can self-register or reach internal functions without verification, onboarding and offboarding are no longer clerical processes. They are security boundaries. If the lifecycle is not explicit, the platform silently trusts actors that were never properly proven in the first place.

Implicit trust in AI platforms creates identity blast radius: The article shows how quickly a missing identity check can expose private applications without alerts or credentials. That is not just a vulnerability. It is a sign that blast radius is being set by architecture, not policy. Security teams should read this as evidence that non-human access needs first-class governance before scale turns convenience into exposure.

From our research:

• 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.
• For the broader control model, see Ultimate Guide to NHIs for lifecycle, rotation, and offboarding guidance that applies once non-human access is recognised as a first-class identity problem.

What this signals

Non-human identity governance is now the default control plane for AI platforms: When a public identifier can unlock private applications, the issue is not just one vulnerable product. It shows that platform teams need to treat service identity, lifecycle, and verification as architectural requirements, not optional hardening. The practical shift is to govern machine access with the same discipline used for privileged human access, while accounting for faster and less visible execution paths.

With 97% of NHIs carrying excessive privileges, according to our research, the Base44 pattern should be read as a warning about blast radius, not just authentication. Teams should expect hidden privilege to remain the default until discovery, access review, and entitlement binding are brought into the same programme.

Identity blast radius: this is the practical measure of how much damage a single exposed identifier can cause when access controls are missing or incomplete. For readers, that means platform governance needs to move from perimeter assumptions to actor-level proof, especially where automation, services, and AI-generated workflows can reach sensitive functions without human friction.

For practitioners

• 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. Prioritise any path that reaches restricted data or admin functions.
• 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. Treat onboarding as a controlled trust decision, not a convenience feature.
• 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. This reduces the chance that a public resource name becomes a stand-in for authentication.
• Extend IAM governance to non-human actors Add service accounts, API keys, workloads, and automated platform actors to the same lifecycle, review, and entitlement governance model used for people. The objective is consistent accountability across all identity types.

Key takeaways

• Base44 showed that a public app_id can become an access key when identity is not enforced for non-human actors.
• The broader risk is architectural: human IAM controls do not automatically secure services, workloads, bots, or AI-driven access paths.
• Teams need explicit verification, lifecycle governance, and cryptographic proof for machine-facing access before platform scale turns convenience into exposure.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software instead of a person, such as a service account, API key, token, certificate, workload identity, or AI agent. In practice, it is the control point that allows machines to authenticate, be authorised, and be governed through their lifecycle.
• Identity Proof: Identity proof is the evidence a system requires before it grants trust to an actor. For non-human access, that usually means cryptographic or authenticated proof, not a name, location, or public identifier. Without it, the platform is making an access decision on assumption rather than verification.
• Identity Blast Radius: Identity blast radius is the amount of damage that can follow from one exposed or over-trusted identity. For machines, it depends on scope, privilege, and reach across systems, because a single weak credential or public identifier can unlock far more than the original entry point suggests.
• Lifecycle Governance: Lifecycle governance is the discipline of provisioning, reviewing, rotating, and revoking access across an identity's life. For non-human identities, it is not an admin afterthought. It is the mechanism that keeps service access, workload access, and automation aligned with current trust and ownership.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Defakto Security: Real-World Lessons Wiz’s Base44 Vulnerability Findings Spotlight a Fixable Gap: Non-Human Identity. Read the original.