Notifications
Clear all
Topic starter
06/06/2026 2:25 am
TL;DR: AppsFlyer’s Eran Dunsky says the company is embedding AI into internal tooling and customer-facing analytics while treating data privacy, tenant isolation, and output accuracy as hard constraints, according to WorkOS. The pattern shows why AI features in enterprise platforms must be governed as access-bearing systems, not just product enhancements.
NHIMG editorial — based on content published by WorkOS: How AppsFlyer built AI into their platform
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map AI feature permissions to tenant scope Document exactly which customer records, reports, and attributes each AI feature can retrieve, transform, or surface.
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- How the team embedded AI into internal development tooling without changing the existing engineering workflow.
- The practical UX patterns used to surface AI insights inside dashboards, reports, and alerting systems.
- The implementation constraints around tenant isolation, contractual data-use limits, and output validation.
- The product decisions that helped drive gradual customer adoption without forcing a standalone AI workflow.
👉 Read WorkOS’s analysis of how AppsFlyer is building AI into its platform →
AI inside marketing analytics platforms: what changes for IAM teams?
Explore further
06/06/2026 4:06 am
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.
A few things that frame the scale:
- 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.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
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.
👉 Read our full editorial: AppsFlyer’s AI platform strategy highlights trust and accuracy constraints
