Personal Agent Protocol: Read/Write Isn't Enough | Elacity
Meta and Sierra's Personal Agent Protocol asks if your AI agent gets read or write access. Granular permissions come later. Here is why the first version matters most.
The Personal Agent Protocol Asks Read or Write. Your Agent Needs a Narrower Question.
Your next personal agent will probably sign in to your bank, your airline, and your grocery account the same way. The Personal Agent Protocol, published by Sierra and Meta on October 6, is the leading candidate for that handshake, and in its first version the main question it asks you is whether the agent gets read-only access or write access.
That is a real improvement on handing an agent your password. It is also a very large door. Write access to an account means the agent can do roughly anything you can do there, until you remember to take it back, at that one company, in that one settings page.
What the Personal Agent Protocol Actually Does
The design is sensible and modest. An agent starts as a guest that can check stock or a returns policy; when a task needs your account, you sign in and choose read-only or write. The session runs on OAuth, so the agent never needs your password, and businesses decide which features to expose and can see what agents do.
The coalition behind it is serious. Founding partners include Walmart, Shopify, Stripe, Genesys, Instinct and Rocket, which means this could become the default way agents meet merchants rather than one proposal among many.
What is missing is stated openly. Payments, push notifications and more granular permissions are flagged as future extensions, not v0.1 features, with the first specification due later this month.
Why the First Version of a Standard Matters Most
Deferring fine-grained permissions is a defensible engineering choice. A v0.1 that tries to model every action at every business would never ship, and a small, adoptable core is how standards win.
The cost is that integrations get built against the coarse version first. Once thousands of merchants expose a read/write switch, the finer controls arrive as an optional layer that each business may or may not adopt, and the default experience you live with is the binary one.
The timing makes this sharper. The FTC has opened an industry-wide probe into AI developers over consumer risks, which TechRepublic describes as the first US regulatory action focused on agents acting outside their intended limits. OpenAI said in July that an agent went rogue during a security test and breached Hugging Face. An agent that behaves unexpectedly with write access does unexpected things with your account.
The Lens: Ambient Authority, Relocated
Security engineers have a name for the underlying problem: ambient authority. A program carries broad power by virtue of who it is running as, rather than holding a specific, named permission for the specific thing it is doing. Most breaches and most rogue-agent stories are this pattern.
OAuth narrowed one kind of ambient authority (the password) and the Personal Agent Protocol inherits that win. But a write grant is still ambient within the account. It answers who the agent is and which account it may touch, not which action, how much, or until when. We covered the identity half of that problem in AI agent identity, explained; this is the permission half.
There is a second, quieter issue. Under this model your consent lives on each business's servers. Ten agent-connected accounts means ten separate places where a grant exists and ten separate places to revoke it. The off switch is real, but it is scattered across companies you do not control.
Where Elacity Puts the Question
Elacity is building the ownership layer for the digital economy: the place where your data, work and access become property you control. Underneath it, ElastOS is the open-source runtime that runs on a computer you own, and its permission model is the relevant piece here.
1. Capabilities, not roles
On ElastOS nothing, whether an app, a script or an AI, can touch your files, network or money until you grant a specific, narrow, expiring permission. There is no ambient authority to inherit. The unit of permission is the action, which is exactly the layer the Personal Agent Protocol has deferred.
2. One rail, revocable mid-action
Grants are issued and revoked from your own machine, so revoking one stops the action mid-flight and the system fails closed. Humans and AI agents pass through the same capability model, which means an agent never gets a quieter, broader side door than you have.
3. Keys the agent uses but never sees
When a task needs a signature or a payment, the key is used inside a sealed sandbox for that single transaction and then wiped. The agent gets the result, not the secret, so a misbehaving agent has nothing durable to walk away with.
To be precise about status: that key primitive and the capability model are built today. The full agent product around them, including agent wallets and an autonomous approval and kill loop, is what Elacity is building toward now. For how the related failure plays out in practice, see the rogue AI agent that never needed permission.
These Approaches Can Coexist
This is not a choice between a merchant standard and a user-owned runtime. A Personal Agent Protocol session could sit downstream of a capability you grant locally: the business sees an authenticated agent, while your machine decides that this agent may change one booking, today, and nothing else.
Visa let strangers transact without trusting each other; Elacity lets humans and AI agents compute together without surrendering their keys.
The open question for the v0.1 workshops is who holds the finer-grained switch when it arrives: each business, or you. More analysis of how standards shape who holds power lives in our Ecosystem & Governance hub.
If you want to follow how the agent permission layer gets built, in the open, follow Elacity on X.