AppsFlyer’s AI platform strategy highlights trust and accuracy constraints

At a glance

What this is: This is WorkOS’s analysis of how AppsFlyer is embedding AI into internal and customer-facing analytics, with the central lesson that privacy, tenant boundaries, and accuracy determine whether the rollout is usable.

Why it matters: It matters to IAM and identity teams because AI features that touch sensitive data behave like governed access paths, which means NHI, human workflow, and emerging agentic controls all need to align.

👉 Read WorkOS’s analysis of how AppsFlyer is building AI into its platform

Context

AI inside a production platform is not just a product decision. It changes how data is accessed, how outputs are trusted, and how much control the organisation needs around sensitive tenant data. In AppsFlyer’s case, the governance problem is not whether AI can help, but whether AI can operate inside existing privacy and contract boundaries without weakening control.

For identity and access practitioners, the key question is how AI features inherit policy. When intelligence is embedded into dashboards, reports, and alerting flows, the underlying identity and data permissions matter as much as model quality. This is a familiar NHI governance problem with a new user experience layer, and it is increasingly typical for platforms at scale.

Key questions

Q: How should security teams govern AI features embedded in enterprise applications?

A: Treat embedded AI as part of the application’s access model, not as a separate experiment. Scope the feature to tenant boundaries, restrict what data it can retrieve, validate outputs before exposure, and keep logging, approval, and revocation consistent with the base application. If the AI layer can see more than the user should, the control model is already broken.

Q: Why do AI features in analytics platforms create identity governance concerns?

A: They create identity concerns because the AI layer inherits access to sensitive data and can amplify mistakes at production speed. If permissions, tenant isolation, and output validation are weak, the platform can surface the wrong information to the wrong user or automate a bad decision path. That is an access problem, not just a model problem.

Q: What do organisations get wrong about adding AI to existing workflows?

A: They often assume the workflow stays the same and only the interface changes. In practice, embedded AI introduces new data retrieval paths, new trust boundaries, and new failure modes around accuracy and oversight. If those are not governed explicitly, the organisation has added a new access surface without updating the control plane.

Q: When should teams delay customer-facing AI features?

A: Delay release when the model cannot reliably respect privacy boundaries, when outputs are not validated against known outcomes, or when the team cannot explain who is accountable for a bad answer. Customer-facing AI should not go live until the identity and data controls are strong enough to make the feature predictable in production.

Technical breakdown

Tenant isolation in AI-enabled analytics

Tenant isolation means one customer’s data must remain logically and operationally separated from another’s, even when AI systems are summarising or ranking information across large datasets. In a marketing analytics platform, this is not a theoretical control. AI features can unintentionally surface patterns, records, or context from the wrong boundary if data access is too broad, retrieval is poorly scoped, or prompts are constructed against mixed datasets. The control surface spans storage, retrieval, inference, and post-processing. The identity question is who or what can request data on behalf of a user, and under what entitlement model.

Practical implication: bind AI features to the same tenant-scoped access controls that govern the underlying product data.

Accuracy controls for AI-generated insights

AI-generated insights in attribution and analytics are only useful when they are reproducible enough to trust. In this context, accuracy is not just model performance. It includes source traceability, validation against known outcomes, and guardrails that prevent a generated answer from outranking the evidence behind it. If a model confidently misstates attribution, campaign performance, or anomaly detection, the failure becomes an operational risk rather than a UX defect. That is why enterprise AI needs output review, confidence thresholds, and deterministic fallbacks for high-impact decisions.

Practical implication: require validation and fallback paths before AI-generated results are shown to customers or used in decision workflows.

Embedded AI versus standalone AI workflows

AppsFlyer’s approach reflects a common enterprise pattern. AI adoption tends to work better when intelligence is embedded into existing workflows rather than forcing users into a separate chat interface or new operating model. That matters because every new workflow introduces a new identity path, new permissions, and more room for shadow access. When AI sits inside dashboards, reports, and alerts, the organisation can reuse established governance, but only if those controls were already mature enough to handle richer data access and automated assistance.

Practical implication: favour embedded AI features only where existing identity controls and approval paths can already support the added access surface.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

AI features inside enterprise platforms are identity and access problems first, product features second. When the AI layer touches customer data, the real question is not whether the model is useful, but whether the surrounding identity model preserves tenant boundaries, contract limits, and decision accountability. That makes this an NHI governance issue even when no autonomous agent is present. Practitioners should treat embedded AI as a new access path that must be governed end to end.

Tenant isolation is the named control boundary that AI commonly stresses. The moment a platform uses retrieval, summarisation, or proactive insight generation, the risk is no longer only data leakage. It is policy drift across a boundary that was assumed to be stable. The practical implication is that data access, model prompts, and output delivery must all respect the same isolation model, or the governance framework becomes inconsistent.

