--- title: What the Instaagent Scam Means for App Developers Everywhere? description: Learn how the Instaagent scam stole user passwords and what it means for app developers building trustworthy, secure products today. image: https://weareaffective.com/hubfs/learning-centre-images/what-the-instaagent-scam-means-for-app-developers-everywhere.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-the-instaagent-scam-means-for-app-developers-everywhere#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What the Instaagent Scam Means for App Developers Everywhere? Table of Contents In 2015 an app called InstaAgent climbed the free charts in the UK and a handful of other countries by promising Instagram users a list of the people who had been looking at their profile. To produce that list it asked for your Instagram username and password inside its own form, sent both in plain text to a server the developer ran, and then posted promotional spam from your account. Apple and Google pulled it within days. App developer scams rarely get more technical than that, which is the uncomfortable part, because it worked on a very large number of people before anyone noticed. > The screen that steals your password looks exactly like the screen that doesn't, which is the whole problem. Nothing was broken into. No encryption was defeated. People typed their credentials in willingly, because the box asking for them looked like every other box that has ever asked for them. We [design and build products for lifestyle brands](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need), and we've been through Apple's review process in the awkward categories, so this episode reads differently to us than it does as a news story. It's a design problem before it's a security problem. What follows is what we changed in how we ask users for things, and what we now refuse to ask for at all. ## What the Instaagent Scam Actually Did The app sold one feature, and Instagram has never offered the data that feature needed. There's no profile view history on the platform, so the list it showed was invented. To make the invention believable, the app had to look connected to a real account, and the simplest way to look connected was to hold the real account's login details. #### A feature that never existed So the login form did the work. It collected the username and password, passed them unencrypted to a server the developer controlled, and used them to post advertising posts from the account in the user's name. People discovered it when their friends started seeing spam on their feeds. A developer inspecting the network traffic found the credentials travelling in clear text, published what he'd found, and both stores removed the app. The behaviour that made it dangerous also made it unremarkable to look at. Third-party Instagram tools were everywhere at the time and plenty of them asked for an account login the same way, because the habit of typing one service's password into another service's app was already normal. That habit is what the scam used. The app didn't need to look suspicious. It only needed to look like the others. This is why we treat a password field in someone else's app as a design failure before anyone has done anything wrong with it. The field teaches a behaviour, and the behaviour is what gets exploited later. ## How App Developer Scams Slip Past Store Review Store review is a short check against a policy list, carried out by someone who doesn't have the source code in front of them and has a queue behind them. It catches what matches a known pattern. A plain login form asking for a well-known service's credentials matched the pattern of hundreds of legitimate apps, so it passed. #### Why app developer scams get through We saw the other side of the same inconsistency on a peer-to-peer currency exchange product we built. Travellers could swap leftover foreign currency with each other at interbank rates and skip the commission. Apple decided the product was a possible vehicle for money laundering because transfers were unlimited, and we had to retrofit compliance we hadn't planned for. Each time the client answered an objection, a new one arrived. They spent real money on legal counsel and compliance work, and there was no route to challenge the pattern. Review attention is uneven, in other words. One queue examined money movement in forensic detail while a credential-harvesting form went through in another. A developer with a well-funded objector can be kept out of the store indefinitely, and a developer with a bad idea that looks familiar can walk in. Treating approval as evidence of safety gets this backwards, for everyone building and everyone downloading. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Why Asking Users for Their Password Is Never Acceptable An app should never ask for the password to a service it doesn't own. There's no version of that request that's safe, because the user can't tell a careful implementation from a careless one, and neither can the store reviewer. If you need access to someone's account on another platform, the platform gives you a proper route for it, and that route exists precisely so the password never leaves the platform. We go further than that with logins we do own. One of the things we always advise clients to look at is a [passive login, where the user puts in a phone number](https://weareaffective.com/app-architecture-design-we-are-affective) or email address and receives a one-time code. Nobody has to remember anything, there's no reset flow to build or abuse, and there's no password sitting in your database waiting to be the reason you appear in a news story. > A password you never collected is a password that can't be stolen from you, and that's the cheapest security you'll ever buy. Credentials are where the damage concentrates. Verizon's 2024 breach report found that 76% of data breaches involved compromised credentials, as [Verizon, 2024](https://gitnux.org/enterprise-mobile-apps-statistics/) sets out. | Login method | User has to remember | Third party sees data | If it leaks | | --- | --- | --- | --- | | Email and password | A password | No | Reused password, many accounts | | Social login | Nothing | Yes, the social platform | Token revoked by platform | | Phone or email code | Nothing | No | Single expired code | | Another app's password | A password | Yes, the app owner | Full account takeover | ## The Collateral Damage to Honest Developers Every scam like this raises the price of asking for anything. The user who got spammed from their own Instagram account carries that into the next app they download, and the next product that asks for an account connection pays for it in drop-off it had nothing to do with. Developers pay again at the store. Our currency exchange client spent on legal advice and compliance work to answer objections that kept moving, and the product's route to market depended on satisfying a reviewer rather than a customer. That cost landed on a small team building something legitimate, because the category had a reputation. If your product connects to another platform, say so in the words users already use. "Sign in with Instagram, we never see your password" is clearer to a nervous person than the technical term for the method. The quiet cost is harder to see. Teams respond to suspicion by adding reassurance, so you end up with padlock icons, trust badges and a paragraph about encryption bolted onto a flow that still asks for too much too early. That decoration moves no one, because the hesitation is about whether the thing you're asking for makes sense at the moment you ask for it, and no badge answers that question. ## Asking for Permission at the Wrong Moment We worked on a map-based fitness social network that connected people for runs and cycle rides. People were dropping off at one specific point, where the app asked them to share their location with a potential running partner. The request itself was reasonable for a product built around meeting up. The timing wasn't, because we were asking before anyone had the chance to have a conversation or learn anything about the other person. So we resequenced it. You see the profile first, then you message through the app, and once you've decided you're comfortable, you share. The flow started following the way trust actually builds between two strangers, rather than demanding the end state up front. Write down every point where your product asks the user for something, then rank those asks by how much trust each one needs. The drop-off that matters is sitting at the top of that list. The pattern holds across permission types. [Apps that wait until a permission makes sense in context](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron) see up to 28% higher grant rates than apps that ask on launch, according to [dogtownmedia.com](https://www.dogtownmedia.com/the-ask-when-and-how-to-request-mobile-app-permissions-camera-location-contacts/). An upfront request also looks like the InstaAgent form looked, which is a demand arriving before any reason to comply. People are feeling okay with stuff until they're not, and the moment of the ask is where that flips. ## Collecting Less Data Than You Technically Could On that same fitness product we had a second problem once location sharing was in the right place in the flow. Sharing a precise pin tells a stranger exactly where you live. Sharing nothing makes the product pointless, because the whole value is finding someone close enough to run with. What we did was [add randomness to the position](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron). You see a vague area rather than a pin, so you can't work out exactly where somebody is, and you still get enough to judge whether they're nearby enough to meet. The decision stays informed and voluntary, and the safety risk goes away without the feature going with it. That's the question we now put to every data request. What's the smallest amount of information that still makes this work? NowSecure's benchmarking found that 77% of analysed mobile apps contain personally identifiable information, reported by [NowSecure](https://deepstrike.io/blog/mobile-security-statistics), and a good share of that is collected because it was available rather than because anything uses it. For each field in your database, name the feature that reads it. Fields with no reader are liability you're paying to store. Data you never collected doesn't leak, doesn't need a retention policy, and doesn't turn into a notification email to your customers two years from now. ## Designing for the Worst-Behaved User on Your Platform The InstaAgent developer was a user of Instagram's ecosystem, behaving as badly as the design allowed. That's the test we apply to products now, and we apply it to every part, because a gap in one part undoes the care in another. We learned that on a dating app. Huge effort went into onboarding, verification and validation, and the client didn't want discovery on the messaging side, so messaging got built generically. The result contradicted itself. All that verification work was designed to keep fake accounts out, and then the messaging feature happily carried the fake, automated messages the verification existed to prevent. > Care in one part of a product is undone by the part nobody examined, and attackers go straight to that part. On an anonymous messaging app we built, the same thinking pushed us the other way. We put authentication right at the front, which goes against how we normally handle login, because the nature of the product meant we had to tie every message back to a specific user on the back end. Messages stayed anonymous to other users. For legal reasons, in cases of abuse or harassment, somebody had to be able to find out who sent what. Both decisions came from asking the same question. What does the worst person on this platform do with what we've built, and what do we do when they do it? ## Building Security Into the Architecture, Not Onto It On a performance coaching survey app we built a multi-layered security model with no traditional API behind it. Only authenticated coach accounts had the rights to create a survey. Each QR code carried a unique key that granted read access to that one survey and nothing else. When a respondent opened the URL we set a cookie and fingerprinted the device, which restricted write access to the responses collection to a single submission per device per survey. That stopped duplicate responses skewing a coach's results, and it stopped any respondent reading what other people had answered. None of it was added later. The [permissions were the structure of the thing](https://weareaffective.com/app-architecture-design-we-are-affective), which is why there was no layer to bolt on at the end. Compare that with the currency exchange product, where the transfer mechanism worked beautifully and the compliance had to be cut back into a finished build. Same team, same care, and a much harder job, purely because of when the question got asked. Borrowed code deserves the same scrutiny and rarely gets it. Only 52% of developers say they always consider security when assessing a new third-party library, against 67% for functionality, according to [Veracode](https://beta.darkreading.com/application-security/79-of-third-party-libraries-in-apps-are-never-updated). That's a self-reported number, so treat it as the optimistic version. ## The Compliance Problem You Did Not See Coming The currency exchange product let travellers swap leftover foreign currency with each other at interbank rates, so nobody paid commission. We built the core transfer mechanism and it did exactly what it needed to do. What we hadn't factored in was anti-money laundering. Apple raised it. Unlimited transfers between parties made the product a possible laundering route, and that was enough to block it. We went back and added several layers we hadn't scoped. 1. Stricter know your customer checks at sign-up 2. Extra security applied to the transfer itself 3. Hard limits on how many transfers any two people could make Each of those changed the product experience, and each one had to be designed into flows that were already built. A limit on transfers between two parties sounds like a database rule until you work out where the user finds out about it and how the app explains why. The lesson we took was that the [rules governing your category are a design input](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design), the same as a user need, and they arrive whether you invited them or not. Find them in discovery, when changing the shape of the product costs a conversation. Find them in review and you're paying lawyers to argue about a build that already exists. ## The Signals Users Read Before Deciding to Trust You Trust only becomes a live question at the point your product asks for something. Someone scrolling a feed isn't deciding whether to trust you, because nothing is being requested of them. The moment you ask for a photo library, a contact list, a payment or a location, their emotional state changes, and the [signals they read are the ones immediately around the request](https://weareaffective.com/learning-centre/how-to-build-a-retention-economics-model-your-board-will-actually-read). Those signals are mostly ordinary. Does the ask arrive at a point where its purpose is obvious? Does the wording match what the app is going to do with it? Is there a visible way to say no and carry on? InstaAgent failed all three and got away with it because the surrounding design was confident and the promise was appealing. Watch a real person reach the highest-stakes request in your product and say nothing. The pause before they tap tells you more than any survey response about the same screen. Hesitation at one of those points has more than one possible cause, so it pays to diagnose before fixing. It can be a comprehension problem, an education gap, or just how you're talking about the product and whether you've clearly explained what you're doing with someone's data or money. Adding reassurance to a comprehension problem makes the screen busier and changes nothing. ## What to Do When Something Goes Wrong You need a route for users to tell you, and most products don't have one. On the anonymous messaging app we added reporting structures inside the product so someone receiving an inappropriate or bullying message could escalate it straight to the client's admin team. Those came in as we got deeper into the project and worked through the safety problems that anonymous messaging creates by its nature. Reporting is the part that keeps working after your assumptions stop. You can't predict every misuse, so build the channel that tells you about the ones you missed. > A product with no way to report harm doesn't have fewer problems, it just finds out about them later. When something does go wrong, the sequence matters more than the apology. 1. Say what happened in plain words, before anyone else says it for you 2. State exactly what was exposed, and what wasn't 3. Give people one clear action to take 4. Fix the thing in the product that made it possible 5. Tell everyone what changed, once it's done That last step gets skipped constantly, and it's the one that rebuilds anything. People forgive a problem that was handled. They don't forgive silence, and they don't come back to a product that treated them as a PR issue. ## Conclusion InstaAgent didn't hack anybody. It asked, and people answered, because the asking looked normal. That's the part worth carrying into your own product, whichever store you're publishing to and whatever your app does. Every request you make trains your users in what's reasonable, and the next person to ask will be relying on that training. So the practical work sits in a handful of decisions. Don't ask for a password you've no business holding, and look at a one-time code instead of storing one at all. Put each request at the point in the flow where its purpose is obvious, the way we had to resequence location sharing on the fitness network. Collect the vaguest version of the data that still makes the feature work. Design the whole product for the worst-behaved person on it, because the dating app taught us what happens when one half is hardened and the other isn't. Find the rules for your category during discovery, not during review. None of this makes a product feel defensive when it's done properly. It makes it feel considered, which is what people are reading for anyway. If you're building something that asks a lot of its users and you want a second pair of eyes on where the trust breaks, [let's talk about your app's trust and permission flows](https://weareaffective.com/get-started). ## Frequently Asked Questions What exactly did the InstaAgent app do? InstaAgent promised to show Instagram users who had been viewing their profile, a feature Instagram has never offered, so the list it displayed was invented. To appear connected to a real account it collected the user's Instagram username and password through its own form, sent them in plain text to the developer's server, and then posted promotional spam from the account. How was the scam discovered? Users noticed when their friends started seeing spam posts appearing on their feeds under their names. A developer then inspected the app's network traffic, found credentials travelling in clear text, and published the findings, after which Apple and Google removed the app within days. Was any hacking or encryption breaking involved? No. Nothing was broken into and no encryption was defeated. People typed their credentials in willingly because the login box looked like every other login box they had ever used. Why didn't Apple's and Google's review processes catch it? Store review is a short check against a policy list, carried out by a reviewer without the source code and with a queue of other apps waiting. A plain login form asking for a well-known service's credentials matched the pattern of hundreds of legitimate apps, so it passed without raising a flag. Why does the article call this a design problem rather than a security problem? The screen that steals a password looks exactly like the screen that doesn't, so users have no visual way to tell them apart. A password field in someone else's app teaches a habit, and that habit is what later gets exploited, which makes it a design failure before anyone has misused it. What should developers avoid asking users for? Developers should avoid asking for another service's credentials inside their own app, because doing so normalises a dangerous behaviour even when their intentions are good. Every in-app password field for a third-party service makes the next scam easier to pull off. Can legitimate apps still run into trouble with store review? Yes, and the inconsistency works both ways. The article describes a peer-to-peer currency exchange product that Apple flagged as a possible money laundering vehicle because transfers were unlimited, forcing the team to retrofit compliance work they hadn't planned for. What can a developer do if store review objections keep coming? In the currency exchange case, each answered objection was followed by a new one, and there was no route to challenge the pattern. The practical lesson is to anticipate compliance questions early and budget for legal counsel rather than assuming an appeal will resolve matters. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.