Agent identity
How a peer coworker proves what it is, what it can do, and what it needs approval for — before another coworker (or a human) trusts it with a task.
The agent card
Every role's a2a-bridge publishes /.well-known/agent-card.json — a discovery document listing its skills and its gates.toml policy. A peer reads this before sending a task: does this role own the work, and does completing it require an approval this peer can't grant itself?
Least-privilege by construction
An agents/<role>.yaml file is generated from crates/agent-gen, never hand-written. The generator reads a typed RoleConfig table and fails the build if a role is given a tool it shouldn't have — so a coworker's access is a compile-time fact, not a convention someone might forget to follow.
Surface-scoped identity
The same role resolves differently depending on where it's running: macos__desktop_cowork__engineering_coworker (this Mac, Claude Desktop's Cowork mode) is a different identity from cloud__docker_mcp__engineering_coworker (Anthropic's cloud inference, Docker MCP Toolkit catalog) — same role, different tool access, because a Mac-local binary and a cloud sandbox can reach different things.
Vaults and credentials
Where a role needs a real credential (a GitHub PAT, an MCP OAuth token), it's stored in a Vault — macOS Keychain as the local secret source, Postgres as the durable audit layer — never inline in a prompt or a config file. Rotating or archiving a credential is a vault operation, not a grep-and-replace.
Related
7107190fff4c0519 · verify