Hi everyone, thanks for coming back to Customer Futures. Each week I unpack the fundamental shifts around Personal Agents, digital customer relationships and Empowerment Tech.
If you’re reading this and haven’t yet signed up, why not join a growing number of global executives, entrepreneurs, designers, regulators and other digital leaders by clicking below.
To the regular subscribers, thank you.
(p.s. did your email cut this newsletter short? You can find the full post here)
Hi folks,
Welcome to Part 2 of my five-part series looking under the hood of Meta’s new Personal AI Agent, Muse.
In Part 1, we explored why Meta has given Muse its own dedicated computer in the cloud. Complete with its own browser, storage, memory and connections to other services.
We also met Meta’s Sentinel, the independent security system that sits between Muse and the outside world. Controlling what the agent is allowed to do.
So today I want to dig deeper into one of their most important design choices: Why Meta has separated the intelligence that decides what to do, from the permission that allows it to happen.
This is a clear set of choices by Meta around digital trust - which may turn out to be just as important as the AI itself.
Because we’re about to give our personal agents access to an extraordinary amount of our personal data, and a range of different tools and powerful new capabilities.
They’ll read our emails, organise our diaries, manage subscriptions, deal with customer service departments and eventually spend money on our behalf.
But who, or what, gets to decide what they’re allowed to do? And how do we make sure our personal agents don’t break the rules that we give them?
That’s what today’s post is about. We’ll take a look at:
Why intelligence and permissions need to be separated
How Sentinel actually makes approval decisions
The five types of permission, and why they matter
How AI agents can act without actually needing our credentials
Who really controls the new personal permission layer?
Let’s go.
1. Intelligence isn’t permission
First, a quick observation about Meta.
They’ve spent an enormous amount of money building out some of the world’s most sophisticated AI technologies. But they’ve also designed an entire security wrapper around the assumption that their new personal agent Muse will behave badly.
Why?
Because by definition AI agents will make mistakes, misunderstand instructions and be manipulated by malicious content.
We must remember that AI is a probabilistic technology. It will come up with a likely answer, not a pre-planned one. If we knew exactly what would happen every time, it would be a deterministic technology. And it would just be another software programme that was predictable.
We wouldn’t be able to call it intelligent.
As Meta explains in its technical paper:
“No matter how strong the model is at the core, any agent like this will still make mistakes, and it will sometimes be attacked via the data it reads.”
In other words, regardless of how capable these systems become, Meta doesn’t believe the AI itself can be relied upon to decide what it’s allowed to do. Just because an agent can make a decision doesn’t mean it should have the permission to act on it.
And the more autonomous these systems become, the more important it is that we separate the two out.
Which is why Meta has built Sentinel.
Not just to protect your AI agent from malicious attacks, but to ensure that Muse’s decisions have a separate system of control. Muse can request an action… but it can’t independently approve it.
And that takes us into some interesting technical detail.
2. How Sentinel actually makes decisions
In Part 1, I introduced Sentinel as the ‘independent gatekeeper’ controlling Muse’s interactions with other services.
But Sentinel is going much further than checking whether an agent has permission to access something. It’s also making decisions about specific actions.
I’ve not yet seen a general purpose model take this approach.
When Muse wants to use a ‘third-party connector’ (like email or your calendar), the request gets passed to Sentinel. It then reviews it against what’s been approved for the agent, and the security decision can then look at:
Which service is involved
What operation is being requested
The scope of the permissions already granted
Take email permissions as a good example.
You might be perfectly happy for an AI agent to search your inbox for a flight confirmation. But that’s very different from allowing it to read every message. Which is different again from allowing it to send emails, delete them or forward attachments to another organisation.
All of those activities involve the same email account. But they’re very different operations, with different consequences.
For years, we’ve relied heavily on giving pretty broad permissions to our apps. You connect an application to your account. You approve a bunch of access rights. And off it goes.
Do you know really what you agreed to? Do you really know what happens next? Can you really remember what service has access to what? What access is happening right now vs yesterday?
But it gets even more complicated with autonomous AI agents. Because they won’t just follow a fixed set of functions. They will interpret those instructions, develop new plans around them, and even select new actions on the fly.
My goodness it’s about to be a mess.
Which is why Meta has introduced a more granular permission model. And it’s fascinating. Here’s how Meta’s researchers introduce it:
“Muse has support for obtaining one-time, session-scoped, task-scoped, time-bounded, or perpetual permission.”
I’ve been working on personal data permissions, consent, trust and control for over a decade. And as a whole design approach, this feels different. Sentinel gives users multiple different ways to describe what their AI agents are allowed to do. And how much permission we’re happy to give them.
Let’s break it down into five options:
One-time permission: Allow my agent to send this particular email to my accountant. Once it’s sent, the permission expires.
Session-scoped permission: Allow my agent to read my calendar while we’re organising next week’s meetings. The permission ends when the session finishes.
Task-scoped permission: Allow my agent to access my airline and hotel bookings while organising my holiday. Once the task is completed, the permission ends.
Time-bounded permission: Allow my agent to access my energy account for the next 30 minutes to compare tariffs. After that, access expires.
Perpetual permission: Allow my agent to check my bank account every morning and alert me to unusual transactions, until I revoke that permission.
These are very different forms of permission. And critically, they can be matched to what you are actually trying to achieve.
Think about a boring routine like checking your home energy use, and maybe changing your energy supplier. Now let’s look at what’s possible with Muse and Sentinel.
Muse could be asked to go and get your current tariff, check your bills, compare alternatives and recommend a better deal.
But you probably don’t want to give it permanent access to your energy account. And you certainly don’t want it signing a new contract without checking with you first.
So the approvals need to be attached to the activity, not just to the application.
I’ve been writing about this shift for years now. We are about to move from a world of permissions to access things, towards one of permissions to do things.
But this brings us to another fascinating detail. When Sentinel needs the user’s approval, Meta doesn’t ask Muse to request permission inside the conversation.
Rather, the approval is presented through a separate interface, and the response goes directly back to Sentinel.
Why?
Because the AI agent conversation itself might have been compromised.
Eh?
Imagine your AI agent has been reading a webpage containing malicious instructions, perhaps telling it to grab a private document and send it to an external address.
The agent might mistakenly take those instructions as part of its legitimate task.
This is called prompt injection. And it becomes particularly dangerous when an AI agent has access to private information and can communicate with external services. Just like our energy checking example above.
So Meta has designed the approval process to operate outside the agent’s control.
Even if the AI gets confused or manipulated, it shouldn’t be able to trigger the permission needed to complete an action. Yes, your AI agent can ask for permission, but any approval can’t come from the agent itself.
Fascinating, and absolutely critical when it comes to Muse permissions and building digital trust.
3. Acting without needing our credentials
There’s a second technical thing here worth exploring.
In Part 1, we looked at Meta’s designs for ‘credential surrogation’ (btw, who on earth approved that name…?) where the AI agent uses substitute credentials rather than having direct use of the real access tokens.
Interestingly, this now separates three things we usually bundle together:
Identity
Capability
Authority
They’re related, but they’re not the same.
Identity establishes who or what is involved. Capability determines what a system is technically able to do. And authority determines what it’s allowed to do.
In the coming AI agent economy, we’ll need to distinguish between all three.
Here’s a different example to make my point. Let’s say I want my personal agent to check whether my driving licence is valid before hiring a car.
So my AI agent will need to go get that data from my personal files, perhaps my digital wallet. It’ll need to rummage around and access my driving license credential, and then check my driving entitlements against the car hire policies or whatever.
Now, should my AI agent have unrestricted access to my identity files or wallet? Of course not. If would have potentially free access to copy my credentials, reuse them elsewhere or present them for unrelated purposes. No thank you.
No, my AI agent just needs the ability to complete a particular approved action. It doesn’t even need to have the underlying identity data.
And so Meta’s ‘credential surrogation’ (I really hate that term) demonstrates one way of separating those capabilities. As the research paper puts it:
“The agent never sees real tokens, which means any attempt to coerce the agent to reveal the actual secrets via prompt-injection or otherwise is futile.”
Of course, that doesn’t mean every security problem disappears. An AI agent could still attempt to carry out a banned task using one of its real connections. Which is precisely why separate permission steps matter.
But the underlying point here is important.
Your agent doesn’t need to ‘become you’ in order to act for you.
I think we’ll see much more of this kind of separation as personal agents get adopted at scale. Specifically, I think we’ll see AI agents getting their own identities. Because they’ll need ways to demonstrate which capabilities they have, and ways to prove that particular activities have been authorised by the people or organisations they represent.
AI Agents will need to be separate from us. Distinct from us. Identifiable on their own.
We’ll dig into this in more detail in Part 3: Delegation, Not Impersonation. Where we’ll look at why AI agent identity is becoming so important, how it differs from the ID of the person the agent represents, and why Muse is running into problems with some of the big brands and getting blocked.
For now though, there’s a more immediate question.
Yes, Meta can build a sophisticated internal system to decide what Muse is allowed to do. But that doesn’t mean another business can check those permissions are legit.
4. Who actually controls the permissions
OK, now take a step back. Because this is where Muse’s design is particularly interesting for the future of the digital customer relationship.
For decades, businesses have controlled most of the infrastructure governing our digital interactions. They decide how we authenticate and prove it’s us, what information we can access, which permissions are available and which activities we’re allowed to carry out.
But personal agents introduce something new:
A new set of capabilities operating on the side of the individual.
Including a personal computing environment. Personal data and memory. Personal tools and connections. And now a new personal permissions layer.
Instead of every business deciding how a customer can interact with its systems, we’re beginning to see personal software that can coordinate activities across multiple organisations, operating on behalf of the individual.
And crucially, that software has its own permissions infrastructure.
But there’s a catch: Meta still controls the rules. Of course they do.
Because they’ve designed Sentinel, they’ve defined the security architecture and they’re the ones operating the permissions infrastructure. And it’s Meta that ultimately determines which capabilities and authorisations are available within Muse’s environment.
So while Muse might operate on behalf of the individual, the permissions layer itself remains controlled by their central platform.
And that’s a fascinating tension. Because there’s a world of difference between a company giving you more control within its platform, and you having control independently of that platform.
Why should you care?
It’s very likely that soon we’ll all be using multiple personal agents. One from Meta. One from Google. One from OpenAI. Perhaps another from your bank.
Will you really want to manage all your permissions, credentials and delegated tasks separately inside every one of those apps? Would you want each company maintaining its own version of what your agents are allowed to do?
And what happens when you switch providers? Do your permissions move with you? Can you revoke authority centrally? Can you see which agents have access to which services?
And can you establish the rules that apply regardless of which agent happens to be acting on your behalf?
If we’re not careful, we’ll end up with the same mess we have today, with hundreds of apps on your phone, millimetres apart on the home screen, but unable to talk to each other.
Portable permissions. This is what I’ve been working on. And it’s a wicked hard problem. But these are kinds of questions we’re going to have to answer, and fast.
As Personal Agents become more capable, the ‘permissions layer’ could become one of the most important control points in the digital economy.
Whoever controls that layer will have considerable influence over which services your AI agents can access, what information they can use, and which activities they can perform.
Which is a huge choke point in your digital life.
Good old Zuck. Is this another master stroke by the Big Tech folks?
Now, you can argue that it’s not necessarily a bad thing. Security requires control. But it raises an important question about where that control should sit. With the agent provider? With the business providing the service? Or with the individual?
My view is that we’re going to need new, digital and independent infrastructure operating on the side of the customer. Not simply another collection of permissions buried inside individual apps.
We need portable, verifiable ways for people to manage the permissions they grant to their digital representatives. Across all their services, their AI agents and platforms.
That’s what genuine Digital Personal Infrastructure - the real DPI - is all about.
And it’s why all the work happening around digital wallets, verifiable credentials, agent identity and delegation protocols is going to become so important.
We must remember that the future of Personal AI isn’t about giving everyone a clever assistant. It’s much more about giving individuals a trusted digital representative that can operate across the economy on their behalf.
And for that to work, intelligence won’t be enough.
We need identity. We need accountability. And we need ways for organisations to know that someone’s agent really does have permission to act.
Which brings us to the next part of the story, and the next post in the series.
Next up: Delegation, not impersonation
Meta can use Sentinel to check whether Muse is allowed to perform a specific task. Fine. But how does an airline, bank or retailer also know? Can they know?
How does another organisation distinguish between an agent genuinely acting on my behalf, and software simply pretending to be me? And how does it know what I’ve actually approved?
These are fundamental questions about identity, trust and the future of digital customer relationships.
So in Part 3: Delegation, Not Impersonation, we’ll look at why AI agents will increasingly need their own IDs, why delegation is fundamentally different from impersonation, and why ‘identity and authorisation infrastructure’ will become essential to the AI agent economy.
And to Meta’s Muse.
If Part 2 has been about who gets to say yes, then Part 3 is about how the rest of the world knows that yes is genuine.
See you in Part 3.
Thanks for reading this week’s newsletter.
If you’ve enjoyed it, and want to learn more about the future of Personal Agents, digital customer relationships and customer engagement, then why not subscribe: