Consumer trust in AI-built apps is lagging behind their use

At a glance

What this is: LEGIT Security’s survey finds that consumer trust in AI-built apps is lagging behind adoption, with many users unsure how much AI is involved and many concerned about sensitive data exposure.

Why it matters: IAM, AppSec, and product security teams need to treat AI disclosure, data handling, and permission scope as trust controls because consumer confidence now depends on how apps use AI, not just whether they use it.

By the numbers:

• Only 22% of respondents believe a typical mobile app’s code is mostly AI-generated.
• Nearly 90% of developers surveyed report using AI coding assistants.
• 47% of respondents say they are concerned about AI in apps.
• 31% of respondents say sensitive data requests top their list of app concerns.

Context

AI-assisted development has moved from experimentation to routine delivery, which means software teams are no longer just managing code quality but also the trust signals that surround how applications are built and what data they collect. In this context, consumer perception becomes a security and governance issue because AI is increasingly embedded in application architecture rather than sitting outside it.

The governance gap is not whether AI exists in software, but whether users understand where it is used, what it touches, and how much data is being exposed to support it. That gap matters to application security, privacy, and identity teams because consent, disclosure, access scope, and data minimisation now affect trust in the product itself.

Key questions

Q: How should security teams govern AI use in developer tooling?

A: Security teams should govern AI use as a data and access problem, not only a productivity feature. Define what information can be sent to models, require human review of generated code, and apply least privilege to connected repositories and tools. Approved use cases should be explicit, monitored, and revisited as model capabilities expand.

Q: Why do AI-built apps raise trust concerns for consumers?

A: Consumers cannot directly see how much AI shaped the app, what data it consumes, or whether AI changed the underlying permission model. Trust therefore depends on transparency, privacy discipline, and whether the application requests only the data it genuinely needs. When those signals are weak, users assume the security model is also weak.

Q: What mistakes do AppSec teams make when they treat AI as a separate silo?

A: They usually overvalue narrow AI scanners and undervalue the surrounding application graph. That leads to duplicate alerts, poor severity ranking, and weak remediation because the team cannot see how the AI component interacts with APIs, code, secrets, and infrastructure.

Q: Should organisations change identity and access controls for AI-enabled apps?

A: Yes, when AI features fetch data, call tools, or act on behalf of users or the application, access control must cover those machine-mediated paths. That means limiting privileges, scoping data access tightly, and reviewing delegated access with the same discipline used for other non-human workflows.

Technical breakdown

AI in the application build path changes the security boundary

AI-assisted coding is not just a productivity layer. When code generation, model calls, and data retrieval become part of software delivery, the attack surface expands into the build pipeline, runtime behaviour, and user-facing trust model. That creates a mixed security problem: traditional application controls still matter, but teams also need visibility into where AI is used, what data it can access, and whether the resulting behaviour is predictable enough to govern. In practice, the application is no longer only executing code. It is also mediating model-driven decisions, external tool calls, and new data flows.

Practical implication: Treat AI usage in the software supply chain as part of application inventory and threat modelling, not as a separate innovation track.

Consumer trust now depends on disclosure, data scope, and permission design

The survey shows that users look for security signals they can understand, such as privacy policies, official app stores, and familiar brands. That means app trust is being judged through visible governance cues, not only through technical hardening. From an identity and access perspective, this is where permission scope, data minimisation, and consent design matter. If an app requests broad access or unclear data handling, users read that as risk, especially when AI is involved. The security issue is not only whether data is protected, but whether the product creates the impression of over-collection or opaque processing.

Practical implication: Align permissions, consent prompts, and privacy language so that user-facing trust signals match the actual data-processing model.

AI-specific app risk includes toxic combinations, not just model flaws

Legit’s article points to a useful idea: AI use becomes more dangerous when it combines with other weaknesses such as missing static analysis, weak branch protection, or poor discovery of where AI is embedded. That is a governance problem, not just a model problem. The same principle applies to identity-adjacent controls when AI systems fetch data, call tools, or touch sensitive records. A permissive app architecture can turn routine AI-assisted features into exposure paths if access boundaries are not explicit and monitored.

Practical implication: Review AI-enabled delivery pipelines for control gaps that only become visible when AI features are combined with weak code and access governance.

Threat narrative

