Identifier-based access controls are failing AI app governance

At a glance

What this is: Wiz Research found that Base44 allowed outsiders into private applications by using a visible application ID as a trust signal, even when SSO was configured.

Why it matters: For IAM teams, this shows how static identifiers can undermine both NHI and human access controls when routing values are allowed to stand in for identity.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Aembit's analysis of identifier-based access vulnerabilities in Base44

Context

Base44 is an AI-powered application development platform, and the issue disclosed by Wiz Research shows what happens when an application identifier is treated as a trust signal instead of a routing value. In practice, possession of the ID let an outsider move through normal registration and into a private app, even where SSO was intended to protect access.

The identity lesson is broader than one platform. As more organisations build and deploy AI-generated applications, they create more places where static labels, tokens, and IDs can be mistaken for actual identity. That weakens both NHI governance and the controls IAM teams depend on to separate routing from authorisation.

The pattern is not unusual. Systems built for speed often skip the extra proof steps that human identity programmes take for granted, then discover that convenience has replaced verification at the exact point where access should be decided.

Key questions

Q: What breaks when an application ID is treated as a credential?

A: Access control collapses because possession of a routing value is no longer separated from proof of identity. That lets an attacker or unauthorised user enter normal registration or enrolment flows without enterprise identity verification. The fix is not more convenience, but a distinct authentication step that cannot be satisfied by the identifier alone.

Q: Why do static identifiers create higher risk in AI application environments?

A: AI application environments often move quickly and reuse templates, making it easy for IDs, labels, and tokens to be copied into places where they were never meant to confer trust. When those values are accepted without context, the system turns convenience into authorisation. That is a governance failure, not just a technical flaw.

Q: How do security teams know if a non-human access flow is actually safe?

A: Look for three signals: the identifier only routes traffic, access depends on runtime-bound proof, and alternate enrolment paths are removed or governed by the same policy as SSO. If any one of those is missing, the flow is still relying on weak trust. Safe NHI access should fail closed when context does not match.

Q: Who is accountable when a private AI app can be joined through a visible ID?

A: Accountability sits with the team that designed the enrolment and authorisation flow, not with the user who followed it. Governance frameworks such as OWASP NHI and zero trust both assume access decisions are explicit, contextual, and reviewable. If a visible ID can bypass that model, the control owner must close the side path.

Technical breakdown

How identifier-based access becomes a trust primitive

An application ID is meant to locate a tenant, project, or environment, not prove who or what is requesting access. The failure happens when the access workflow treats possession of that identifier as sufficient evidence of legitimacy. In NHI terms, this is the same architectural error seen when API keys, service account names, or other static values are accepted without binding to runtime context. Once the identifier is used as an authentication shortcut, the system has already collapsed routing and identity into one step.

Practical implication: separate routing identifiers from authentication decisions and never let possession alone advance access.

Why SSO does not help if there is a side-door registration path

Single sign-on only protects the paths it actually governs. If a platform still allows self-registration, password reset, email verification, or other alternate enrolment flows, an attacker may bypass the enterprise identity path entirely. The control failure is not the absence of SSO, but the existence of a parallel trust path that the main control does not cover. In shared SaaS and AI application models, that kind of side door is especially dangerous because one mistake can affect many tenants.

Practical implication: audit every non-SSO enrolment path and remove any route that can grant access without enterprise identity proof.

Binding workload identity to runtime context

Workload identity only works when the credential is tied to where and how the workload is running. If a token, key, or application ID can be reused from a different host, pipeline, or image without policy rejection, the identity is not really bound to the workload. Runtime binding forces the access decision to consider location, posture, and legitimacy at the moment of use. That is the difference between a label and a trustworthy identity assertion.

Practical implication: make access conditional on runtime posture and environment, not on a reusable static value.

Threat narrative

Attacker objective: The attacker’s objective is to obtain unauthorised access to private AI application tenants by abusing a static identifier that the platform mistakenly treats as proof of identity.

1. Entry occurred when the attacker used a publicly visible application ID from URLs or configuration files to begin the registration process for a private app.
2. Escalation followed when the platform accepted email confirmation and allowed access through a trust path that did not require enterprise identity proof.
3. Impact was unauthorised access to private applications in a shared infrastructure model, creating tenant-wide exposure from a single weak control.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

Static identifiers are not identity, and treating them as such creates a governance blind spot. The Base44 issue shows the same failure mode that appears across NHI programmes when an application ID, tenant ID, or service label is allowed to advance trust. That design assumes possession equals legitimacy, which is not a defensible identity assumption. Practitioners should treat this as a routing-versus-authentication separation problem, not a one-off platform bug.

