Sierra and Meta Poppy make personal agent permission the KYA mandate file
The October 10 KYA signal is that personal-agent access is moving from undetected browser automation toward explicit identity, permission and company-side control. Public last-24-hour materials showed Sierra publishing a draft Personal Agent Protocol, also called Poppy, after announcing it with Meta and partners. The draft describes how a personal agent can identify itself, obtain user permission, and work with a company through websites, service interfaces or a company agent.
Daily signal: Public materials described a company-published discovery file, user sign-in on the company's own page, agent sessions on behalf of a customer, company-defined parameters for what agents may do, and extensions for payments and push notifications. This is protocol and market infrastructure activity, not a regulator adopting a binding KYA rule.
Why this matters for KYA
Personal agents create a practical problem for banks, marketplaces, airlines, insurers, merchants and enterprise platforms. If an agent arrives by pretending to be the user, the company may not know that software is acting, what the user approved, or whether the requested action should be blocked. If the company simply blocks every agent, customers lose useful delegation. KYA sits between those extremes.
Poppy matters because it turns the agent relationship into an explicit permission file. The company can know that an agent is acting for a customer. The customer can approve the access needed for a task. The company can choose which channels and actions are available. That combination maps directly to the KYA question: who is the agent, who is it acting for, what may it do, and what record proves the answer?
For finance-facing workflows, this is not only a usability issue. A personal agent may return a product, rebook travel, apply for a mortgage pre-approval, change an order, retrieve account information, or prepare a purchase. Each action can trigger privacy, payment, consumer, outsourcing, record-retention, fraud and dispute obligations. The KYA file must capture the permission boundary before the agent touches value or regulated data.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak personal-agent posture | KYA-ready Poppy-style posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The company sees a user login, browser session, script, support chat or automated traffic, but cannot separate the agent from the customer. | The personal agent identifies itself, states who it represents, and works through a company-recognized session or interface. | Agent name, provider, represented customer, company session reference, agent lifecycle state, allowed channels and revocation state. |
| Agent mandate | The agent inherits whatever the user account can do, even when the task is narrow, temporary or informational. | The user grants task-specific access and the company defines which agent actions are available for that task and sign-in state. | Task purpose, approved scope, permitted action class, approval time, expiry, company policy version and blocked-action reason. |
| Wallet and custody | A payment method, refund path or financing action may be reached because the signed-in user could reach it. | Payment, refund, financing and account-change actions require separate boundaries, confirmation and dispute-ready evidence. | Payment or financing scope, amount or product limit, merchant or supplier boundary, confirmation receipt, reversal route and support owner. |
| Tool and venue access | The agent scrapes pages or uses broad connectors without a consistent company view of what systems are involved. | The company publishes allowed websites, service interfaces, company-agent routes and task-specific access parameters. | Discovery file state, allowed interface list, service schema, channel used, pages accessed, company-agent transcript reference and denied surfaces. |
| Audit trail | Logs show a user session and business outcome, but cannot reconstruct agent discovery, permission, company decision and user control. | The record links discovery, sign-in, permission, session continuity, agent action, company response and final outcome. | Discovery timestamp, sign-in event, permission grant, session events, action log, human confirmation, company response and outcome record. |
| Security and abuse | Controls depend on bot detection, rate limits, account takeover controls or broad access reviews after the event. | Controls separate guest access, view access, change access and high-impact actions, with monitoring, revocation and exception handling. | Risk tier, access mode, change-action rule, confirmation requirement, abuse alert, revocation event, monitoring result and incident link. |
| Jurisdiction fit | The same personal-agent flow is reused across markets without mapping privacy, consumer, payments, credit, insurance or records duties. | The KYA file maps agent permission, data use, financial action, disclosure, retention, complaint routing and liability owner by market. | Jurisdiction matrix, consent basis, data-use basis, regulated-action flag, retention period, complaint route, dispute owner and accountable entity. |
From hidden automation to permissioned delegation
The most important KYA shift is the move away from hidden delegation. When an agent uses the same login and pages as a human, the company may treat every action as if the customer directly performed it. That creates a weak evidence file. The company can prove account access, but not the agent's identity, instruction, permission scope or decision path.
A permissioned-agent flow creates a cleaner record. The agent discovers how the company wants to be reached. The user signs in with the company. The company can limit whether the agent may browse, view account information, make changes, use service interfaces or speak with the company's own agent. The session can continue across web pages, service calls and conversations, which gives review teams one action trail instead of disconnected fragments.
That action trail is the core of KYA. It should show which agent was involved, what the user allowed, which company policy applied, what the agent attempted, what the company permitted, and where the user remained in control. Without that trail, the organization has a hard time separating ordinary customer activity from delegated software action.
Permission is not the same as financial authority
Poppy-style access can support everyday tasks, but regulated finance teams should separate account access from financial authority. A personal agent that may view a booking should not automatically be able to change the itinerary. An agent that may start a return should not automatically be able to change payment details. An agent that may prepare a mortgage interaction should not automatically submit binding credit, insurance or investment instructions.
The KYA file should therefore split permissions into layers: discovery, guest interaction, signed-in view access, non-financial account changes, payment preparation, payment execution, regulated product application, complaint handling and data export. Each layer needs a different approval rule and record-retention treatment.
For APAC firms, this distinction is especially important because agent tasks can cross sectors. A travel rebooking may touch wallets, loyalty balances, refunds and insurance. A mortgage workflow may touch income records, credit data, property search, bank documents and advisory obligations. A commerce agent may move between marketplace search, payment authorization, refunds and customer service. One generic "agent allowed" flag cannot support that complexity.
Company-side control becomes a compliance asset
One of the strongest KYA implications is that companies can publish what they are willing to expose to agents. That turns agent support into a managed control surface rather than an ad hoc exception. Companies can decide whether agents are blocked, allowed only to search, allowed to view user records after sign-in, allowed to make changes after approval, or allowed broader access in narrow contexts.
This is useful for compliance teams because it creates a policy artifact that can be reviewed, versioned and tested. A bank, airline, marketplace or insurer can ask whether its agent-facing surfaces match its risk appetite. It can test whether the agent can reach payment details, personal data, complaint processes, product recommendations or binding actions without the right approval. It can also show regulators and partners that agent access is not simply a bot-detection gap.
Company-side control also reduces the temptation for agents to evade detection. If there is a recognized way to work with the company, the safer path is to identify the agent and apply the user's permissions. If there is no recognized path, the company is left with brittle bot controls and weaker customer experience.
Audit design for personal-agent workflows
A reviewable personal-agent workflow should preserve a compact but complete file. At minimum, it should include the discovery response the agent used, the company identity, the agent identity, the represented customer, the access mode, the task purpose, the permission grant, the session continuity record, the channels used, each high-impact action, each confirmation event, the final outcome and the revocation state.
The record should be machine-readable enough for monitoring and human-readable enough for complaints, refunds, fraud review and supervisory review. In practice, that means stable references, consistent action names, clear denied-action reasons and a way to reconstruct the user's control points.
For financial institutions, evidence quality matters more than protocol branding. Whether the agent reaches the firm through a website, a service interface, a company agent or a commerce protocol, the KYA file must answer the same questions. If the action moves money, changes account state, accesses sensitive information or creates a regulated product outcome, the evidence burden rises.
APAC operating implications
APAC firms will see personal-agent delegation through super-apps, wallets, bank apps, travel platforms, marketplaces, insurance portals, brokerage tools and enterprise software. The same customer may use different agents for shopping, work, travel and finance. Firms therefore need portable KYA records that can handle consumer, SME and enterprise delegation without assuming every agent has the same risk profile.
The operating model should begin with a matrix: which agents are recognized, which customer roles may delegate, which tasks are allowed, which surfaces are exposed, which actions require confirmation, which actions are prohibited, which records are retained, and which entity owns the dispute. The matrix should be market-specific because privacy, payment, credit, insurance and consumer-protection rules do not align perfectly across APAC.
Institutions should also avoid overclaiming. Poppy is a protocol draft and partner-design process, not a formal KYA mandate. Its significance is that it makes the missing control file visible. KYA teams can use that signal now to design identity, permission, access, audit and jurisdiction controls before personal agents become normal customer channels.
Practical KYA checklist
- Require personal agents to identify themselves before they access signed-in customer workflows.
- Separate search, view, change, payment, refund, application and complaint actions into different permission classes.
- Preserve the company discovery state and policy version used by the agent at the time of action.
- Bind each high-impact action to a represented customer, task purpose, approval event, expiry and revocation route.
- Use company-side allow and deny rules for websites, service interfaces and company-agent conversations.
- Record blocked actions and denied surfaces as positive compliance evidence, not only error logs.
- Map personal-agent workflows to market-specific privacy, payments, consumer, credit, insurance and record duties.
Bottom line
Sierra and Meta's Poppy signal points to a practical KYA future: companies should know when an agent is acting, users should decide what the agent may do, and high-impact actions should carry reviewable evidence. The protocol draft does not create a binding compliance rule, but it shows why personal-agent access needs a mandate file. Without identity, permission, access limits, audit trails and jurisdiction mapping, agentic commerce remains hidden delegation. With them, it becomes accountable delegated action.
Source note: This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.