Why Meta wraps risky platform APIs

Some operating system functions and third-party APIs are easy to misuse in ways that compromise security. Meta’s answer is to wrap or replace those functions with its own secure-by-default frameworks. These frameworks help security and software engineers keep the codebase safe without sacrificing developer speed.

Building such a framework on top of Android APIs, for instance, requires a careful balance among security, usability, and maintainability. With AI-driven tools and automation, Meta can now scale framework adoption across its large codebase. AI helps identify insecure usage patterns, suggests secure replacements, and monitors compliance, accelerating migration and enabling consistent security enforcement at scale.

Designing these frameworks for thousands of developers shipping widely different features across multiple apps means weighing competing concerns: discoverability, usability, maintainability, performance, and actual security benefit. Developers only have so much time each day, so the goal is to improve security while staying largely invisible and friction-free.

Getting the balance wrong has real consequences. A framework that improves security but introduces three new concepts and requires five extra inputs per call site will push some developers to find workarounds. Conversely, a framework that is trivial to use but consumes noticeable CPU and RAM will also get avoided, just for performance reasons. Those examples come from real experiences developing around 15 secure-by-default frameworks for Android and iOS over the last decade-plus. That experience produced a few core design principles.

  • The secure API should resemble the existing API. This lowers cognitive load for users, forces framework developers to minimize complexity, and makes automated code conversion from insecure to secure usage easier.
  • The framework should build on public and stable APIs. OS vendor and third-party APIs change constantly, especially non-public ones. Even when private API access is technically possible, relying on it leads to constant fire drills or, worse, dead-end investment in frameworks that cannot work with newer OS and library versions.
  • The framework should maximize coverage of application users, not security use cases. Not every security issue deserves its own framework, but each framework should work across all apps and OS versions for a particular platform. Smaller libraries are faster to build, deploy, maintain, and explain.

SecureLinkLauncher: a case study in intent scoping

SecureLinkLauncher (SLL) is one of Meta’s most widely used Android security frameworks. It prevents sensitive data from leaking through the Android intents system by wrapping native intent-launching methods with scope verification and security checks. SLL specifically targets intent senders.

SLL’s API closely mirrors the familiar Android Context API for launching intents, including methods like startActivity() and startActivityForResult(). Instead of calling the potentially insecure Android API directly, such as context.startActivity(intent), developers use SecureLinkLauncher.launchInternalActivity(intent, context). Internally, SLL delegates to the stable Android API, ensuring every intent launch is verified and protected.

public void launchInternalActivity(Intent intent, Context context) {
   // Verify that the target activity is internal (same package)
   if (!isInternalActivity(intent, context)) {
       throw new SecurityException("Target activity is not internal");
   }
   // Delegate to Android's startActivity to launch the intent
   context.startActivity(intent);
}

Similarly, SecureLinkLauncher.launchInternalActivityForResult(intent, code, context) replaces the direct call to context.startActivityForResult(intent, code). SLL enforces scope verification before delegating to the native Android API, preserving familiar semantics while providing security by default.

The most common way data spills through intents is incorrect targeting. An intent that does not specify a package can be received by any app with a matching <intent-filter>. A developer might intend their implicit intent to reach the Facebook app based on a URL, but any app—including a malicious one—can register an <intent-filter> for that URL and intercept it.

Intent intent = new Intent(FBLinks.PREFIX + "profile");
intent.setExtra(SECRET_INFO, user_id);
startActivity(intent); 
// startActivity can’t ensure who the receiver of the intent would be

In the example below, SLL ensures the intent is directed only to one of the family apps, as specified by the developer’s scope for implicit intents. Without SLL, such intents can resolve to both family and non-family apps, potentially exposing SECRET_INFO to third parties. Enforcing the scope prevents that leak.

SecureLinkLauncher.launchFamilyActivity(intent, context); 
// launchFamilyActivity would make sure intent goes to the meta family apps

In a typical Android environment, an internal scope (within the same app) and an external scope (between different apps) might seem sufficient. Meta’s ecosystem, however, spans multiple apps—Facebook, Instagram, Messenger, WhatsApp, and their variants like WhatsApp Business. Inter-process communication between these apps demands finer-grained intent scoping. SLL therefore provides scopes tailored to specific use cases:

  • Family scope: Limits intent sending to other Meta-owned apps.
  • Same-key scope: Restricts sending to only Meta apps signed with the same key, since not all Meta apps share a signing key.
  • Internal scope: Restricts sending within the same app.
  • Third-party scope: Allows sending to external apps while preventing Meta apps from handling those intents.

