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

At a glance

What this is: The survey shows consumers are using AI-infused apps while underestimating how much AI now shapes application code and behaviour.

Why it matters: For IAM, security, and app governance teams, the findings highlight a trust and transparency problem that intersects with permissions, data access, and the security controls around AI-assisted development.

By the numbers:

• Only 22% of respondents believe a typical mobile app’s code is mostly AI-generated.
• 47% of consumers say they are concerned about AI in apps.
• 31% of respondents say sensitive data requests top their lists of app concerns.
• 53% of Gen X respondents say official app store presence is the strongest security signal.

👉 Read LEGIT Security's survey findings on consumer trust in AI-built applications

Context

AI-assisted development has changed how applications are built, but consumer trust has not caught up with the reality of AI-shaped code paths, model calls, and data flows. That creates a governance gap: users judge safety through familiar cues, while development teams are adding new dependencies and exposing new data surfaces.

For identity and access teams, the relevant issue is not whether AI appears in the application stack, but whether the application’s permissions, data access, and third-party integrations are governed as tightly as the rest of the software supply chain. Once AI is part of application architecture, access decisions and data handling become part of the security story, not just the engineering story.

The survey suggests this mismatch is typical, not edge-case behaviour, which makes it a broader app security and identity governance problem rather than a niche consumer perception issue.

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 do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

Q: How can organisations tell whether app transparency is credible?

A: Credible transparency explains where AI is used, what data it can access, and how that use affects security, privacy, and user choice. Vague claims about safety are not enough. Teams should be able to show the controls behind the claim, including access limits, retention rules, and testing coverage.

Technical breakdown

Why AI-assisted application development changes the trust model

When AI becomes part of application development, the security boundary moves. Code may be generated faster, but the app still inherits the same access paths, secrets, APIs, and data processing obligations as any other software. The difference is that AI-assisted workflows can introduce opaque changes, hidden dependencies, and faster release cycles that outpace review. That creates a governance problem for security teams because the application may look conventional to users while the internal build and runtime model is no longer conventional at all.

Practical implication: teams need to classify where AI is used in the software lifecycle and tie that to review, testing, and access controls.

Sensitive data requests are now a security and privacy signal

The survey shows sensitive data requests are a primary concern because AI-enabled apps can collect broader input types, including voice, images, location, and behavioural data. From a governance perspective, this is where application security intersects with identity and privacy: if the app can infer, store, or transmit more context, then the permissions model and data handling rules need to be explicit. Users are reacting to the perceived scope of collection, not just the presence of AI itself.

Practical implication: map AI-enabled data collection to least-privilege permissions and clear retention rules before features reach production.

Toxic combinations in AI app development

A key technical risk is not AI code generation alone, but AI combined with weak surrounding controls. If AI-generated code lands in a pipeline without static analysis, branch protection, model output review, or secret scanning, the result is a broader attack surface with fewer brakes. This is a classic compound-control failure: each missing guardrail raises the chance that a fast-moving AI development workflow introduces insecure code or exposes data in ways conventional reviews miss.

Practical implication: treat AI coding workflows as security-critical pipelines and verify that existing SDLC controls still enforce policy.

Threat narrative

Attacker objective: The objective is to exploit expanded application complexity and data handling paths to increase exposure, weaken trust, or bypass normal security expectations.

1. Entry occurs when AI-assisted development introduces code paths or app features that expand data collection, API usage, or third-party interactions beyond what users expect.
2. Escalation happens when weak pipeline controls, missing review gates, or poor data governance allow those changes to reach production without adequate scrutiny.
3. Impact is a trust and exposure problem in which consumers face broader data collection, and teams inherit security and privacy risk from opaque AI-driven application behaviour.

NHI Mgmt Group analysis

AI in applications has become a governance problem, not just a development pattern. Once AI is embedded in code generation, data handling, or runtime decision-making, the security model must account for new dependencies and faster change velocity. Consumer trust is then shaped by whether teams can explain and control those dependencies, not by whether the app claims to use AI responsibly. The practitioner conclusion is that AI visibility must sit inside application governance.

