How to enable MFA and protect your Tigy agent account

Prepare recovery

Use an authenticator you control and choose secure recovery-code storage. Do not share an administrator account to avoid invitations. Each responsible person should have their own identity and appropriate access.

Enable and confirm

Open account settings and security. Start two-factor setup, follow the displayed instructions and enter a valid code to confirm. Adding the account to an authenticator without confirming the code does not complete activation.

Check a new sign-in

Verify the final account state before signing out, then use your usual sign-in method. Complete the additional step when requested. If a code fails, check the selected authenticator account and device clock synchronization.

Separate account and destination credentials

The second factor protects human access. Tool credentials authenticate an external destination and need separate storage and review. Keep secrets out of prompts, screenshots and tickets; describe the step and error when seeking help.

Review responsibility changes

When owners change, review members and account-linked integrations. Disable the second factor only through settings and its required confirmation. Sending recovery codes to colleagues is not a solution to blocked access.

What does two-factor authentication protect?

It adds a check to human sign-in for the account managing agents. Adding the account to an authenticator app does not complete activation: enter the requested code and verify the final state. Permissions still determine which resources that identity may change.

A sign-in code does not replace credentials used by a tool to call an API. Review keys and credentials separately, particularly when owners change. Do not distribute recovery codes to give colleagues access; each person should use their own account and appropriate invitation.

Protect the account that can change service

An account maintaining agents can change instructions, sources, and tools according to its permissions. An improper configuration change may affect more than the dashboard: it can alter what the agent says or does during calls. Login protection therefore belongs to service maintenance. Two factors add an authentication step, while permissions continue defining the actions available after sign-in.

On a fictional team, the person editing an agent has access to a calendar tool. Protecting that identity matters because they can change the tool's description and usage. Enabling two factors does not mean they should administer every resource. Review necessary work and effective access. Authentication and authorization answer different questions: who signed in and what that identity can do. Both should match operational responsibility.

Tigy's documented procedure begins in account security settings. Start setup, add the account to an authenticator using displayed instructions, enter a valid code, and confirm activation. Adding the account to the application alone does not finish the process. Check final state before signing out. This avoids believing protection is enabled while the required confirmation remains pending. Use the state displayed by the product rather than the presence of an authenticator entry as evidence.

Use an appropriate account and device for the identity being configured. If the authenticator contains several accounts, check the correct entry before submitting a code. Do not share screenshots containing setup information or codes to prove the step occurred. When asking for help, describe the screen, step, and error without exposing secrets. Reviewers need reproducible observations rather than access to authentication material.

The aim is a usable, protected identity with evidence that activation completed. Do not turn this into a promise that every integration or data resource automatically became secure. Keys, external credentials, and permissions require their own review coordinated with account protection. This keeps the process focused on what two-factor setup actually establishes.

Prepare recovery without distributing codes to the team

Documentation advises storing recovery codes securely and separately from the password. They should not be sent to other workspace members for easier support. Plan recovery around the identity and organizational process without turning codes into shared credentials. Sharing personal access to avoid login difficulty creates a different issue from the one setup was meant to address.

In a fictional example, someone enables two factors and later discovers access depends on one device. Preparation should have included storing recovery codes according to product instructions and internal procedures. There is no need to invent an alternative recovery method the documentation does not offer. Use real options and keep recovery material protected with access aligned to purpose. A colleague's need to maintain the agent is not itself a reason to distribute another person's codes.

When a code is rejected, documentation recommends checking the selected account and device time synchronization. A code from another authenticator entry does not establish access to the current account. Describe these checks without asking the person to send the code through a message. If the problem persists, retain the step and error for support while avoiding publication of passwords, authentication codes, or recovery material. The information required for diagnosis is different from the secret required for entry.

Review the process when a device or responsibility changes. Continuing service should not depend on sharing a password so a colleague can perform the work. Use appropriate accounts and permissions. If the identity owns linked integrations, plan their continuity separately from login recovery. These dependencies may need attention even when the original account can still sign in successfully.

Useful preparation prevents both access loss and unnecessary secret circulation. Final testing should confirm normal sign-in and the additional step when requested. Do not disable protection merely because someone is unsure which authenticator account to choose; diagnose the situation first and follow available procedures for that case.

Review account access and external credentials separately

Two factors protect interactive account access through the product's process. External-service credentials let tools access configured systems. Enabling the additional step should not be interpreted as automatically replacing all credentials or reviewing their scope. Documentation advises checking external credentials when someone's access changes or exposure is suspected.

At a fictional operation, an integration still uses a key created by someone no longer responsible for maintenance. Before removing access, identify dependencies and assign ownership for updating them. Do not paste the key into the agent prompt or a public page to simplify transfer. Keep secrets in the appropriate credential mechanism according to available configuration and team procedures. Personal login protection does not make a copied integration token safe to distribute.

If exposure is suspected, preserve minimal investigation context without repeating the secret in every report. Identify the affected integration, involved capabilities, and necessary actions in the corresponding system. Replacement or removal should account for continuity: removing credentials may interrupt queries and actions even while the agent remains available for conversation. Test affected operations with appropriate data after adjustment. An unchanged greeting does not prove the integration still works.

Review resource permissions too. An authenticated identity need not change everything. Align access with work, inspect effective summaries, and verify the required task. If an action is rejected, investigate account, workspace, and resource before granting administration. Context or integration issues may be responsible rather than insufficient broad privilege. Correct the actual cause without unnecessarily expanding capability.

These reviews complement each other. Account protection reduces one unauthorized-access route; permission controls limit actions; external-credential handling keeps integrations under defined ownership. No isolated setting represents every layer. Staff should know which control changed and which evidence confirms service still operates within authorized scope. Keep that distinction visible in change records so later troubleshooting does not assume two-factor setup addressed an unrelated API or tool-access problem.

Verify final state and maintain a practical review

Setup completion should be visible in account state. After confirming activation, check normal sign-in and the additional step when requested. Also verify that the person can still perform their workspace duties. A permission issue discovered during this check should not automatically be blamed on two factors: authentication and resource access remain separate decisions.

Keep a short maintenance list: confirmed activation state, prepared recovery, appropriate role, and external credentials under defined ownership. There is no need to reproduce secrets in that list. Record that checks occurred, not the values used to sign in. If access arrangements or responsibility change, review affected points and preserve integration continuity. This makes the review useful without turning it into another place storing authentication material.

Test situations involving the wrong authenticator account, rejected codes, and unavailable workspace actions. Diagnosis should identify the next concrete check: selected identity, device time, activation state, or resource permission. Avoid random disabling or administrative grants without understanding the cause. Clear procedures reduce support time and the chance of expanding access accidentally. The same apparent inability to proceed may require very different remedies.

If someone genuinely needs to disable two factors, documentation directs them to use the settings action and complete required confirmation. Follow organizational procedure and actual context. Do not offer disabling as an automatic response to every difficulty. First establish whether the issue concerns account, code, device, or permission, because the remedies are not equivalent. Retain the relevant observations rather than the rejected code itself.

Keep review proportionate to the service administered by the identity. People changing write tools need attention to integration scope and permissions; results reviewers still need protected access. A useful routine establishes known state, prepared recovery, and clear responsibilities. It supports agent maintenance without depending on shared accounts, codes sent through messages, or assumptions that incomplete activation already protects login. Recheck the affected parts when devices, accounts, or integration ownership change.