Does AI itself need auth? What kind? Can vanilla auth work?

To answer these questions, we need to understand how and where AI might operate, and to do that, we need to study applications.

‍

The apps that thrive in AI

A year ago this month Bill Gates wrote “AI is about to completely change how you use computers”

In the next five years … you won’t have to use different apps for different tasks. You’ll simply tell your device, in everyday language, what you want to do. And depending on how much information you choose to share with it, the software will be able to respond personally because it will have a rich understanding of your life. In the near future, anyone who’s online will be able to have a personal assistant powered by artificial intelligence that’s far beyond today’s technology.

While the model layer appears on a path to commoditization, there’s growing interest in the application layer. But per Bill, in five years the application layer won’t exist. Which is it?

It appears the application layer is on its way to more natural interfaces. Instead of clicking through menus we’ll just ask for what we want.

But then you might wonder – what exactly is an app in this world? If app functionality succumbs to language interfaces, you might start to wonder if or why you’re using an app to begin with. At this moment, are we actually in the world Bill Gates imagines?

To us, an application is no less than a private collection of services and context.

• Walmart sells low-priced inventory available at conveniently located stores
• Airbnb sells trusted home-rentals
• The NYT sells all the news that’s fit to print

To achieve the world Gates describes, you’d need reliable interfaces into these services (e.g., APIs).

But such interfaces, at least today, are contrary to apparent business interests. Airbnb wants to own the user experience end-to-end. Just 1 month ago Airbnb was hiring for its Anti-Bots Engineering team: Airbnb doesn’t want bots mediating its carefully designed user experience. Walmart has an API but only for sellers.

Some apps like eBay or Kroger have APIs that enable developers to create new storefronts into their marketplaces. Despite this and the incredible capability of today’s AI, we haven’t seen new AI services built on top of these APIs. [How would these services make money? What would they deliver that Kroger itself doesn’t?]

Providing services when you don’t control the user experience end-to-end is just hard. It’s why restaurants complain about delivery services, or SaaS companies complain about bring-your-own-cloud deployments. It’s hard to optimize and easy for things to slip through the cracks when responsibility boundaries are not clear.

So to us – and as we’ve written before – the app isn’t dead. Intermediating aggregators without trusted brands or durable attention might be. But services that produce goods and services that people love may credibly fight to own the user experience.

It’s why OpenAI discontinued its ChatGPT Plugins service and has reportedly sought deals with Redfin, Conde Nast, and Eventbrite to power search within their respective platforms. Personal AI bots intermediating all our interactions with the entire internet might not be practical or desired.

So if apps like Redfin, Conde Nast and Eventbrite are Thick Apps here to stay, we have our motivation for how AI services might interact with apps.

Operating system level services might direct users to particular applications with captured supply or trusted experiences (e.g., via Apple App Intents!), but users will engage applications with AI powering them.

AI will be embedded in apps, enabling simpler and more streamlined interfaces into inventory, content and services. Our user agent will selectively share transformations of our context with the applications we use. For that we’ll need auth, but existing vanilla auth isn’t enough.

‍

Tacked on auth won't work

Last month Auth0 announced Auth for Generative AI applications. It reportedly powers four use cases

1. Standard auth
2. Calling APIs on behalf of users
3. RAG with fine-grained access control
4. Human in the loop (unclear what this means or why Auth0 is involved here)

We’ll restrict our attention to items 2 and 3 as they have the clearest and most well-defined AI application. Standard auth is not AI-specific and async human in the loop auth likely needs more details to allow comment.

Auth0 shares a demo application. Studying its details, it quickly becomes apparent that (2) is strictly downstream of scopes available in connecting applications. For instance, the demo allows users to link their calendar to check if calendar availability matches that for an example upcoming company event. Auth0 says that this integration

will only check free/busy availability, not get full calendar access. This showcases the Google Calendar API integration, while minimizing information disclosure necessary for a demo app.

There are a few problems here, however.

First, the minimization of information disclosure is entirely downstream of the connecting application's available sharing scopes. Google Calendar happens to have a

‍https://www.googleapis.com/auth/calendar.freebusy

scope, but this is more luck than design. Many applications (like Gmail e.g., emails containing itemized receipts) contain data users would like to selectively share but lack appropriately granular scopes. This creates a false choice: either share everything or nothing at all. A truly AI-native approach would let apps request exactly what they need ("Are you free next Tuesday at 2pm?") rather than being constrained by pre-defined API scopes.

Second, the temporal nature of sharing is binary and inflexible. While the amount of information is constrained to this Google-provided scope, once you share the calendar.freebusy scope, it's shared permanently - there's no concept of temporary or purpose-limited access. Consider how this contrasts with modern location sharing:

Apple lets users share location:

• Never
• While using
• Always

But with standard auth we only have:

• Never
• Always

