Pulse

Pulse Chat: Identity, Authorization, and Execution in Enterprise Processes

Pulse chat lets signed-in users run enterprise processes in conversation, while Orchesty keeps permissions, identity, and execution outside the language model.

Pulse lets people work with enterprise processes through conversation without giving the language model unrestricted access to enterprise systems.

Every action available in Pulse is a predefined Orchesty topology. What a signed-in user can see and run depends on the permissions assigned to that user in Orchesty.

The path is:

  • Signed-in user
  • Permissions
  • Available topologies
  • AI selection
  • Authorization
  • Trusted identity
  • Topology execution
  • Enterprise system
  • Audit trail
The signed-in user's groups decide which topologies Pulse can see. The model selects one. Orchesty authorizes the run, attaches the trusted identity, executes the topology, and connectors limit the data to that user.

What Pulse is allowed to see #

Pulse does not receive a complete list of processes in Orchesty.

After the user signs in, Orchesty knows which groups the user belongs to and which topologies those groups are allowed to run. Only the tool descriptions of those topologies are exposed to Pulse. From the model's perspective, processes outside this permitted set are not available.

One user may therefore have access to capabilities such as retrieving customer orders, checking stock availability, and updating a delivery address. Another user may also be allowed to cancel an order or trigger an internal operational process.

Those differences come from Orchesty permissions, not from the language model. The model can only choose from capabilities that Orchesty has already made available to the authenticated user.

The topology is the authorization boundary #

In Pulse, authorization is applied at the topology level.

A topology represents one capability that can be exposed to a user. If two operations need different permissions, they should be separate topologies. Retrieving customer orders, updating a delivery address, and cancelling an order are three different capabilities. A user may be allowed to retrieve orders and update delivery information without being allowed to cancel an order.

Authorization stays explicit, whatever the topology contains internally. A topology may include multiple connectors, transformations, conditions, or calls to other systems. From the authorization perspective it still represents one defined capability.

Each capability is its own topology. Get customer orders and update delivery address can be allowed while cancel order is not. Steps inside a topology, including branches, do not create separate permissions.

AI selects the capability, Orchesty controls the execution #

Once Pulse receives the capabilities available to the current user, the model can decide which one best matches the request. Its role is to select an appropriate topology and provide the inputs that topology requires. After that, execution is handled by Orchesty.

The model does not construct the integration process. The topology defines which components can participate, how data moves between them, which conditions can affect the path, which systems can be called, and what inputs and outputs are expected.

A topology can contain conditional branches. Branching does not make the process agentic. Every possible path stays predefined by the topology.

The probabilistic part of the interaction is limited to interpreting the request and selecting an available capability. The business process follows the logic defined in Orchesty.

Trusted user identity stays outside the model #

When a topology runs, Orchesty preserves the identity of the authenticated user who started the request. Orchesty creates that identity after authentication and passes it into the run separately from the payload the language model controls.

The model can provide the business inputs the topology needs. It cannot create, replace, or modify the trusted user identity.

That separates two kinds of context:

  • Model-controlled input: data required to perform the requested operation.
  • Trusted execution context: the authenticated identity provided by Orchesty.

A connector or later step in the topology can then use the trusted identity when deciding which data the user is allowed to access.

The model provides business inputs. Orchesty provides the authenticated identity. The topology uses that identity to return only the data in the user's scope, even when the connector connects with a broader technical account.

System credentials do not define the user's scope #

Enterprise integrations often use technical accounts with broader access than the person using Pulse. That does not mean the user receives the same access.

A connector can use the trusted identity from Orchesty to apply further restrictions before it returns or changes data. It may use one technical account to query an ERP and still limit the result according to the Pulse user's identity. A sales representative could therefore retrieve only the customers assigned to them, even though the technical account can access all customers.

The same principle can apply to departments, business units, regions, customer portfolios, or other business-level access rules.

This separates two questions:

  • System authentication: can this integration connect to the system?
  • User authorization: which part of the available data should this particular user be allowed to access?

The filtering logic stays part of the integration design. Orchesty supplies the trusted user context required to enforce it, without relying on identity information from the language model.

Execution remains auditable #

Orchesty keeps an audit record of how a process was started. For each execution it can record:

  • which authenticated user started the process,
  • whether the request came through MCP,
  • which input data were provided,
  • and whether the process was successfully started.

That is a record of who initiated a business action and through which interface. What happened during the process is a separate concern, covered by Orchesty observability. Auditability records who started the process and with what input. Observability explains what happened during execution.

Why this matters #

Pulse uses AI as an interface to enterprise processes, not as their security boundary.

The model interprets the user's request and selects from capabilities already available to that user. Orchesty remains responsible for authorization, trusted identity, and execution.

Where next #