“When not distracted by AI (which, you have to admit, is very distracting), I’ve been thinking a lot about delegation in digital identity. We have the tools that allow administrators or individuals to grant specific permissions to applications and services.”
In theory, it’s a clean model: you delegate only what’s necessary to the right party, for the right time. Consent screens, checkboxes, and admin approvals are supposed to embody that intent.
That said, the incentive structures around delegation don’t actually encourage restraint. They encourage permission grabs and reward broader access, not narrower. And when that happens, what was supposed to be a trust-building mechanism—delegation with informed consent—turns into a trust-eroding practice.
You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.
And be sure to leave me a Rating and Review!
Delegation’s design intent versus product incentives
Delegation protocols like OAuth were designed to solve a simple problem: how can an application act on your behalf without you handing over your password? Instead of giving a third-party app your full login, OAuth lets you grant that app a limited token, scoped to specific actions, like “read my calendar” or “post to my timeline.” In enterprise settings, administrators can approve apps at scale, effectively saying, “this tool can access certain company data on behalf of all our employees.”
The intent is least privilege: give just enough access to accomplish the task, nothing more. Tokens should be narrowly scoped, time-bound, and transparent.
But the product incentives push in the opposite direction. If you’re a developer or growth team, every extra permission opens new doors: richer analytics, better personalization, and potentially more revenue. Why ask for the bare minimum when you can ask for a lot more, especially if you can get away with it?
And so the pattern of permission creep emerges. There is an interesting study of Android apps, for example, shows that popular apps tend to add more permissions over time, not fewer. The reason isn’t technical necessity; it’s incentive alignment. More access means more opportunities, even if it slowly undermines the trust that delegation was supposed to build.
This is scope inflation: when “read metadata from one folder” somehow balloons into “read and write all files in your entire cloud drive.” From a delegation perspective, it looks absurd. From an incentive perspective, it looks entirely rational.
Consent as a manufactured outcome
Let’s talk about “consent.” It’s the shiny wrapper that’s supposed to make delegation safe. The idea is simple: a user sees what’s being requested, makes an informed choice, and either agrees or doesn’t. That’s the theory. In practice, consent is manufactured.
Consent screens are optimized like landing pages. The language is written to minimize friction. The buttons are designed to maximize acceptance. Companies treat “consent rates” the same way they treat sign-up conversions or click-through rates: a metric to push upward.
And the tactics aren’t subtle:
- Dark patterns in consent UIs. Regulators in the EU have formally called out manipulative design in cookie banners and social media interfaces; tricks like highlighting the “accept” button in bright colors while burying “reject” in a subtle link. That’s not neutral presentation. That’s steering.
- Consent-or-pay models. The latest battleground is whether “pay or accept tracking” constitutes valid consent. European regulators have said that if refusal carries a cost, then consent may not be “freely given.” Yet many sites lean into exactly this model: you can either hand over your data or hand over your credit card.
- Consent fatigue. When users see banners, pop-ups, and consent prompts multiple times a day, they stop reading. They click whatever gets them through fastest. At that point, it’s no longer informed consent, it’s consent theater.
Delegation without trust is already fragile. Delegation wrapped in manufactured consent is worse: it’s a contract of adhesion where one party has all the power and the other clicks “accept” because they have no real choice.
If you’d like to dive into the consent debate further, I HIGHLY recommend you follow Eve Maler’s The Venn Factory. She has a great blog series on consent (example here) and an even greater whitepaper (for a fee but totally worth it).
Enterprise delegation and the admin consent problem
It’s tempting to think this is just a consumer problem involving cookie banners and mobile apps. But enterprise delegation has its own set of perverse incentives.
Take Microsoft 365 and Entra ID as an example (though let’s be clear that this is absolutely a common scenario). Enterprises can allow third-party apps to request access to user or organizational data through OAuth. To reduce noise, Microsoft lets administrators “consent on behalf of the organization.” Sounds efficient, right? Fewer pop-ups, fewer interruptions for the workforce, saving time (and time = money, right?).
But that efficiency comes at a cost. Attackers exploit this very model through “consent phishing”: tricking a user or admin into approving a malicious app that requests broad API scopes. Once granted, those permissions are durable and hard to detect. Microsoft now publishes guidance on identifying and remediating risky OAuth apps precisely because the model’s incentives tilt toward convenience over caution.
For administrators, the path of least resistance is to click “Approve for the organization” once and move on. That makes life incrementally easier for everybody: administrators, their users, and the attackers.
Enforcement as a belated correction
If the incentives reward broad access, who actually keeps things in check? Increasingly, it’s regulators and courts.
- In the U.S., the Federal Trade Commission has penalized companies like Disney and Mobilewalla for collecting data under misleading labels or without meaningful consent. The penalties aren’t just financial; they force changes in how products are designed and how defaults are set.
- In Europe, the IAB’s Transparency and Consent Framework—the standard that underpins much of adtech—has faced repeated rulings (see examples here and here) that its consent strings are personal data, that aspects of the framework violate GDPR, and that “consent at scale” is not a free pass. Legal battles continue, but I think the message being sent is pretty obvious: broad, opaque consent mechanisms don’t hold up under scrutiny.
- Regulators have also zeroed in on “consent-or-pay” and dark pattern interfaces, explicitly saying that these undermine the principle of freely given consent.
What’s happening is essentially a regulatory realignment of incentives. If the market rewards permission grabs, fines, and rulings change the cost-benefit equation. In some markets, but not all, the cheapest path is shifting to grabbing less data, not more.
Why this erodes trust
From the individual’s point of view, none of this is subtle. They notice when an app requests more permissions than it should. They notice when every website they visit demands cookie consent in confusing ways (it is SO ANNOYING). They notice when their IT department approves a sketchy app and they’re the ones who end up phished.
The result is trust erosion. Individuals stop believing that “consent” means choice and assume that every request for access is a data grab in disguise. They are probably not wrong.
And once trust is gone, it’s not easily rebuilt. Every new protocol, every new delegation model, has to fight against that backdrop of suspicion.
What good looks like
If delegation and consent are to survive as trust-building mechanisms, they have to look different from how they look today. Here are a few ways to realign the incentives:
- Purpose-bound scopes. Tokens should be tied to specific actions, not broad categories. “Read file metadata for this folder” is a very different ask than “Read all your files.”
- Time-boxed tokens. Access should expire quickly unless explicitly renewed. Long-lived tokens are an incentive to attackers and a liability for providers.
- Refusal symmetry. The “reject” button should be as prominent and easy to click as the “accept” button. Anything less is manipulation.
- Transparent change logs. Apps should publish what scopes they request and why, with a clear history of when those scopes changed. If permissions creep is inevitable, at least make it visible.
- Admin consent boards. In enterprises, app approval should involve more than a single overworked admin. Formal review processes—similar to change advisory boards—can slow down risky delegation without grinding everything to a halt.
- Trust reports. Companies could publish regular “trust reports” that show how delegation and consent are actually being managed. Which apps request what? How often are tokens revoked? How many requests are denied? Turning these into KPIs re-aligns incentives toward trust, not just conversion.
Who actually benefits?
So, back to the original question: who actually benefits from delegation and consent as practiced today?
- Companies benefit from broader access because it feeds product features, analytics, and monetization.
- Attackers benefit when that broad access is abused, because consent tokens and admin approvals often outlive user awareness.
- Regulators benefit politically when they enforce, because they’re seen as protecting consumer rights.
- Users? Users benefit in theory, but in practice, they’re the least likely to see real advantage. Their consent is optimized against, their delegation scopes are inflated, and their trust is constantly eroded.
Delegation and consent were supposed to empower users. Right now, they mostly empower everyone else.
The path forward
Delegation is too valuable to discard; it is definitely having its moment given the complexities of doing it correctly. Consent is too foundational to abandon; the alternative of not asking at all is at least as bad as asking too much. But both need to be reclaimed from the incentive structures that have warped them.
That means treating trust as the KPI, not just consent click-through rates. It means designing delegation flows that prioritize least privilege, not maximum access. It means regulators continuing to push back against manipulative practices, and companies recognizing that the long game is trust, not just data.
If the only people who benefit from delegation and consent are companies and attackers, then the rest of us have been sold a story. And the longer that story holds, the harder it will be to convince users that their “yes” actually means something. If your bosses are having a hard time understanding that, feel free to print out this post and slide it under their office door. They might think a bit more deeply about their decisions going forward.
📩 If you’d rather track the blog than the podcast, I have an option for you! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
[00:00:30] Welcome back to A Digital Identity Digest. Today’s episode is called Delegation and Who Actually Benefits?
[00:00:37] This piece builds on earlier conversations and writing about delegation and digital identity.
[00:00:44] Today, we’ll explore how incentive structures push companies to grab broader permissions than they really need—and how that erodes trust.
The Clean Model of Delegation
[00:00:53] When not distracted by all the AI news—which you have to admit is very distracting—I’ve been thinking a lot about delegation and digital identity.
We have tools that allow administrators or individuals to grant specific permissions to applications and services. In theory, this is a very clean model:
- Delegate only what’s necessary
- To the right party
- For the right time
[00:01:18] Consent screens, checkboxes, and admin approvals are all supposed to embody this principle.
[00:01:24] Unfortunately, incentives don’t encourage restraint. They encourage permission grabs. That reward system favors broader access, not narrower. What should be a trust-building mechanism often turns into a trust-eroding practice.
OAuth and the Design of Least Privilege
[00:01:40] Delegation protocols like OAuth were created to solve a practical problem:
[00:01:47] How can an application act on your behalf without requiring your password?
Instead of handing over login credentials, OAuth allows granting a limited token. Ideally, that token is:
- Scoped to a specific action (e.g., read my calendar)
- Time-bound
- Transparent
[00:02:17] In enterprise settings, administrators can approve apps at scale. That way, employees aren’t asked to answer the same questions repeatedly.
[00:02:28] But here’s the issue: incentives push in the opposite direction.
[00:02:32] Service builders want broader access because:
- More permissions unlock richer analytics
- Data enables personalization
- Extra information can be monetized
[00:02:42] Growth teams treat every consent screen as a conversion funnel to optimize. Why ask for less when asking for more is easier?
[00:02:59] The result is permission creep. Studies of Android apps show that popular apps add permissions over time—not fewer.
Consent in Theory vs. Consent in Practice
[00:03:34] On paper, consent is the safeguard. Users see what’s requested and make an informed choice.
[00:03:48] In practice, consent is manufactured. Consent screens are optimized like landing pages.
- Language minimizes friction
- Buttons maximize acceptance
- Consent rates are tracked as key metrics
[00:04:00] Dark patterns dominate: cookie banners where “Accept All” is bright and obvious, while “Reject” hides as a faint gray link.
[00:04:15] Regulators in Europe have called this out as manipulative.
[00:04:20] Then there are “consent or pay” models: accept tracking or pay for access. Regulators argue this undermines freely given consent.
[00:04:33] And, of course, there’s consent fatigue. Repeated banners train users to click without thinking. What’s left isn’t informed consent—it’s consent theater.
[00:04:46] Delegation without trust is fragile. Delegation wrapped in manufactured consent is worse.
Enterprise Risks and Consent Phishing
[00:05:01] This isn’t just a consumer problem. Enterprise environments like Microsoft 365 and Entra ID carry their own risks.
[00:05:13] Enterprises can let third-party apps request organizational data. To reduce friction, admins can consent on behalf of the entire company.
[00:05:22] Efficient, yes. Dangerous, absolutely.
[00:05:24] Attackers exploit this through consent phishing—tricking admins into approving malicious apps with broad permissions. Once granted, this access is durable and hard to detect.
[00:05:39] Microsoft even publishes playbooks to spot risky OAuth apps, acknowledging the problem.
[00:05:44] But incentives still tilt toward convenience. For overworked admins, approving once feels easier than vetting thoroughly.
Regulatory Realignment of Incentives
[00:06:03] If incentives reward broad access, who reins it in? Increasingly, regulators.
[00:06:11] In the U.S., the Federal Trade Commission has penalized companies for misleading consent practices.
- Disney and Mobilewalla paid fines
- Companies were required to change product design, not just pay penalties
[00:06:26] In Europe, the IAB’s Transparency and Consent Framework has been ruled non-compliant with GDPR. Courts held that consent at scale does not equal valid consent.
[00:06:46] Regulators are also challenging “consent or pay” models, stating they undermine freely given consent.
[00:06:59] This is a regulatory re-alignment of incentives. If the market rewards permission grabs, fines and rulings push companies in the opposite direction—toward less data collection.
The User’s Perspective and Erosion of Trust
[00:07:14] From the user’s point of view, the problem is visible:
- Apps request more permissions than needed
- Cookie banners are confusing
- IT teams approve apps that later lead to phishing
[00:07:46] The result is erosion of trust. Users stop believing that:
- Consent equals choice
- Delegation equals least privilege
[00:07:56] Once trust is lost, it’s hard to rebuild. Every new product must fight against this backdrop of suspicion.
How Do We Fix This?
[00:07:58] So how can delegation and consent become real trust-building mechanisms instead of hollow rituals?
[00:08:04] Here’s a list:
- Purpose-bound scopes: tokens tied to specific actions, not broad categories
- Time-boxed tokens: access that expires quickly unless renewed
- Refusal symmetry: reject buttons as visible and easy as accept buttons
- Transparent change logs: apps publishing history of permission requests
- Admin consent boards: enterprise review panels instead of one pressured approver
- Trust reports: companies disclosing how often requests are denied, access revoked, and policies enforced
[00:09:05] Each of these shifts incentives toward making trust the key performance indicator.
Who Actually Benefits?
[00:09:16] Returning to the original question: who benefits from delegation and consent today?
- Companies: more permissions, more data, more revenue
- Regulators: political capital when stepping in
- Attackers: durable, broad tokens for persistence
- People: benefit mostly in theory, but often remain the least protected
[00:09:57] Delegation and consent were meant to empower users. Today, they mostly empower everyone else.
[00:10:04] But both are too important to discard. They must be reclaimed from warped incentives.
[00:10:18] That means:
- Treating trust as the KPI
- Designing delegation for least privilege, not maximum access
- Regulators continuing to push back against manipulation
[00:10:30] Because if only companies and attackers benefit, we’ve lost the plot.
Closing Thoughts
[00:10:44] If you want to dive deeper, explore the work of Eve Maler at the Venn Factory. Her white paper on consent is a fantastic resource worth reading.
[00:11:06] Thanks again for joining A Digital Identity Digest.
[00:11:17] If this episode made things clearer—or at least more interesting—share it with a friend or colleague. Connect with me on LinkedIn @hlflanagan.
And don’t forget to subscribe and leave a review on Apple Podcasts or wherever you listen. The written post is always available at sphericalcowconsulting.com.
Stay curious, stay engaged, and let’s keep these conversations going.