Trust signals are lagging indicators of real security. Consumers rely on app store presence, privacy policies, and brand familiarity because they cannot see the actual control environment. That means app teams must not confuse perceived trust with verified assurance. The practitioner conclusion is that external trust cues need to be backed by access control, testing, and data minimisation.

AI-generated code creates a named control gap: security review latency. The faster teams ship AI-assisted changes, the easier it is for static review, threat modelling, and secret scanning to fall behind the build pipeline. This is where application governance and identity governance intersect, because the same systems that move code also move permissions and data access. The practitioner conclusion is to measure whether review pace still matches release pace.

Consumer concern about sensitive data points to a broader permission discipline failure. Applications that request more data than they need are already fragile, and AI makes that problem more visible because it can justify broader collection and more contextual inference. For IAM and app security teams, the issue is whether permissions are still tied to necessity or have drifted into convenience. The practitioner conclusion is to enforce data and access minimisation together.

What this signals

AI visibility has become an application governance control, not just a development inventory exercise. Teams need to know where AI shapes code, content, and runtime behaviour because that is where assurance breaks first. The practical signal is whether security can trace AI use back to specific permissions, tests, and release gates.

Consumer-facing trust language will matter less than demonstrable control evidence. Privacy policies, app store presence, and brand familiarity still influence perception, but they do not prove secure design. Teams should expect pressure to document data minimisation, permission scope, and testing coverage in language that non-specialists can understand.

The broader pattern is that AI changes both the application attack surface and the governance conversation. As AI-assisted development becomes routine, app teams will need to connect software delivery controls to identity, privacy, and data-handling decisions more explicitly than before.

For practitioners

• Inventory where AI is used in the SDLC Identify which applications, pipelines, and release paths use AI for coding, testing, content generation, or runtime decisions so security review can be scoped correctly.
• Tie app permissions to data necessity Review mobile and web app permissions, third-party integrations, and data collection fields to confirm each one has a specific business purpose and a documented retention rule.
• Harden AI-assisted pipelines with existing controls Apply static analysis, branch protection, secret scanning, and approval gates to AI-generated code exactly as you would for manually written code, with no exceptions for speed.
• Publish plain-language transparency for AI use Disclose where AI affects app behaviour, what data it touches, and whether sensitive inputs are used for model training, personalisation, or routing decisions.

Key takeaways

• AI-assisted apps create a trust gap because users cannot see how much AI shapes code, data handling, or runtime behaviour.
• The survey shows consumers care most about sensitive data requests, which makes permissions and data minimisation central security issues.
• Security teams should govern AI in the SDLC with the same discipline they apply to secrets, testing, and release approvals.

Key terms

• AI-assisted development: A development workflow where an AI system helps generate, refactor, test, or execute code inside the software delivery process. The security issue is not the assistance itself, but that the tool may operate in trusted contexts that also contain credentials, infrastructure access, and other sensitive assets.
• Identity Trust Signal: Any signal that helps a platform judge whether a user, account, or action is genuine enough to proceed safely. These signals can include behavioural history, device context, transaction patterns, and verification status. Strong programmes use them together, not as single-point proof.
• Security Review Latency: The time gap between a code or configuration change being introduced and the associated security review or control catching up. In AI-assisted delivery, this gap can widen quickly and allow insecure patterns, data exposure, or weak permissions to reach production.
• Claim Minimisation: The practice of including only the identity attributes required for a specific access decision. In API security, claim minimisation reduces unnecessary data exposure, simplifies token review, and lowers the risk that broad identity context becomes a hidden authorisation dependency.

What's in the full report

LEGIT Security's full article covers the operational detail this post intentionally leaves for the source:

• Survey methodology and consumer segmentation across age groups and trust signals
• Detailed breakdown of how respondents judged AI-written code, privacy, and app-store credibility
• Vendor guidance on AI visibility, AI-specific testing, and threat modelling for app teams
• Consumer safety checklist covering permissions, passwords, two-factor authentication, and device hygiene

👉 LEGIT Security's full article covers the consumer survey breakdown, developer implications, and practical guidance for app teams.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It is relevant for practitioners who need to connect identity controls to modern software and infrastructure risk.