Talkdesk Authentication Gate™ (Auth Gate) is a security and access-control layer within the Talkdesk AI Agent Platform™ that prevents Sub Agents or Skills handling sensitive data (such as account balances, transaction history, or personal identifiers) from being accessed before a customer session has been authenticated.
Auth Gate gives admins direct, self-service control over authentication requirements, entirely from the platform UI, with no engineering effort required.
Key concepts
| Term | Definition |
|---|---|
| Auth Condition variable | A variable that acts as the system's official signal for whether a session is authenticated. Only one variable per application system can be the auth condition. |
| Sub Agent | An agent in the orchestration that handles a specific domain. It can be protected as a whole. |
| Skill | An action that runs deterministic code. It can be protected individually and is the recommended place to set the Auth Condition variable. |
| Coordinator | The component that receives each request and, for unauthenticated sessions, intercepts requests to protected components before they reach the LLM. |
In this article
- Why Auth Gate?
- How does it work?
- Configuring Auth Gate
- Best practices
- Verification flow
- Why it matters
Why Auth Gate?
- Protects customer privacy. Keeps your customers' sensitive data confidential until their identity is verified.
- Closes the unauthenticated gap. Prevents a sensitive workflow from remaining reachable during an unauthenticated session.
- Predictable outcomes. Authentication depends on a deterministic variable, not on how the model interprets the conversation.
- Self-service setup. Admins create and apply requirements directly in the platform UI.
How does it work?
Auth Gate is built around the Auth Condition variable. A protected component only runs while this variable is defined, which means the variable is the single source of truth for the session's authentication status.
Automatic enforcement. If an unauthenticated session tries to reach a protected component, the Coordinator intercepts the request before it reaches the LLM and routes the session to the appropriate authentication flow instead.
Configuring Auth Gate
Configuration takes two steps: create the Auth Condition variable, then apply protection to the components that need it.
- Create an Auth Condition variable.
In the AI Agent Platform, open Variables, select Add a variable, fill in the name and description, and check Set as auth condition, then select Confirm.
Figure 1. Open the Variables panel from the orchestration canvas.
Figure 2. Select Add a variable.
Figure 3. Name the variable and check Set as auth condition.
- Protect a component.
Once the Auth Condition variable exists, protection is applied at the component level. Choose the level that matches how much you need to restrict:
| Level | Where to enable it | Effect |
|---|---|---|
| Sub Agent | Advanced settings → Require authentication to enter this agent | Gates the entire agent. It only runs while the auth condition variable is defined. |
| Skill | Advanced settings → Require authentication to call this skill | Gates only that specific action, without gating the whole agent. The skill only runs while the auth condition variable is defined. |
Gate a Sub Agent
Figure 4. Enable Require authentication to enter this agent.
Gate a Skill
Figure 5. Enable Require authentication to call this skill.
- Test the flow.
Use the Simulator to confirm that unauthenticated sessions are routed correctly and that protected components are unreachable until authentication succeeds. In the example below, an unauthenticated customer asks for a balance and the agent asks for verification first.
Figure 6. Simulator: the request is routed to verification before any balance is shared.
Best practices
|
Golden rule Always set the Auth Condition variable from inside a Skill, never from the agent's own reasoning or free text. A Skill runs deterministic code, so the variable is set the same way every time and doesn't depend on how the model interprets the conversation. |
Tips for building the verification flow
- Separate logic from conversation. Keep the verification logic (checking the customer's data, confirming a match) inside Skills. Let the agent only handle the conversation: asking questions, explaining next steps, and reacting to the Skill's result.
- Validate before setting. Whatever data the customer provides to verify their identity (a code, an identifier, a biometric match, etc.) should be validated inside a Skill. Set the Auth Condition variable to true only after that validation succeeds.
- Never trust claims. Never let the agent set or assume the Auth Condition variable based on what the customer says (for example, a customer claiming they are already verified). The variable should only reflect the outcome of an actual Skill execution.
- Test before go-live. Run both authenticated and unauthenticated scenarios in the Simulator to confirm each protected component behaves as expected.
Verification flow
Auth Gate does not dictate how a customer is verified. Each company builds its own verification flow, and the outcome of that flow is what sets the Auth Condition variable.
This makes Auth Gate flexible enough to support different verification strategies depending on the channel and the customer's enrollment status. For example:
| Customer segment | Example verification method |
|---|---|
| Standard customers | PIN-based verification |
| SSN digits | Social security number |
Why it matters
Auth Gate helps keep your customers' sensitive data confidential, ensuring it is only shared after their identity has been properly verified. Because it relies on a deterministic Auth Condition variable, the authentication outcome is always consistent and predictable, never subject to interpretation by the agent during the conversation.
It also keeps configuration simple: admins can create and apply authentication requirements directly in the platform UI, with no engineering effort needed, while still having the flexibility to design the verification method that best fits each customer segment or channel.