Authentication and Runtime Tokens

Persona integrations usually touch two different planes:

• the control plane
• the runtime plane

If you do not separate those clearly, the integration becomes confusing very fast.

Control plane vs runtime plane

The control plane is where you provision and configure the system.

This is where you typically:

• create or select spaces
• register apps
• create Personas
• issue runtime tokens
• manage rollout posture

The runtime plane is where Persona actually operates.

This is where integrations:

• call runtime surfaces
• connect product experiences
• send or receive data
• allow Persona to act through approved capabilities

Runtime tokens

Runtime access is granted through runtime tokens.

Those tokens are what allow a product integration, connector, or external surface to call Persona runtime endpoints safely.

What a token should carry

A runtime token should answer three questions:

Which space can this token operate on?

This is the most important scope question.

The space is the canonical authority boundary, so runtime access should always be understood in relation to the owning space.

Which scopes does this token have?

Scopes define which route families or runtime surfaces are available to that token.

That means a token for reading chat should not automatically be able to mutate other product surfaces.

How long is it valid?

Tokens should have explicit expiry. Runtime access should be narrow and intentional, not open-ended by default.

The practical sequence

For most product teams, the right sequence is:

1. create or select the target space
2. register the app that will expose or use Persona
3. create the Persona inside that space
4. issue runtime tokens for the required scopes
5. connect the integration to the relevant runtime surfaces

Why the space is authoritative

This is the part many teams miss on the first pass.

The space is not just one field in a payload. It is the main authority boundary for the runtime.

That means:

• token scope should align with the target space
• runtime calls should align with the target space
• Persona residency should align with the target space

If those three drift apart, the integration model stops being trustworthy.

Good token design

Good runtime tokens are:

• space-scoped
• narrowly permissioned
• time-bounded
• issued for a clear integration role

Bad runtime tokens are:

• too broad
• long-lived without reason
• reused across unrelated spaces
• carrying more capability than the product surface actually needs

Common mistake

The most common integration mistake is to think about auth only in terms of “does this request have a token?”

That is not enough.

The better question is:

“Does this token have the right authority for this space, this runtime surface, and this product role?”

That is the mindset that keeps Persona deployments clean as they grow.