User identity and groups

The Pulse chat authenticates the person using it and authorizes each process by group. This is what makes an employee portal possible: the platform acts on behalf of the real user, but only within what their group allows.

Identity #

The signed-in user's email travels into every run as the protected identity header. A topology can read it to act on the right person's behalf, for example to file a request in a downstream system without the user being able to choose someone else.

As with the agent API, execution still happens under the system identity so shared credentials resolve. The identity header is the separate channel that carries the real person.

Groups #

Authorization is the same model used everywhere on the platform and in the agent API:

• A base chat role lets someone open the chat but run nothing on its own.
• Add the user to a group that grants specific topologies, and those topologies appear as tools in their chat.
• Build as many groups as you need, each scoped to its own set of processes.

flowchart LR
  User["Signed-in user"] --> Group["Group"]
  Group --> Topo["Permitted topologies"]
  User --> Id["identity header (email)"]
  Id --> Topo

Where to go next #

• Confirmation and output
• Scoping with groups (agents)