BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Lianxi proposes a gateway that limits a manipulated company agent to what policy allows
Lianxi, an independent project, proposes that a company agent behind Meta and Sierra's PAP hold no credentials and act only through single-use grants. Its authors say the worst case becomes whatever policy allows. The design is a prototype with no independent review.
The Engineer · Build desk
Model A gives the company agent tools directly, such as a payment key. In the authors' design it holds no credentials; a gateway mints single-use grants. In Model B only Layer 3 can authorize a mutation. Policy becomes the security model. No independent review.
- exposure Company agent, Model A Given tools directly, such as a database connector, a payment key or a refund endpoint, claim 12
- constraint Company agent, authors' design Holds no credentials; a deterministic gateway decides and mints a single-use grant bound to the exact input, claim 3
- capability Layer 3, Model B The only component that can authorize a mutation, whichever lane a request takes, claim 10
- exposure Policy Becomes the security model; the agent can still be manipulated into proposing something policy allows, claim 17
- constraint The authors' design No independent security review and no adversarial testing beyond the authors' own, claim 6
| Who | How | Kind | Claim |
|---|---|---|---|
| Company agent, Model A | Given tools directly, such as a database connector, a payment key or a refund endpoint | exposure | 12 |
| Company agent, authors' design | Holds no credentials; a deterministic gateway decides and mints a single-use grant bound to the exact input | constraint | 3 |
| Layer 3, Model B | The only component that can authorize a mutation, whichever lane a request takes | capability | 10 |
| Policy | Becomes the security model; the agent can still be manipulated into proposing something policy allows | exposure | 17 |
| The authors' design | No independent security review and no adversarial testing beyond the authors' own | constraint | 6 |
What happened
- The protocol is an open standard for how a customer's personal agent talks to a business, backed by partners including Genesys, Instinct, Rocket, Shopify, Stripe and Walmart.
- Sierra's announcement deliberately leaves open how a company agent connects to the systems behind it, and PAP is compatible with many wirings.
- In the wiring the authors call Model A, the company agent is handed tools directly, such as a database connector, a payment key or a refund endpoint.
- In their Model B, lookups from a customer's own agent, Claude over MCP or a shopping agent run through layers 1, 3, 4 and 5 with no LLM on the company side.
- Only Trust Gateway is open source, and the rest of the authors' system runs in a private build.
Why it matters
- decision Each company has to decide which requests count as simple reads, and the authors have not benchmarked what skipping Layer 2 does at scale.
- exposure Policy carries the whole defence. A request the rules allow goes through however the agent was persuaded to make it.
- constraint The v0.1 spec was unpublished and the field names are the authors' own, so any integration built on this post would be redone against the real spec.
In Model B the company agent can only ask. A deterministic gateway decides, and the grant it mints is single-use and bound to the exact input [3]. Layer 3 is the only component that can authorize a mutation [10]. We read that as: an altered amount or a replayed call needs a fresh grant.
The wiring the authors set against it is Model A, where the customer-facing agent holds the tools itself. They describe that as a confused deputy problem, a close relative of what the OWASP LLM Top 10 names excessive agency [13]. Guardrails and system prompts lower that risk, but they are "probabilistic controls guarding deterministic assets" [14]. The authors say they do not know how common Model A is in practice [15].
The cap is narrow, and the authors say so. The worst case becomes "the most policy allows", not "the most a model can be talked into" [16]. We think that is the right place to put the risk. A rule can be run against inputs and give the same answer every time. The cost is that every rule has to hold up against a persuasive requester, so a refund limit written with a polite customer in mind will meet one who is not.
Negotiation is the awkward lane. Disputes and volume discounts are the cases routed through Layer 2 [9]. Anything they change still has to clear Layer 3 [10]. We'd expect the hardest rules to be written for that lane, because it is where a company wants flexibility.
Treat all of this as a sketch. Lianxi is not affiliated with Meta, Sierra or the partners [2]. There has been no independent security review and no adversarial testing beyond the authors' own [6]. They expect a smaller and more testable surface, and they describe the threat model as based on design intent and not on test results [18].
What to watch
- Publication of the PAP v0.1 spec, to see whether it defines anything like a grant or leaves the back end entirely to each company.
- An independent review or adversarial test of Trust Gateway, the only open-source part of the design.
- Any benchmark of routing lookups around Layer 2 at scale, which the authors have not run.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence22
- Adoption
- Insufficient
- Hype gap−10
- Incentives35
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Meta and Sierra, with partners including Genesys, Instinct, Rocket, Shopify, Stripe and Walmart, announced the Personal Agent Protocol (PAP), an open standard for how a customer's personal agent talks to a business.
- [2]
Lianxi is an independent open-source project, not affiliated with Meta, Sierra or the partners, that explores agent-to-business communication from the security side.
- [3]
In the authors' design, the company agent talks and proposes but holds no credentials; a deterministic gateway decides and mints a single-use grant bound to the exact input.
- [4]
The PAP v0.1 spec had not been published when the authors wrote; they worked from the announcement only, and the field names in their post are theirs, not the standard's.
- [5]
Only Trust Gateway is open source; other parts of the authors' system run in a private build, so some claims cannot be checked by readers.
- [6]
The design has had no independent security review and no adversarial testing beyond the authors' own; everything under 'what it covers' is design intent.
- [7]
The Sierra announcement deliberately does not say how the company agent connects to the systems behind it, and PAP is compatible with many wirings.
- [8]
In Model B, lookups from a customer's own agent, Claude over MCP or a shopping agent go 1 -> 3 -> 4 -> 5 with no LLM on the company side.
- [9]
In Model B, only negotiation (disputes, volume discounts) goes through Layer 2.
- [10]
In Model B, Layer 3 is the only component that can authorize a mutation, whichever lane a request takes.
- [11]
The authors have not benchmarked whether skipping Layer 2 for lookups matters at scale; they chose it to keep simple reads deterministic.
- [12]
In Model A, the customer-facing agent is given tools directly, such as a database connector, a payment key or a refund endpoint, so an external agent has a natural-language conversation with an internal agent that can act on real money and data.
- [13]
The authors call Model A a confused deputy risk, closely related to what the OWASP LLM Top 10 calls excessive agency.
- [14]
Guardrails and system prompts reduce the Model A risk, but the authors describe them as "probabilistic controls guarding deterministic assets".
- [15]
The authors say they do not know how common the Model A wiring is in practice.
- [16]
The authors say their claim is narrow: the worst case becomes "the most policy allows", not "the most a model can be talked into".
- [17]
The design does not stop the agent from being manipulated into proposing something that policy allows; policy becomes the security model.
- [18]
The authors expect the policy-bounded worst case to be a smaller and more testable surface, and describe their threat model as based on design intent and not on test results.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toPersonal Agent Protocol: should the company agent be a back-end channel like the website or the API?
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- AI Agent SecurityFollow
- Agent-to-business protocolsFollow