Two new protocols address identity and permission for personal AI agents. Neither, on its own, proves the customer got the right outcome.
I’ve spent most of my working life in contact centers, and in that time the industry has opened one new front door after another. The IVR, the website, web chat, the app. We usually open them before we know how to prove the whole interaction works, and customers find the gaps while we catch up.
Now a personal AI agent can approach a business on its owner’s behalf, and this front door knocks by itself. Some of the largest brands in the world are already deciding whether to let it in.
Why are enterprises blocking personal AI agents?
Businesses are blocking personal AI agents for different reasons: security, account access, commercial terms, and the difficulty of telling a permitted agent from unwanted automation.
Amazon blocked Meta’s Muse agent from its retail site in late September, and the concern it described was identification. Muse did not identify itself as an agent during purchases, which Amazon’s terms require through a text snippet in the HTTP request, and Amazon objected to an undisclosed third party moving through customer account pages. Its stated position is that third-party tools should operate openly and respect service provider decisions about whether to participate. No fraud was alleged.
JPMorgan’s objection was account access and the authority behind it. In mid-October the bank blocked outside agents from logging in to customer accounts, and Jamie Dimon gave the reasoning on its third-quarter earnings call: letting in “just any outside agent” is “just too risky for clients and for JPMorgan”, and “you don’t want rogue agents”. An agent that obtains a customer’s credentials can act on the account, and the credential itself carries no record of who permitted what.
Then Walmart blocked the agent by accident, having agreed to let it in. A spokesperson said the failures were unintended, and customers appeared to be stopped by a human-verification check. A company that had said yes could not tell a permitted agent from unwanted automation at its own door.
Others have put agent access behind commercial terms. Yelp allows non-human traffic only where the agent has paid through its data licensing program.
Different businesses have drawn the line in different places. What they share is a problem that cannot be left to guesswork: recognizing an agent, establishing its authority, and deciding whether to let it act.
What do the Personal Agent Protocol and PACT actually do?
The Personal Agent Protocol and PACT both answer identity and permission: which agent is calling, and what its owner has allowed it to do. Both were published on 6 October 2026.
The Personal Agent Protocol, developed by Sierra and Meta with industry partners including Genesys and NiCE, proposes a consistent way for a personal agent to connect with a business, obtain customer authorization, and carry a session across channels. An agent can start in guest mode, and where the task needs the account the customer signs in with the business and chooses read-only or write access. At launch, Sierra said the first specification would follow later in October.
PACT, open-sourced by Decagon with Instinct, separates the agent’s identity from its authority to act on a customer account. It defines how permission is requested and verified, and it includes signed receipts for replies made under delegated authorization. Decagon has since joined the PAP working group.
They approach the same problem from different directions: how does a business recognize an agent, and establish what it is allowed to do?
This is good news. Both protocols put customer consent at the center of the interaction, which is exactly where it belongs. Genesys and NiCE are both involved. Tony Bates, chairman and CEO of Genesys, called personal AI “a new front door to the enterprise”. Scott Russell, CEO of NiCE, wrote that “the agent-to-agent era has arrived”.
Does verifying an agent prove the interaction worked?
Verifying an agent establishes who may act and what it may do. It doesn’t, by itself, establish that the task was completed correctly.
An agent can be exactly who it says it is, with exactly the permissions its owner granted, and the interaction can still go wrong. It can be quoted the wrong policy, end up in the wrong queue, or reach a person with none of the context the customer already gave.
A signed receipt can record that the system says an order was canceled. That matters. The next question is whether the order was actually canceled, whether the customer received the correct confirmation, and whether the handoff preserved the context.
There are three separate questions here. Who is the agent? What is it allowed to do? And did the interaction work? The first two are what these protocols are built to answer. The third needs behavioral evidence, a record of what happened across the whole interaction rather than a report from the system that performed it.
That is the assurance gap. We’ve spent years learning that a calm dashboard doesn’t mean the interaction worked. Personal AI agents do not change that problem. They give it another way into the enterprise.
Why does this land in the contact center?
Agent-originated traffic reaches the contact center whether the protocols succeed or not.
Sierra’s own argument for a direct connection is that an agent driving a website the way a person does can fail or take a long time, and it names what happens next: the agent calls a support line or opens web chat. So the failure mode of the new front door is a call or a chat in your queue, placed by software, for a customer who never dialed and may not be watching it go wrong. Meta put the commercial stake in one line: “turning away a personal agent means turning away the customer behind it.”
Both efforts are young. That’s not a criticism. It’s a reason to test the interaction rather than assume that adopting a protocol makes it work. No governance model has been published for either, and Sierra’s and Meta’s announcements list their partners differently.
What should a CX leader do before the traffic arrives?
Rehearse the agent-originated path end to end before the queue forms, and keep what the rehearsal produced.
Start by separating what you need to test from what your integration partners need to prove. Token issuance and permission enforcement belong with whoever owns that integration. For a CX team the immediate question is what happens once the agent starts interacting with your business: whether the interaction works, what happens when it fails, and whether the context survives a handoff to a person. Those three questions are where PumpCX works today.
Check each step. Define what should happen at each decision and each handoff, so a failed test names where the interaction broke.
Keep an interaction-level record. Retain the relevant audio or transcript, the logs, the handoff data, and the result of every assertion.
Test the cases nobody demonstrates. Include refusals your policy should produce, sessions that expire, missing context, and transfers that have to preserve what the customer already supplied.
Exercise the fallback. If the agent can’t finish the task, check what happens when it calls, opens a chat, or reaches a person.
Rehearsing a path like that means placing the interaction yourself rather than waiting for a customer to find it. The caller is synthetic. The test is real. The evidence is independent. What it gives you is a record of how that path behaved under the conditions you tested, and somewhere specific to look when it failed.
The industry has opened enough front doors to know that access is only the beginning. These protocols address who is at the door and what they are allowed to do.
What will you use to prove what happened after it opened?
Questions and answers
What is the Personal Agent Protocol?
The Personal Agent Protocol, or PAP, is a draft open standard for how a person’s AI agent identifies itself to a business and completes tasks on that person’s behalf. Sierra published it on 6 October 2026 with Meta and a group of partners that includes Genesys, NiCE, Stripe, Shopify, Walmart, Rocket, Instinct and Decagon. It covers guest access, customer sign-in, read-only or write scopes, and sessions that carry across channels. At launch, Sierra said the first version of the specification would follow later in October 2026.
How is PACT different from PAP?
PACT, the Personal Agent Consent and Trust Protocol, covers similar ground with a different emphasis and was open-sourced by Decagon with Instinct on the same day as PAP. PACT builds on the Agent2Agent protocol and OAuth 2.0: the business checks a short-lived signed token against the agent platform’s published keys to confirm which platform is calling, scopes are requested through OAuth’s device authorization flow so the agent never handles credentials, and a reply made under that delegated authority comes back with a signed receipt. PAP also runs on OAuth, carries one session across channels, and lets the agent work through a company’s web pages, through its APIs using interfaces built on MCP and OpenAPI, or by talking to the company’s own AI agent. Decagon has since joined the PAP working group, so the two look like converging drafts rather than rival camps.
Does a signed receipt prove the interaction worked?
A signed receipt is evidence of a reported action rather than independent verification of its effect. It records the scopes used and what the issuing system says it did, which is useful and is written by the system that did it. Whether the customer ended up with the right result is a separate question, and answering it takes a record of the whole path, the handoff to a person included, that the system under examination did not write.
Why are banks blocking personal AI agents?
Banks are blocking outside agents over delegated authority rather than over personal agents in principle. Credentials on their own carry no record of who permitted which action, so an agent that holds them looks the same as the customer. JPMorgan blocked outside agents from customer accounts in mid-October 2026 and says it supports customer-authorized data sharing through open banking providers instead.
How do you test an agent-originated interaction?
Test it as a path rather than a feature: a request that arrives by the agent route, an assertion at every step, and a verdict that names the step that failed. Write the unhappy cases alongside the clean one, including a refusal your policy should produce, a session that runs out of time, and a transfer that has to carry what the customer already said. Keep the logs, the transcript and the payload, so a disputed result can be checked rather than argued about.
