Consumer Agents Are Here. Is Enterprise Identity Ready?

Imagine an airline customer who authorizes an AI agent to rebook a cancelled flight, pay the fare difference, apply a travel credit, and text the updated itinerary to a family member. The customer wants speed. The airline wants trust, accountability, and clear limits on what that agent may do.

That tension is the opportunity Meta's Muse puts in front of every digital business. Muse shows that personal agents are real.¹ The harder question for retailers, airlines, banks, healthcare providers, and other businesses is whether their identity systems can tell a delegated agent action apart from a direct human one.

Let's explore what Meta's new personal consumer agent means for the future of cybersecurity, how businesses should alter their identity strategy to meet this new type of customer interaction, and the opportunity ahead for organizations that take a proactive approach.

Muse matters because it moves past chat. It persists over time, operates across websites and applications, and completes real-world tasks like booking travel or making purchases. That is a different class of software than a chatbot that only answers questions.

Meta took security seriously. Muse runs in an isolated environment, keeps credentials separated from the core model, uses a secondary system to authorize actions, and adds user approval and audit controls.² Those safeguards are strong, but they do not solve how an outside business should identify and trust the agent itself.

Here is the real gap. When Muse shows up at a retailer, airline, bank, or healthcare provider, that business usually sees only the customer's authenticated session. It does not see a separate agent identity that carries explicit, delegated authority.

That distinction sounds small, but it decides who is accountable when something goes wrong. A session tells the business that a valid user is present. It says nothing about whether a human or a machine is driving the action, or what that action was approved to do.

Muse has a sophisticated internal permission model. But when it crosses into another company's application and signs in with the consumer's existing credentials or authenticated browser session, the receiving company generally sees the consumer, not the agent.

In identity terms, this is closer to impersonation than true delegation. It does not mean credentials are stolen, because the primary agent cannot see passwords or tokens. The issue is that the external application receives an action under the user's identity with no separate, verifiable agent identity behind it.

A shared session also breaks the audit trail. When every action arrives under the customer's login, the business cannot later separate what the person did from what the agent did on their behalf. That ambiguity is a problem for fraud teams, for dispute resolution, and for any regulator who asks the business to show who authorized a given transaction.

This matters more as agents move from low-risk research into higher-impact actions. Once money, health information, financial accounts, or legally meaningful commitments are involved, the cost of a wrong action climbs quickly.

A person logging into a bank and an agent accessing that bank on the person's behalf are not the same security event. They carry different risk, different intent, and different accountability, even when they use the same login. Treating them as identical hides exactly the information a business needs to make a good decision.

Today, many AI agent actions still look like customer actions. That is impersonation, not true delegation.

If an agent rebooks a trip, redeems loyalty points, changes a shipping address, applies a stored payment method, or accepts terms, the business needs three answers. It needs to know which agent is acting, what that agent was authorized to do, and whether the current action falls inside those limits. Today, a shared session answers none of those questions.

A stronger model lets the agent present the merchant or service provider with verifiable facts rather than a borrowed login. Instead of asking to be treated as the customer, the agent proves what it is and what it may do.

Think of it as the difference between a stranger claiming to speak for a customer and a signed, checkable note that says exactly what the customer allowed. The second option protects everyone. The customer keeps control, the agent can still act quickly, and the business gets a clear record of what was permitted.

That model rests on five verifiable facts:

• Agent Identity: The business can confirm that the actor is verifiably an AI agent, not the customer typing in a browser.

• Human Accountability: A specific person explicitly authorized this agent for a defined task, so responsibility traces back to a human.

• Bounded Authority: The agent's power is limited by scope, time, destination, and, where it applies, transaction value.

• Runtime Enforcement: The authorization can be challenged, reduced, or revoked while the agent is acting, not only when it first signs in.

• End-to-End Traceability: Every action traces to both the agent and the accountable human behind it.

Consider a simple example. You authorize an agent to buy school supplies from approved merchants for up to $300 over seven days. That grant should not let it reach your bank account, change your shipping address, or make unrelated purchases.

The same logic maps cleanly onto travel and retail. An agent can rebook one missed flight within a set budget, or buy back-to-school items only from approved merchants up to a fixed amount. Neither task should quietly extend to transferring loyalty points, changing traveler profiles, or opening credit lines.

The difference between these two worlds is fundamental. Impersonation asks the merchant to treat the agent as if it were the customer. Delegation lets the merchant recognize the agent, understand whom it represents, and independently enforce the limits of its authority.

This is not a call for more friction. Recognizing the agent should make good interactions faster, because the business can approve a well-scoped request with confidence instead of guessing. The point is to give the business a real choice, rather than forcing it to treat every agent action as if a human were present.

Muse already has many components of the right model, which is what makes this moment promising rather than alarming. The pieces exist. They simply need to travel beyond Muse's own walls.

Its Sentinel architecture evaluates proposed actions against user-defined permissions. Its approval model supports one-time, session-scoped, task-scoped, and time-bounded grants. Its payment integration uses restricted, single-use credentials tied to a specific merchant, amount, and limited period.

In other words, Muse already thinks in least privilege and bounded authority inside itself. The next step is to make that context portable, so the receiving business can evaluate the agent, the person behind it, and the limits of delegated authority in real time.

Portability is the piece the ecosystem still has to build. It means agreeing on how an agent proves its identity, how a business reads a delegated grant, and how both sides confirm that the grant is still valid at the moment of action. None of that requires a single vendor or a closed network. It requires shared expectations that any business can evaluate on its own terms, using the fraud and authorization tools it already trusts.

Picture the handoff done well. Instead of presenting only the consumer's session, the agent presents a delegated authorization credential. That credential carries the agent's identity, the accountable user, the approved purpose, and the transaction boundaries.

The receiving company then evaluates that credential alongside its own fraud, authorization, and business policies. This enables a real-time trust decision based on customer identity, agent identity, delegated scope, and transaction risk together. Low-risk agent actions can flow through seamlessly, while the business reserves friction for the moments that genuinely deserve human confirmation.

Muse makes agentic technology tangible. It shows personal agents taking meaningful work off people's plates, and it signals where consumer expectations are heading next.

For most businesses, the practical question is not whether to allow agents, but how to tell a trustworthy one from a risky one in the moment. That decision depends on context the business does not have today. Closing that gap is what turns a compliance worry into a competitive edge.

Its current identity model is not a reason to slow progress. It is an opportunity to strengthen how agents and businesses trust each other. The next generation of personal agents should not have to borrow a person's identity every time they act. They should carry their own recognizable identity, connected to an accountable human through explicit, limited, and revocable authority.

If an agent can spend money, change records, or make commitments, the business must be able to see the agent, the human, and the limits of the authority.

The principle is simple and durable. If an agent can spend money, change records, or make commitments, the business must be able to see the agent, the human, and the limits of the authority in play.

The winners in this shift will not be the companies that merely let agents log in as users. They will be the ones that can recognize agents, verify delegated authority, and decide in real time what those agents are allowed to do.

1. Meta - Introducing Muse, a Personal AI Agent

2. Meta - Security and Safety for AI Agents: Our Approach with Muse