Attacker objective: Exploit weakly governed AI-enabled app paths to reach sensitive data or create a user-visible security failure that undermines trust.

1. Entry begins when AI-generated or AI-assisted development introduces new code paths, data flows, and tool connections into the application stack.
2. Credential or data access expands when those paths can fetch sensitive data, call external services, or operate with permissions broader than the feature actually needs.
3. Impact occurs when users lose trust, sensitive data is exposed, or an AI-related weakness becomes a visible app security failure that changes adoption and brand confidence.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-assisted software delivery has become a trust governance problem, not only a development productivity trend. Once AI is part of the build path, organisations must govern what the software can do, what data it can touch, and what users are told about those choices. That shifts the conversation from code generation to control design, because transparency and permission scope now influence whether the product is considered trustworthy. The practitioner conclusion is simple: AI visibility belongs in application governance.

Consumer trust is now a security control signal, not a marketing outcome. Users are reading privacy policies, app store presence, and brand familiarity as proxies for whether an app is safe. That means security and privacy teams need to treat those signals as part of the control environment, especially when AI features increase data collection or automated processing. The practitioner conclusion is to make disclosure, consent, and data minimisation reflect the actual operating model.

AI-generated code creates an AI governance debt if teams do not know where it was used. The risk is not the presence of AI itself but the lack of inventory, review, and boundary-setting around AI-enabled workflows. That debt accumulates quickly when development teams rely on assistants while application governance still assumes human-authored code paths. The practitioner conclusion is to close the visibility gap before it becomes a permanent assurance problem.

AI-built apps widen the identity and access question because models often act on behalf of the user or the application. When an app fetches data, calls tools, or personalises behaviour through AI, access decisions are no longer limited to human login events. That creates a need to govern machine-to-machine access, delegated permissions, and data scope with the same discipline used for other privileged application interactions. The practitioner conclusion is to extend IAM and AppSec review to AI-mediated access paths.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: AI Security Platform Buyer's Guide

What this signals

AI governance debt: organisations that cannot inventory where AI is used will struggle to prove that model calls, AI-generated code, and runtime data access are properly controlled. That gap becomes sharper when AI features are combined with weak branch protection or missing static analysis, because the security problem is then a control design failure rather than a coding issue.

For practitioners, the next question is not whether AI is present in the stack but whether the surrounding controls reflect that reality. Discovery, permission scoping, and AI-specific testing need to move together, because a feature can be trustworthy to users only when the underlying data handling is both explainable and constrained.

For practitioners

• Inventory AI usage across the software lifecycle Map where AI coding assistants, model calls, and AI-driven features are used in development, testing, and production so that governance covers the full path.
• Tighten data minimisation for AI-enabled features Review whether AI-powered functions really need access to voice, images, location, behavioural data, or other sensitive inputs before they are exposed.
• Align user-facing trust signals with real controls Make privacy notices, app permissions, and consent language consistent with how the application actually processes data and uses AI.
• Add AI-specific security testing to AppSec gates Test for model poisoning, excessive agency, unexpected tool use, and other AI-specific weaknesses alongside standard code and dependency checks.
• Review toxic combinations in delivery pipelines Identify places where AI-generated code combines with missing static analysis, weak branch protection, or broad runtime permissions.

Key takeaways

• AI-built apps are changing the trust boundary because users judge safety from disclosure, permissions, and data handling, not only from code quality.
• Consumer concern is already visible in the survey results, and sensitive data requests are a stronger warning sign than many teams assume.
• The practical response is to inventory AI usage, narrow data access, and align user-facing privacy signals with the real operating model.

Key terms

• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
• Toxic Risk Combinations: Toxic risk combinations are unsafe interactions between datasets, access permissions, and AI workflows that only become problematic when combined. Individually they may appear harmless, but together they can expose sensitive information, enable re-identification, or create unintended inferences that traditional controls may miss.
• AI visibility: AI visibility is the ability to identify which AI tools are active, who is using them, and what data they can reach. In security practice, it is the prerequisite for policy enforcement because you cannot control usage, data flow, or risk when the environment is opaque.
• Human-Agent Trust Exploitation (ASI09): An attack where an AI agent's fluency and apparent authority are weaponised to manipulate human users into approving harmful actions, exploiting the tendency to over-trust confident AI outputs.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle management. It helps practitioners connect identity controls to the wider security decisions that shape trustworthy digital services.