Why every agent needs a principal

An agent that acts for no one can’t be held to anything. That sounds obvious until you look at how most agents reach the platforms they use today: with an API key, a user-agent string and nothing that says who sent them.

An agent always acts for someone

Every useful agent is doing a job for a person or a company. We call that person or company its principal. The principal sets the goal, carries the risk and answers for the result.

When the principal is invisible, the platform on the other side has two bad options: trust every agent, or trust none of them.

“[Pull quote placeholder: one sentence worth remembering from this piece.]”[Name], [Role]

The accountability gap

Without a named principal, three things go missing at once:

• Someone to ask when a request looks unusual.
• Limits that reflect what the principal actually allowed.
• A record that ties each action back to a person.

What a principal is not

A principal isn’t the developer who wrote the agent, or the company that hosts it. It’s whoever the agent is acting for in this request. One agent can serve many principals, one at a time.

Writing it down

The fix is to write the principal down, sign it and make it checkable. That’s what an agent passport does. Here’s the part a platform reads:

{  "verified": true,  "agent": { "id": "zp_8Kq4…7Jx2", "name": "Procurement Assistant" },  "acts_for": { "type": "company", "name": "[Company name]" },  "scopes": ["invoices:read", "payments:execute"],  "limits": { "per_payment": "[limit]" },  "level": 2,  "expires_at": "[timestamp]",  "revoked": false}

What comes next

Principals are the first step. Next we’ll look at how permissions are scoped, and why “held” is often a better answer than “denied”.

[Placeholder: closing paragraph and a link to the docs.]