You know the agent, but who’s the owner of the agent?

An agent arrives at your business with a customer's name, address, and a request to change where their money goes.

It might be exactly what the customer wants.
It might be someone using stolen information through an agent.
It might be a legitimate agent, but the user never approved.

The request looks the same until you have a way to tell the difference.

Look at the work personal agents are offering to take off your hands. Meta's Muse suggests tracking when your ID expires and helping book a renewal, or taking a document you photograph, signing it, and filing it with the state. Instinct can arrange airport rides, book a handyman, and file for unclaimed property.

These are signatures, forms, doctor appointments, subscription cancellations, refund requests, and tickets to buy the moment they go on sale. Your assistant handles your money, your records, and your commitments.

A photographed bill becomes an instruction to move money. A subscription cancellation can end a contract and cut off access. A submitted form may contain statements that the owner has legal obligations to fulfill.

Now imagine being the business receiving one of those requests.

Booking a doctor's appointment might be straightforward. Sharing the patient's records or accepting financial terms introduces real consequences for both sides if there’s a misunderstanding.

The business needs to know whether it may accept the action and whether the owner authorized it. Real people bear the consequences, even when software does the clicking.

Knowing the agent gets you partway

Let's say your site can verify that a request really came from Meta's Muse. You recognize the AI service and are comfortable accepting its agent.

Of course you'd rather deal with an identifiable agent from a known AI provider than an anonymous bot. But how do you know its owner approved this request?

How do you know the agent hasn't gone beyond its instructions? How do you know the owner's account hasn't been compromised?

Or forget the sophisticated attack. Imagine your kid picks up your unlocked phone and tells your assistant to place an order. It's your phone, your account, and your perfectly legitimate agent.

You still didn't approve the purchase.

This is why "know your agent," or KYA, is insufficient if it stops at identifying the software. A useful KYA system must reach the owner and the authority behind the action. A trusted AI agent doesn't answer that question for each request.

The old checks don't establish permission

When an agent makes a request on behalf of its owner, the standard checks for identity verification don’t answer “did you authorize this?”

A device score can help you assess risk. But Muse may be acting from its own computing environment, and even your actual phone can be in your kid's hands.

A login establishes access to an account. A record of a login looks the same in an audit log whether the owner shared credentials or the account was taken over.

A photo of an ID can help with identity verification. An agent that has access to that image can also submit it, and the image says nothing about whether its owner approved this purchase.

An mDL gives the recipient stronger evidence than an uploaded image. It tells you who the owner is but not whether the owner asked for this transaction.

Each one might help answer, "who is this?" The question in front of you is, "what did they approve?"

Consider what happens when an agent presents that license with a loan agreement. The license can help establish who the owner is. Presenting it doesn't, by itself, establish that the owner authorized this agent to accept this loan at these terms.

Keep all those controls where they help. Just don't mistake any of them for evidence that the owner agreed to this agentic request that you are about to process.

Intent means what the owner actually asked for

Everyone is talking about intent. In a transaction, it means the owner's expressed choice about what should happen, including the conditions and limits they set.

"Find me a flight" expresses a different intent from "Buy this flight for $480." Permission to spend up to $500 on a refundable ticket doesn't cover a $480 ticket that can't be refunded.

The amount alone isn't enough. The conditions are part of the instruction.

If you're the airline, you’d expect the request to arrive with evidence that the owner approves. If you're processing anything received from an agent, you’d expect to receive evidence establishing approval between the owner and the action.

An agent being able to log in doesn't establish permission to do everything the account allows.

The chat history with the owner isn't enough. The business needs a record of what the owner actually approved.

Work on this is already underway. Google's Agent Payments Protocol uses signed mandates to capture instructions and purchase approvals. The broader job is making this standard record apply to everything an agent does, not just payments.

What a verifiable record should tell you

We call this a verifiable record: an identity and authorization payload that binds the owner's identity to their expressed intent. In plain English, it's a signed package of evidence answering two questions:

1. Who is the owner? Here is verifiable identity evidence establishing that this is me.

2. What did they agree to or approve? Here is the transaction or instruction, with the terms and limits I agreed to.

For an illustrative flight request, the approval could identify the authorized agent, the route and travel dates, the maximum total price, the refund conditions, and when the permission expires. The airline checks the actual booking against those instructions.

The owner doesn't have to approve every search the agent performs. They can approve a specific purchase or give the agent defined authority to choose a flight within those limits.

The record needs several properties to be useful.

• Its origin must be verifiable.
• Its signed contents must be protected against tampering
• Its authorization must be connected to the actual request.
• It must also be something the receiving business can check and retain, with the relevant validity and revocation checks applied when it is used.

Every request should include proof of permission. If an agent alters the signed permission, signature verification fails. If the agent submits a request outside the approved limits, the service should reject it.

That's the evidence every business should ask to receive.

Get the owner's approval on the record

To achieve verifiable records in every agentic transaction, we need two things: 1) A verifiable credential that proves who the owner is. 2) A signing key that only the owner can use — think of it as a signature nobody else can produce.

The agent can carry the signed instructions. It should not hold the key. An agent with the key can approve anything in the owner's name.

The approval step needs to authenticate the owner separately from access to the agent's conversation. Otherwise, the kid with the unlocked phone can approve the purchase too, and you've simply moved the same problem to another screen.

At Proof, we issue verifiable credentials bound to a holder's key through our certificate authority. Our Certify product lets a verified person sign specific transaction data, binding their identity to the terms they approve.

For instructions an agent will execute later, our support for Verifiable Intent creates a signed permission identifying the agent and its permitted scope. The recipient can check all three: the owner approved it, this is the correct agent, and the request satisfies the intent's conditions.

AI can generate a convincing chat history. Without access to the owner's signing key, it cannot generate a valid signature from that owner and invent its own instructions. Modifications to the signed data break verification.

That is the value of a cryptographic record: the recipient can verify the signed approval and detect tampering, even when an agent delivers it.

And if the owner later says, "I never told it to do that," you have a record to investigate. In a dispute, a business can produce the approved terms, the identity evidence, and the signature instead of asking the agent, “What happened?”

When a request arrives from Muse or any other personal agent, make the approval record part of your acceptance decision. That is why we introduced x401: every service provider can now prompt agents to verify their owner’s identity and provide their approval.

Recognizing it’s Muse only tells you which agent arrived. The verifiable record tells you whose instructions you're being asked to carry out, and exactly what that owner approved.

See how Proof binds identity to signed transaction data.