What is an agent passport?

An agent passport is the written record of three things: the accounts and instruments that exist under the agent's name, what they may and may not do, and who can shut it down and how you prove the limits existed before go-live. It is closer to employee onboarding than to a system prompt.

Key takeaways

• Handing a persistent agent a mailbox and a funded card is hiring, not configuration.
• A passport covers identity, contract, and revocation, written down before the first unattended run.
• Passport, then rules, then live. Not live, then a policy doc.
• Five questions make it real: read, send, spend, human approval, and shutdown.
• Build the pack first. Then give it the card.

Why does an agent need a passport?

People are handing Grok Bots a mailbox and a funded card. That is hiring. Here is the onboarding contract that should exist first.

Single-prompt agents made setup cheap. Persistent agents made setup consequential.

A chatbot answers and stops. A Grok Bot keeps a computer, a browser session, and whatever credentials you gave it. If that includes mail, a calendar, a wallet, or a payment card, you did not configure a model. You hired a worker.

That is why a new phrase is spreading: agent passport. It is useful only if you define it before you use it.

What is in an agent passport?

An agent passport is the written record of three things:

1. Identity: the accounts and instruments that exist in the world under this agent's name.
2. Contract: what those accounts and instruments may do, and what they may not.
3. Revocation: who can shut it down, and how you prove the limits existed before go-live.

It is closer to employee onboarding than to a system prompt. The soul file in a ClawMaven pack covers persona and behavioral boundaries. The passport is the operational half: inbox, domain, keys, card, cap, approver, kill switch.

What is an agent passport not?

It is not a product you buy from a mailbox vendor.

It is not a prompt that says "be careful with money."

It is not runtime monitoring that notices a bad charge after it posts.

Runtime tools watch what already happened. A passport is the permission set you issue before the agent can happen.

What order should you onboard an agent in?

A common sequence now looks like this:

Give it mail. Give it a calendar. Give it a card. Figure out the rules later.

That order is how you get the reply sitting under every Grok Bot thread this week: gave it a card first. bad idea.

The workable order is narrower:

1. Decide which identity objects the job actually needs. One mission, not every tool you can wire up.
2. Write the contract before those objects can act. Read, send, spend, approve, revoke.
3. Attach hard limits to anything that moves money or publishes.
4. Prove the task once, with you watching. Schedule it only after that.
5. Keep a named human who can kill the process.

Passport, then rules, then live. Not live, then a policy doc.

Which five questions make it real?

If any of these are blank, the agent is not onboarded:

1. What can it read?
2. What can it send?
3. What can it spend, and what is the hard cap?
4. Which actions require a human?
5. Who can shut it down, and how fast?

Those five lines are the passport. The mailbox and the card are just the stamps.

How does this map to a ClawMaven pack?

ClawMaven does not provision Gmail, AgentMail, or Stripe. Those are runtime plugins. The pack is the contract that should exist before those plugins go live:

If you already spun the agent up, start with Audit, not Build. Config Scout is for the "card first" case.

What does this look like for a Grok Bot?

Grok Bot made the hire visible: persistent computer, browser, scheduled skills, Stripe in natural language. The product already has approval boundaries for send, publish, buy, and delete. Use them. Default to "ask first" on money and outbound messages until a specific bot has earned a narrow pre-approval.

Do not give it a consumer Gmail account if the operator guidance says those get disabled. Do not pre-approve a category because the extra click is annoying. Convenience is how an unproven worker gets production keys.

Bottom line

Call it a passport if that helps your team remember the metaphor. Call it an onboarding contract if you need language that survives a board meeting.

Either way, the substance is the same: identity, limits, kill switch — written down — before the first unattended run.

Build the pack first. Then give it the card.

Build a governed agent or audit the one that already has the card. Free to start. Config stays in the browser.

Frequently asked questions

What is an agent passport?

An agent passport is the written record of an agent's identity, its contract, and its revocation. It covers the accounts and instruments under the agent's name, what they may and may not do, and who can shut it down.

Is an agent passport the same as runtime monitoring?

No. Runtime tools watch what already happened, while a passport is the permission set you issue before the agent can act.

In what order should you onboard a persistent agent?

Passport, then rules, then live. Decide the identity objects the job needs, write the contract, attach hard limits to money and publishing, prove the task once while watching, and keep a named human who can kill the process.

What questions does an agent passport need to answer?

What it can read, what it can send, what it can spend and the hard cap, which actions require a human, and who can shut it down and how fast. If any of these are blank, the agent is not onboarded.

Does ClawMaven provision Gmail, AgentMail, or Stripe?

No. Those are runtime plugins, and the ClawMaven pack is the contract that should exist before those plugins go live.