Shared infrastructure magnifies identifier-based trust failures. In a multi-tenant AI application model, one weak enrolment path can expose all customers to the same control failure. That is why the issue belongs in NHI governance discussions as well as application security reviews: the control gap sits at the boundary where tenant identity, enrolment, and authorisation are supposed to stay separate. The implication is that platform teams must stop assuming shared services can safely reuse the same trust primitive everywhere.

Identifier trust debt is the right named concept for this pattern. It describes the accumulated risk created when systems repeatedly use static values as if they were proof of identity. The debt compounds as AI-generated apps, service accounts, and machine workflows multiply faster than governance can verify them. Practitioners should recognise that each shortcut adds more future exposure than immediate convenience.

Human identity controls have already moved past single-factor trust, but many non-human flows have not. Human IAM programmes now expect multiple signals before access is granted, yet NHI and AI application workflows often still accept a token, key, or label with minimal context checking. That gap is where attackers live: the governance model is mature on paper, but inconsistent in machine-facing execution. Practitioners should re-evaluate whether their identity assurance standards are being applied uniformly across actor types.

AI application development is expanding the surface area where identity shortcuts get normalised. As organisations build faster with LLM-powered tooling, the temptation is to keep access pathways lightweight and permissive. That speeds delivery, but it also increases the number of places where access logic can drift from actual identity proof. Practitioners should assume that AI app sprawl will widen the trust boundary unless policy is enforced at runtime.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• That is why the OWASP NHI Top 10 remains relevant as a forward-looking lens for teams separating identity from static labels and routing values.

What this signals

Identifier-based trust debt: the more places an organisation lets a static label stand in for identity, the more likely it is that a simple routing value will become an authentication shortcut. For teams working on AI app governance, that means the next control failure may be architectural, not operational, and the answer is to harden the trust boundary before app sprawl makes it harder to unwind.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, the market is signalling that machine-facing identity needs its own governance model. The practical change for readers is to treat AI app enrolment, workload identity, and runtime posture as one control plane instead of three separate problems.

The same control logic is now appearing across NHI, agentic AI, and human identity programmes: access should be asserted, verified, and continually checked rather than assumed from a visible identifier. Teams that keep routing and trust separate will be better positioned to absorb AI app growth without expanding their attack surface.

For practitioners

• Separate routing from authorisation Review application IDs, tenant IDs, and project IDs to ensure they only route requests. If possession of the identifier can move a requester into an auth flow, add an independent proof step before any access decision.
• Eliminate alternate enrolment paths Disable self-registration, password reset, and other side doors for private applications unless they are bound to enterprise identity and the same policy controls as SSO.
• Bind credentials to runtime conditions Require workload identity checks to evaluate host, pipeline, image, and posture before granting access. A credential reused outside its intended runtime should fail policy evaluation.
• Audit AI app trust assumptions Map every place where AI-generated apps or vibe coding platforms use static values for trust. Focus on places where a label, token, or ID has quietly become the authentication mechanism.

Key takeaways

• Base44 shows how a visible application ID can become an unauthorised access path when identity and routing are collapsed into one control.
• The risk is broader than one platform because AI app sprawl increases the number of places where static values can masquerade as proof of identity.
• Practitioners should separate routing from authentication, remove alternate enrolment paths, and bind non-human access to runtime context.

Key terms

• Application Identifier: A value used to route a request to the correct tenant, project, or application. It is not proof of identity. In secure identity design, an application identifier should be treated as metadata unless it is bound to a separate authentication and authorisation step.
• Identifier-based Access: A trust pattern where possession of a visible label, key, or ID is enough to move a request forward. This is fragile in NHI and AI application environments because static values can be copied, guessed, or exposed without any real proof of legitimacy.
• Runtime-bound Identity: An identity model that ties access to the actual execution environment at the moment of use. It checks where the workload is running, whether its posture matches policy, and whether the requested action fits the approved context before granting access.
• Side-door Enrollment: Any alternate access path that bypasses the main enterprise identity flow, such as self-registration, password reset, or ad hoc invitation mechanics. Side doors are risky because they often escape the same assurance checks as SSO and can quietly become the real entry point.

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 building or maturing an IAM programme, it is worth exploring.

This post draws on content published by Aembit covering the Base44 identifier-based access issue: AI app access controls that treated an application ID as trust. Read the original.