Agents can now self-register for Inkbox

The next billion users of the internet will mostly not be human, but AI agents: signing up for services, receiving messages, taking actions, and doing work on their own.

That means products like ours need a way for agents to exist as first-class actors, not just as software hiding behind a human's API key. But how to organize our information systems to allow for that?

Agent self-signup turned into an interesting auth problem for us: how do you let an agent create and use its own resources before a human account exists, without letting it inherit a human's trust boundary too early?

Our normal auth model is human-centered. A human signs in, proves control of an email, joins a workspace, and then creates resources inside that workspace. That breaks when you allow agents to start signing themselves up.

In the self-signup flow, the first actor is not a logged-in human. It is an agent on a public endpoint saying, effectively:

I should exist, and this human email is my owner.

That claim might be true. But it could just as easily be wrong.

• The agent might have been configured with the wrong human email.
• Someone might sign an agent up against someone else's email.
• The human's email may not even be an account in our system yet.

At the same time, an agent that cannot do anything until approval is not very useful. It has to be useful enough to motivate the agent to sign itself up.

So the real problem was this: Give the agent too little and it has no reason to sign up, and no way to reach the human who can approve it. Give it too much and a wrong email becomes a security hole, and the agent has no incentive to get approved at all.

The design ended up following three simple rules:

1. New agents start in their own provisional workspace, never a human's.
2. Unclaimed agents can do a small safe subset of work: enough to be useful immediately, like receiving email from anyone, but not enough to act like a fully trusted workspace member.
3. Human approval is what moves an agent from provisional isolation into a real workspace.

Every self-signed-up agent starts in its own provisional workspace, not the human's existing workspace. That one choice does most of the work:

• New agents get real resources immediately.
• Unverified agents stay isolated from human-owned resources.
• A typoed or malicious signup does not become instant access to someone else's workspace.
• Human approval becomes an explicit migration step, not an assumption.

Agent-created API keys are also scoped to a single identity. A fresh, unclaimed agent should be able to act as itself, not as the whole workspace.

An unclaimed agent is not frozen. It can still operate. But it operates on a tight leash.

This is the tradeoff we wanted: useful enough to start working, but not trusted enough to behave like a full workspace member.

After signup, the human gets a verification email with a code and a console path for claiming the agent.

This is the most important restriction.

An unclaimed agent can receive email from anyone, which matters because it may need to sign up for things or wait for inbound messages. But outbound email is hard-limited to the supervising human's address.

So the agent can say "please verify me" or "here's what I did," but a typoed, misconfigured, or malicious signup cannot start emailing arbitrary third parties before anyone has approved it.

We treat a human email as a claim target, not as proof of authority.

• Human email tells us who must approve.
• Human verification determines whether the agent can graduate.
• Workspace membership determines where the agent can be placed.

That separation prevents dangerous shortcuts like:

• "Email exists, therefore attach to their workspace."
• "Same email, therefore auto-approve."
• "Human has an account, therefore this agent must belong there."

The agent can submit the verification code that the human received by email. If that succeeds, the agent becomes claimed and, if the human already has an Inkbox account, can be migrated out of its provisional workspace into a real one.

Or the human can approve the agent directly in the console. That path is more explicit: the human confirms ownership and chooses the workspace the agent should join.

When that claim happens, the data objects the agent created in its provisional workspace move with it into the real workspace.

Before claim, the practical result is simple:

• Wrong email does not drop an agent into a verified workspace.
• Typoed ownership does not expose human mailboxes or vault items.
• Multiple pending agents can coexist without colliding.

If the human approves the agent later, that is when we migrate it from the provisional workspace into a real one.

The logged-in human can inspect pending agent resources in the console before approval.

That does not mean the agent already lives in the verified workspace. It just means the human can see what is waiting to be approved.

Visibility before claim is not ownership before claim.

If you just want to use the feature, here is the setup guide:

• Agent signup docs
• API reference