Accuracy gates matter more when AI is embedded in operational workflows than when it is presented as an experiment. Marketers may tolerate a rough assistant, but they will not tolerate wrong attribution or misranked insights inside a production system. That means the platform must validate outputs before exposure and preserve a clear line between generated suggestion and authoritative result. Practitioners should measure AI features by trustworthiness, not novelty.

Embedded AI reduces the temptation to create shadow AI, but only if governance keeps pace. If the approved platform experience is weak, users will route around it with unsanctioned tools and ad hoc assistants. The lesson for identity teams is that sanctioned AI must be easy to use, tightly scoped, and visibly controlled. Practitioners should design the access model so the approved path is also the safest path.

Named concept: workflow-native AI governance. This is the discipline of placing AI inside existing operational surfaces without creating a separate trust model for data access, permissions, and output use. It is valuable because the control plane stays aligned with the workflow plane. Practitioners should treat workflow-native AI as the standard to test against whenever AI is added to a production platform.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For the lifecycle angle, read Ultimate Guide to NHIs , The NHI Market for how fragmented control planes complicate governance at scale.

What this signals

Workflow-native AI governance: the practical standard is to keep AI inside the application’s existing identity model rather than creating a parallel trust plane. That matters because the moment AI can retrieve, summarise, or rank sensitive data, the control question becomes who can see what, under which tenant boundary, and with what validation. Security teams should align AI rollout gates with the same controls that already govern production access paths.

The programme signal is clear: embedded AI will reward teams that already understand entitlement design, logging, and data boundary enforcement. Where those controls are immature, AI becomes an amplifier for ambiguity rather than a productivity layer. For teams building governed AI into production systems, the baseline remains zero trust thinking, reinforced by the NIST Cybersecurity Framework 2.0.

The stronger the product promise, the more important the governance evidence becomes. If customer-facing AI cannot show where its data came from, how it was validated, and when it should fall back to deterministic logic, the operational risk shifts from isolated bad answers to systemic trust erosion. The next maturity step is not more AI, but more defensible control over AI-enabled access.

For practitioners

• Map AI feature permissions to tenant scope Document exactly which customer records, reports, and attributes each AI feature can retrieve, transform, or surface. Keep the AI access path inside the same tenant isolation rules that govern the base application, and review any retrieval layer that can cross boundaries.
• Introduce output validation for high-impact insights Require confidence thresholds, human review, or deterministic fallback logic before AI-generated attribution or anomaly results are exposed to users. This is especially important where a wrong answer can change customer reporting or operational decisions.
• Reuse existing approval and entitlement controls Avoid creating a separate AI permissions model if the product already has mature role-based access and request approval flows. Extend the current identity model so AI assistance inherits the same review, logging, and revocation mechanisms.
• Watch for shadow AI workarounds If users cannot get fast, governed access through the official workflow, they will move sensitive work into unsanctioned assistants. Track where teams are exporting data into external tools and close the usability gap before it becomes an access gap.

Key takeaways

• AI embedded in a production platform changes the identity problem, because the feature now carries data access, policy scope, and accountability with it.
• Tenant isolation and output validation are the two controls most likely to determine whether AI insights remain safe inside customer-facing workflows.
• Teams that already govern permissions, logging, and revocation cleanly will adopt embedded AI more safely than teams trying to bolt governance on later.

Key terms

• Tenant isolation: Tenant isolation is the control that keeps one customer’s data, permissions, and processing boundary separate from another’s in a shared platform. In AI-enabled systems, it must apply to retrieval, inference, and output paths, not just storage. Weak isolation turns convenience features into data-exposure risks.
• Embedded AI: Embedded AI is AI functionality built directly into an existing application surface such as dashboards, reports, or alerting flows. It differs from standalone assistants because it inherits the application’s identity model, data permissions, and operational risk. Governance succeeds only when the new feature does not outrun the old controls.
• Output validation: Output validation is the process of checking AI-generated results before they are trusted, displayed, or used in decisions. It includes confidence thresholds, source checks, fallback logic, and human review where needed. For production analytics, it is the difference between helpful assistance and incorrect automation.
• Workflow-native AI governance: Workflow-native AI governance means placing AI inside the normal operating workflow while keeping the same rules for access, logging, approval, and accountability. The idea is to avoid a second trust model for AI. In practice, it asks whether the control plane still matches the way work actually happens.

Deepen your knowledge

AI governance in production platforms is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are embedding intelligence into customer-facing workflows, this is the governance baseline worth building from.

This post draws on content published by WorkOS: How AppsFlyer built AI into their platform. Read the original.