These scopes let developers share sensitive data securely and intentionally within the Meta ecosystem while defending against unintended or malicious access.

Using generative AI to migrate at scale

Adopting frameworks across a large codebase is not trivial. The main difficulty is choosing the correct scope, because that choice depends on information not readily available at existing call sites. A deterministic static analysis that infers scope from dataflows would be a major undertaking with likely precision-versus-scalability trade-offs.

Meta instead turned to generative AI. AI can read the surrounding code and infer scope from variable names and nearby comments. The approach is not always perfect, but it does not need to be—it only needs to produce good-enough guesses that code owners can accept with a one-click patch review.

This work complements AutoPatchBench, a benchmark Meta recently released for evaluating AI-powered patch generators that use large language models to automatically recommend and apply security patches. Secure-by-default frameworks are exactly the kind of code modification an automatic patching system can apply to harden a codebase.

Meta built a framework using Llama as the core technology. It identifies migration targets in the codebase and suggests patches for code owners to accept:

Prompt creation

The workflow starts with a call site to migrate, identified by file path and line number. That location is used to extract a code snippet from the codebase: the file is opened and 10–20 lines before and after the call site are copied into a prompt template. The template contains general migration instructions, similar to what would be written as an onboarding guide to the framework for human engineers.

Generation

The prompt goes to a Llama model (llama4-maverick-17b-128e-instruct). The model outputs two things: the modified code snippet with the call site migrated, and optionally a set of actions, such as adding an import to the top of a file. Actions work around the limitation that all code changes are local to the snippet; they let the model reach outside it for limited, deterministic changes like adding imports or dependencies that are necessary for compilation but rarely local. The snippet is then inserted back into the codebase and any actions are applied.

Validation

The modified code goes through several validations, run with and without the AI changes so only the difference is reported:

  • Lints: Confirm the original lint issue is fixed and no new lint errors were introduced.
  • Compilation and tests: Compile and run tests covering the targeted file. This is not meant to catch all bugs—continuous integration handles that—but gives the AI early feedback on issues like compile errors.
  • Formatting: Code is formatted to avoid style issues; formatting errors are not fed back to the AI.

If any validation step fails, the error messages are added to the prompt alongside the “fixed” snippet and the AI tries again. This loop repeats up to five times before giving up. On successful validation, a patch is submitted for human review.

Design Principles That Make Frameworks AI-Ready

Successful secure-by-default frameworks share a few core traits that also make them amenable to AI-assisted adoption. An API that closely follows existing OS patterns, reliance solely on public and stable OS APIs, and a design aimed at broad user bases rather than niche cases all contribute to frameworks that drop into existing codebases cleanly. These same characteristics turn out to be what an LLM needs to perform reliable, large-scale migrations.

Accuracy of generated code remains a hurdle — an AI may pick the wrong API scope or stumble on syntax. However, an internal feedback loop in the migration pipeline lets the model detect and correct the trivial failures on its own. The automation only escalates genuinely novel problems to a human, which both cuts down on developer frustration and improves the scalability of the whole effort.

Validation Lessons From the Field

The real-world exercise of adopting security frameworks across a large, diverse codebase demonstrated that AI can handle this work with minimal disruption to developers. In fact, the validation approach itself proved more instructive than the AI improvements alone. The experience highlighted two key principles for applying AI to code migrations: at validation time, measuring output quality against a secure, ideal baseline can be deceiving; and combining code review with hidden tests, each with clear criteria, creates a powerful feedback loop that helps flag clear, satisfying failures early for the model to rollback and retry.

Strict, centralized validation also helps manage migration errors before they slow down feature work. Detection of anomalous diffs by platform engineers — well before developers feel downstream effects — smooths out the rollout. When security automation triggers noisy failure outputs, developers can get fatigued by repetitive manual review; a curated validation pipeline mitigates that.

What the Trajectory Suggests

The work proved AI can meaningfully drive security framework adoption across heterogeneous codebases, and the pattern is now being replicated on similar problems in C/C++ and other languages, using varied models and validation techniques. Expect that trend to accelerate through 2026 as developer comfort with state-of-the-art AI tools grows, and as the quality of generated code continues to improve.

As codebases expand and the threat landscape sharpens, the pairing of careful framework design with intelligent automation will be central to keeping user data protected and trust intact at scale.