This lack of temporal control is particularly problematic for AI applications, which often need temporary access to fulfill specific, time-bound tasks. For example, a travel planning AI might need calendar access only while booking a trip, not indefinitely.

Finally, and perhaps most critically for AI applications, the current approach fundamentally overshares data even when attempting to minimize it. In the calendar example, the application only needs to answer a simple question: "Is the user available for this specific event?" Instead, it receives broad access to free/busy status - far more information than required. This pattern of oversharing becomes even more problematic as AI applications handle increasingly sensitive personal data.

These limitations become especially acute when we consider how thick apps might want to integrate AI. A service like Airbnb or Walmart might want to provide AI-powered personalization, but current auth patterns would force them to choose between requesting broad data access – risking user privacy – or forgoing rich personalization entirely. [First party data doesn’t cut it for AI.]  This explains why many thick apps remain hesitant to fully embrace AI integration - the auth and integration patterns simply haven't caught up to their needs.

This is why we need Authorized Agents.  Rather than retrofitting traditional OAuth patterns, we need an auth system designed specifically for AI's unique requirements around context, temporality, and granular data access.

‍

The promise of Authorized Agents

AI is enabling more streamlined and delightful access to products and services we love.

To make this even more seamless, these applications need access to our context.

But we shouldn’t have to share everything to make this possible. What we share should be context specific, not given by whatever existing application scopes happen to exist. And if applications are using AI to transform our context to provide us a service, do we have to share our context to them so that they can transform it, or can they call an AI resource users own – our AI User Agent – to just get the answer they need e.g., if a candidate event fits in our calendar.

This is the case for Authorized Agents.  Auth for AI cannot be tacked on. It needs to be tightly integrated with AI and the context it operates. When AI is embedded into applications, we need our AI User Agent to operate our context while enabling the best experiences in apps we use.

When searching for travel, a travel app should call our AI User Agent to refine a list of candidate hotels that best align to us. When shopping for groceries, our AI User Agent should help grocers deliver us the household essentials that best align with our schedules and evolving tastes. These use-cases don't require full data sharing, just a call to our Authorized Agent.

This interaction pattern requires an auth that allows users to link their AI User Agent to applications with

• Sharing purpose
• Specific context scopes
• Time-bound access: Link once, while using, or always?

Vanilla auth doesn’t cut it. The future needs Authorized Agents.

‍

Solving AI’s big privacy questions

Last year Bill Gates set forth the big privacy questions for AI.

As all of this comes together, the issues of online privacy and security will become even more urgent than they already are. You’ll want to be able to decide what information the agent has access to, so you’re confident that your data is shared with only people and companies you choose.

But who owns the data you share with your agent, and how do you ensure that it’s being used appropriately? No one wants to start getting ads related to something they told their therapist agent. Can law enforcement use your agent as evidence against you? When will your agent refuse to do something that could be harmful to you or someone else? Who picks the values that are built into agents.

There’s also the question of how much information your agent should share. Suppose you want to see a friend: If your agent talks to theirs, you don’t want it to say, "Oh, she’s seeing other friends on Tuesday and doesn’t want to include you.” And if your agent helps you write emails for work, it will need to know that it shouldn’t use personal information about you or proprietary data from a previous job.

These questions are simplified when users own their AI User Agent. When the AI User Agent is, per Tim Berners Lee

a program [that] does, in each instance, exactly what the user would want it to do if asked specifically

Now, when Gates asks: 'Who owns the data you share with your agent?' with Authorized Agents, users own both their data and their AI agent. The agent acts as a trusted intermediary, transforming private context into purpose-specific insights that apps need. Authorized agents ensure context stays bounded by purpose and time. And since Authorized Agents have AI inside, linked applications can enable users to

'share just my work availability' or 'only high-level schedule info'

rather than being bound by whatever API scopes exist."

AI privacy questions find natural resolution in Authorized Agents.

‍

Authorized agents for all

Crosshatch provides an Authorized Agent to every user. We do this by decoupling sharing scopes from apps. In its place, we create a new data model with its own more flexible and natural sharing scopes, creating a single pane of glass for controlling links to applications. Linking applications can access agent-transformed context ‘while-using’ and ‘always’ for reasons always clearly communicated.

Thick apps like Airbnb and Walmart will persist because they provide trusted services and curated experiences. But to deliver the personalized future Gates envisions, they need safer ways to access user context. Traditional auth forces a false choice:

• Share everything (via broad API scopes)
• Share nothing (preserve privacy but lose personalization)

Authorized Agents – provide a third way - letting thick apps access AI-mediated insights from user context without requiring direct access to that context. This preserves both:

• App control over user experience
• User control over personal context

If you'd like a demo of how all this works, reach out!

[Authorized agents may also take action on behalf of users – we'll consider that in a future post.]

‍