Data handling
The synthetic input contains an email and IBAN. The governed model path records redaction decisions; it is not a blanket DLP guarantee for systems outside Talon.
Use case · Support operations
Let AI draft customer replies without granting refund authority.
Support workflows need useful answers, safe handling of customer data and clear boundaries around financial actions. In Talon's synthetic n8n demonstration, a support reply is completed through an approved model path while a disallowed refund-related tool is blocked before provider dispatch.
duplicate-charge support ticket
→ email + IBAN handling
→ permitted provider fallback
→ customer reply draft
issue_refund offered to model?
→ DENY before provider request
operator approval in n8n
→ separate synthetic finance handoff
→ NO actual refund executedCustomer supportPII redactionPolicy-valid fallbackTool-schema denialSeparate human gateSigned decisions
Concrete support workflow
Useful drafts should survive a blocked financial action.
The existing n8n customer-support resolution demo starts with a fictional duplicate-charge ticket, account context and refund policy. A preferred local model route fails; Talon skips a forbidden provider candidate and allows an approved OpenAI fallback on the redacted request. The draft can be completed even though the subsequent request exposing issue_refund is denied before upstream model dispatch.
Provider reliability
Fallback candidates are checked against the use-case's provider and data policy. A model-provider failure is not proof that the complete support workflow has failed.
Preventive tool restriction
The disallowed issue_refund tool schema cannot pass this governed provider request. This does not assert control of every directly invoked payment API.
Where approval actually happens
The n8n operator gate is not a Talon-initiated refund.
After Talon denies the disallowed model request, n8n enters a literal human approval state. The workflow waits until a demo operator approves or rejects the exact synthetic EUR 249 finance request. On approval it creates a finance-handoff artifact; on rejection no handoff is created. Neither branch issues an actual refund.
That human gate belongs to the n8n demo workflow. It is not the separately shipped HTTP Action Gateway's authorization/dispatch lifecycle and should not be presented as Talon automatically approving payment execution.
ticket + account context
↓ model request through Talon
PII redaction + allowed fallback
↓
useful customer reply draft
↓ issue_refund tool denied
n8n operator gate (SEPARATE)
↓ approved? create finance request
rejected? no handoff
No payment or refund is executed.What a buyer can inspect
Two perspectives on the same synthetic workflow
Support lead
The reply draft remains available. The application explicitly records that refund processing requires a separate human decision.
Platform engineer
The configured customer-support identity, approved provider fallback, denial, estimated cost and relevant session records can be inspected.
Security reviewer
Verify signed Talon decisions for routed traffic and separately signed demo-operator receipts. No claim extends to direct calls bypassing the controlled path.
The support inputs and financial handoff are synthetic. A separate Zendesk-adapter scenario exists, but installation and UI observations in a real Zendesk account require additional operator confirmation.
Run the controlled scene
Can your support assistant generate a draft and still stop a forbidden action?
Reproduce the n8n workflow and review the signed Talon records. Do not confuse a tool schema denial with an executed payment or complete endpoint containment.