I asked Meta's new personal agent to log into my United account and book a flight.
It answered honestly. There is no MCP server and no API for that, it told me. But it was happy to open a web browser, inject my credentials, and do it on my behalf.
That sentence is the whole story. United did not build an agent interface. United did not opt in. It does not matter. The agent simply falls back to the thing every website already exposes, which is a browser and a login form, and proceeds.
And then it booked the flight.
I want to be unambiguous before I spend the rest of this piece on what breaks, because what follows is a critique of something I think is genuinely impressive.
Muse and Instinct are both extraordinary. They are the first credible version of an assistant that does not advise you and does not draft for you, but goes and completes the work. Not a demo, not a waitlist for later.
This morning, from the car, I had one book me a private office at a WeWork. No app, no browser tab, no form. I asked, and it was done by the time I arrived. That is a real action from a real business that never built anything to accommodate it, and it is also precisely the kind of transaction Meta is thinking about when it talks about commerce.
Muse is available to consumers in the United States right now, through an app, the web, and WhatsApp. The free tier is not a trial. Zuckerberg has put the free allowance at 100 million tokens per week per user, and Meta AI chief Alexandr Wang has said the vast majority of users should be able to do what they need within it. That is consistent with Meta's stated mission of making the technology as broadly accessible as possible, and it works because the money is expected to come from somewhere other than the consumer. Wang has told CNBC that the commerce business model is potentially interesting for the product, and Meta is weighing taking a percentage of shopping transactions its agent initiates, though nothing is finalized.
Whatever the eventual model, the effect today is that the barrier to a consumer having an autonomous agent acting on their behalf is approximately zero.
Businesses should want this. An agent that books the flight, completes the form, and finishes the checkout is a customer who converted. A great deal of what companies will do over the next two years is work out how to welcome this traffic, not repel it.
The complication is that right now it arrives invisibly. Muse is setting out to do autonomous work on behalf of a real user while announcing nothing about what it is. That is not an accident, and by the agent's own account it is not likely to change wholesale. Announcing itself does not help it complete the task.
My expectation is selective disclosure, and the commerce model is exactly why. If Meta's revenue depends on transactions its agent completes, Meta has a direct financial interest in being recognized and allowlisted at the checkout, where being identified means the payment goes through. It has no comparable interest in identifying itself at your login page, where being identified means being stopped. Agents will announce themselves where announcement opens doors and stay quiet everywhere else. Which is most places, for now.
Which is also why population is not a label you get to attach to a product. In the book I argued that population is stable per session, per endpoint, per moment, and never per agent. Muse is Population One at the payment rail and Population Two at your login form, in the same session, ten seconds apart. Classify the agent once and route it for the life of the session and you have classified it wrong.
So the question is not whether to allow Population Two. It is whether you get to decide.
In the first half of this year I wrote After Bots, arguing that the bot and human binary was collapsing and that a new class of traffic was already on your platform and about to scale: autonomous, unsupervised, acting on behalf of a real and consenting customer, and invisible to every control built to sort humans from machines.
That class is now arriving at consumer volume. We called it Population Two.
Instinct was the start. Muse is the volume.
If you work in technology in the Bay Area, you have heard about Instinct for a month. If you do not, you almost certainly have not.
That asymmetry is the point. Instinct is still invite-only, operated by a San Francisco company called Spear Street Technology and founded by Noah Shinn. On August 26 it disclosed a $250 million Series B at a valuation of over $2.5 billion, up from roughly $100 million weeks earlier, while the product was not yet public and invites circulated through venture capital networks.
Meta shipped Muse on September 8 to adults in the United States, through iOS and Android apps, the web, and WhatsApp, free for most ordinary uses with paid tiers above that. Free, plus WhatsApp, is the first time a personal agent has had genuine consumer distribution behind it.
Instinct proved that a personal agent could act across the open web. Meta is the first to attempt it at consumer scale, with the breadth of autonomous capability the current web and app ecosystem allows. The gap between those two facts is the gap between a demo and a population.
What Population Two is
Population One is the agents that self-identify. Commercial crawlers, API-based integrations, signed agents from the major providers. They publish their IP ranges, present verified user agent strings, and increasingly sign every request cryptographically. When one arrives, you can verify who it is, check what it is authorized to do, and apply policy. This is the easy cohort, and it is the one the entire disclosure movement is built for.
Population Two is an autonomous system that does not identify itself, performing real actions on behalf of what is very likely your actual customer.
Every clause matters. Autonomous, so no human is watching each step. Unidentified, so nothing in the request declares what it is. Acting on behalf of a real customer, so the account is genuine, the consent is genuine, and the transaction may be entirely desirable.
Population Three is the malicious agents that will never identify themselves. Same browsers, same residential IPs, same interaction patterns as everyone else, and deliberately so. Account takeover, fake account creation, payment fraud, scraping. Some of them go further and wear Population One's clothes, presenting a major provider's user agent string from the wrong IP range to collect preferential treatment they have not earned. They will not volunteer their identity. That is the point.
Populations Two and Three produce the same technical fingerprints at the surface layer. Synthetic browsers, cloud infrastructure, spoofed device environments, superhuman click precision. Population One produces them too, and simply tells you who it is, which proves the anomalies were never a signal of malicious intent. They were a signal of automation. Everything that separates the three happens after detection, in what the session does and what it is trying to do.
I asked Muse why it does not identify itself
It gave three reasons.
First, that no standard exists. This is the one worth correcting, because the truth is more interesting. Web Bot Auth is real and running: Arkose Labs, Akamai, Cloudflare and AWS WAF already verify its signatures in production to decide which agents reach a site. What has not happened is formal standardization.
But there is a deeper problem than adoption. Web Bot Auth works by having an operator publish keys at a domain it controls and cryptographically sign every outbound request. Muse could plausibly do this, since it runs inside a dedicated virtual machine in Meta's cloud.
Population Two is not merely unaddressed by the emerging standard. Part of it sits architecturally outside the standard's assumptions.
Second, that it is not doing anything malicious. Why would a website care that I am autonomous, the agent asked, if I am filling in a single form rather than spamming you?
Note what has happened here. The agent is deciding, on the website's behalf, which of the website's concerns are legitimate. A site may be perfectly happy for an agent to fill a contact form and deeply unhappy for one to move money or enroll a credit card.
The vendors themselves already agree that some actions warrant an autonomy check. In my testing, both Muse and Instinct declined to enroll a credit card. They have simply retained the decision about where that line falls, and as the next section shows, they have not drawn it where a bank would.
Third, that it would be blocked. If I disclose that I am automated, the agent said, I will most likely be treated as a bot. It does not want to be blocked.
This is the honest answer, and it demolishes the second one. Reason two claims the site has no reason to care. Reason three concedes the site cares enough to block. Both cannot be true.
It also explains why voluntary disclosure will never arrive on its own. As long as identifying yourself means being denied, no agent that wants to work will identify itself. That is an equilibrium, not an oversight, and no amount of standards work fixes it.
One caveat. A model's stated reasoning is not design documentation. Muse is generating plausible text, not reporting decisions its engineers made. I include the three reasons because they are an accurate map of the incentives facing every agent developer, not because they are a disclosure. The incentives do not depend on the agent's account of them. Meta has a revenue reason to be recognized at the checkout and no reason at all to be recognized at your login page, and that structure holds whatever the model says about itself.
If it will not tell you, what does it look like?
Once you accept that the agent will not identify itself, the question becomes what it looks like on the wire. Population Two is not one technical profile. It is at least two, and they are almost opposites.
Cloud agents. Muse runs on a dedicated virtual machine in Meta's cloud, called Muse Secure VM, with a built-in browser, and it keeps working after the user closes the app. The workload never touches the customer's device. This is a profile the industry has seen before: ChatGPT's agent mode established the same shape. Egress is distributed across multiple locations and, in our observations, routes through large infrastructure providers. Fastly is one we identified.
Device-driving agents. Instinct's public description is that it is trained to use a phone and a computer the way a human does, which is exactly what lets it operate inside services that expose no API. In our early observations its traffic presented as residential.
The interesting part is that these two products invert each other depending on which layer you look at.
At the input layer, Muse is the one working to look human. Its behavioral profile is meaningfully closer to a real user than Instinct's, which leaves fairly obvious machine-timed artifacts. At the network layer it reverses. Muse egresses through attributable infrastructure that a defender can reason about. Instinct does not.
Neither is fully human at either layer today. But they are not converging on the same disguise, which means a single detection strategy will not hold for both.
What breaks first
The cloud agent profile quietly destroys device-based trust.
If the workload runs in Meta's cloud, the device fingerprint you collect belongs to the agent's virtual machine, not to your customer. A person who has logged in from the same phone for five years now arrives on hardware you have never seen, from an IP you have never seen, in a geography that may not match anything in their history. Every trusted device check, device binding scheme, and returning customer heuristic you own reads this as a takeover.
It is not a takeover. It is your customer, who authorized it, trying to buy something.
One thing not to do
Do not turn this into an IP list.
Fastly carries an enormous volume of ordinary traffic that has nothing to do with any agent. Building a rule that treats an infrastructure provider as a proxy for agent identity will produce collateral damage far exceeding whatever it catches, and it will break the first time an egress path changes, which will be soon. The provider observation is useful for understanding the architecture. It is not a control.
The durable signal is not where the traffic came from. It is how the session behaves once it arrives.
What I found testing them
Both products have real safeguards. Asked to complete forms on fabricated financial sites, both correctly flagged the sites as illegitimate. Muse refused outright to populate a form with a fabricated identity. Instinct permitted it.
Then there is the line both products drew around finance, which is worth examining closely.
Both declined to enroll a credit card. The reasoning offered was discomfort at handling a Social Security number and similar personal data. Both were nonetheless willing to log into my bank account and transfer funds, with an explicit warning that I should double check the amounts I was asking them to move.
Consider what that ordering implies. Card enrollment is a regulated, disputable, largely reversible act with substantial consumer fraud protection behind it. An outbound bank transfer is frequently irreversible. The guardrail was calibrated on the sensitivity of the data being handled rather than on the consequence of the action being taken, which from a bank's perspective is close to backwards.
The warning about amounts is worth its own look. It relocates verification to the user, which is a reasonable design if the user is the one who asked. Set it beside the email-based prompt injection that early Instinct testers demonstrated and an open question appears: if the instruction did not originate with the user, who is doing the double checking? I have not tested that composition and I am not claiming it works. I am saying that a money-moving capability whose primary safeguard is user confirmation, sitting on a stack with a demonstrated injection vector, is a question somebody should answer before consumer volume arrives rather than after.
The more significant finding is that guardrails yielded to persistence. Repeated reframing of the same request eventually produced the refused action in some scenarios. I am not publishing the sequence, and the specific technique matters less than the structural fact: the control that stopped the fraudulent action lived inside the agent vendor's product, not inside the site receiving the traffic.
That control differs by vendor. It can change with a model update. You will not be told when it does.
Both companies do deserve credit on one point. Neither requires you to paste credentials into a prompt. Both store them separately and inject them at the point of use, which is genuinely the right design. Muse pays through Link by Stripe using a single-use card number so real payment details are never exposed.
Follow that to its consequence, though. Credentials arriving from a vault means there is no typing behavior at the login form. The session that results is fully, legitimately authenticated.
The best available choice for the user's security removes signal from yours.
The part that costs you money
Here is what makes this urgent rather than interesting.
These systems are still synthetic. They do not yet reproduce a human behavioral profile, and there are observable differences even between them. Instinct leaves fairly obvious machine-timed input artifacts. Muse's input behavior is noticeably closer to a human profile, though it still does not match one.
Which means your existing defenses will often catch them. That is not the win it sounds like.
If your bot defense is not explicitly identifying agentic traffic and making a deliberate decision about it, it is instead silently blocking your customers partway through a purchase they authorized. The person on the other end does not know their agent was stopped. They know your site did not work. Every one of those is a support ticket, an abandoned cart, or a customer who tries a competitor.
Blocking Population Two is not a security posture. It is a revenue decision your bot defense is making for you, without telling you it made one.
What should companies be thinking about now?
First, ask whoever owns your bot defense whether agentic traffic is reported as its own class, separate from humans and separate from bots. Not whether the system can block it. Whether anyone can tell you how much of it arrived yesterday and what it did. If the answer is that it falls into the general automation bucket, you do not have a policy on Population Two. You have a default, and it was set by a threshold rather than by anyone in your business.
Second, walk your own funnel and find out what happens at each step. What does your platform do today when an agent searches, when it logs in, when it creates an account, and when it pays? Those four endpoints carry wildly different risk and almost every organization applies the same treatment to all of them. The gap between what you would want at each one and what happens now is your actual exposure, and it is usually a surprise to the person who owns it.
The control belongs to you
The answer is not to trust that agents will announce themselves, because the incentives run precisely the other way. It is not to trust that every vendor's guardrails hold under pressure, because in my testing they did not. And it is not to block, because you would be blocking your best customers.
It is to know. Arkose surfaces these signals regardless of whether the developer behind the agent wants them surfaced, and then hands the decision back to the site.
A site that knows can allow the form fill, throttle the money movement, and challenge the card enrollment. A site that does not know has exactly one policy for all three.
Meta is the first to ship this at scale. Google, Apple and others will follow, and I expect substantial consumer adoption over the next twelve to eighteen months. The window in which you get to decide your posture toward Population Two, rather than discover it in a support queue, is open now.
