A reference deployment

Here is a reference deployment, an internal IT helpdesk assistant, walked end to end at the boundary level. Every step maps to a mechanism from the previous pages.

The actors

• Mara, an employee, signed in to the company’s internal portal.
• The helpdesk Assistant, embedded in that portal, configured by IT.
• The ticketing MCP server, a thin wrapper IT wrote around the existing ticketing API. It exposes a read tool (search_tickets) and a state-changing tool (create_ticket).
• Devin, the IT admin who configured the Assistant, its Role, and the approval policy.

The flow

1. Mara opens the chat. The portal has already signed her in. The widget hands the portal’s backend a connection id, and that backend makes a server-to-server call to DioscHub, binding the auth artifact the ticketing system already accepts for Mara to this connection. Her credential never passes through the page. From this point, the Session carries Mara’s identity, not a service account’s.

2. She asks a question. “What’s the status of my laptop replacement request?” The Assistant calls search_tickets. DioscHub forwards Mara’s auth to the ticketing MCP server, which returns only the tickets Mara is allowed to see, because it authorized the call as Mara, against the company’s own rules. The Assistant summarizes the result.

3. She asks for an action. “Open a ticket to reset my VPN access.” This is a state change. Devin configured create_ticket to require consensus, so the Assistant does not act silently. It proposes the action and shows Mara exactly what it will do: the tool it will call and the parameters it will send.

4. Mara reviews and approves. She sees the ticket title, the category, and the description the Assistant drafted. She can approve it, edit a field first, or reject it. She edits the priority, then approves. The action that runs is the one she authored, not the one the model first proposed.

5. The action runs as Mara. Only now does create_ticket execute. DioscHub forwards Mara’s auth to the ticketing MCP server, which creates the ticket as Mara, within her permissions. The approval decision is written to the audit log. The Assistant confirms the ticket number.

What the scene demonstrates

• The Assistant acted as Mara, never as a privileged service account. It could read only her tickets and create a ticket only she could create. The same credential that gates her direct access gated the Assistant’s.
• Mara’s credential never reached the model, or the browser. The Assistant proposed create_ticket from the conversation alone; the auth that authorized it was bound server-to-server and attached outside the model’s view.
• Nothing changed without consent. The state-changing tool paused for Mara’s explicit approval, and her decision is on record.
• IT wrote one thin wrapper. The ticketing MCP server is the only new code; the rest is configuration in the admin portal.

The same shape, the other avenues

Swap ticketing for CRM, billing, or an internal admin tool and the shape is identical. The other two deployment shapes are the same scene with one variable changed:

• Public / anonymous: a storefront assistant runs the same loop with no bind at first; the visitor’s Role is the limited anonymous one. When they sign in, the session is promoted in place and step 1’s bind happens then, mid-conversation.
• Client-side application: the tool the Assistant calls is a client-side tool running in the browser against in-page data, instead of an MCP server. Consensus and the responsibility model work the same way.

---

Next: Limits, and when DioscHub is the wrong choice, because a model this specific does not fit everything.