Notifications
Clear all
Topic starter
25/06/2026 3:15 pm
TL;DR: Base44 let outsiders join private apps by presenting a visible application ID, showing how static identifiers can be mistaken for identity across AI-powered application workflows, according to Aembit and Wiz Research. The problem is not just one app flaw but a broader governance failure: access decisions cannot rely on possession of a label when NHI and agentic systems need verifiable, context-bound identity.
NHIMG editorial — based on content published by Aembit covering the Base44 identifier-based access issue: AI app access controls that treated an application ID as trust
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Separate routing from authorisation Review application IDs, tenant IDs, and project IDs to ensure they only route requests.
- 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.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of the Base44 registration flow and where the application ID was accepted as trust input.
- Concrete examples of how to distinguish routing identifiers from credentials across AI application workflows.
- A practical list of five controls the vendor recommends for preventing identifier-based access vulnerabilities.
- Related reading that connects this pattern to workload identity, AI agents, and secret misuse.
👉 Read Aembit's analysis of identifier-based access vulnerabilities in Base44 →
Identifier-based access controls: are your AI app controls keeping up?
Explore further
25/06/2026 4:40 pm
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.
A few things that frame the scale:
- 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%.
A question worth separating out:
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.
👉 Read our full editorial: Identifier-based access controls are failing AI app governance
