Protected Tags

Protected tags are vault account labels that you can reference directly in Policy rules, replacing complex vault-by-vault configurations with simple group-based logic. Any change to a protected tag requires quorum approval, keeping controls deliberate and auditable.

Common examples include labels like High-Risk, VIP Clients, Treasury, Retail, Sanctioned, or Europe. Generally, protected tag labels should represent a business-critical classification you want to enforce in policy.

Support for additional Fireblocks entity types is planned for future releases.

How protected tags work

A protected tag behaves like a standard tag in terms of structure, but adds two key capabilities:

• Policy referenceability: Protected tags can be used in Policy rules. At transaction submission time, Fireblocks evaluates the tags on the source and destination vault accounts and applies any matching rules.
• Approval-controlled governance: Any change to a protected tag requires quorum approval before it takes effect. Your enforcement logic cannot be changed silently or accidentally.

Creating a protected tag does not require approval. Protection status is set at creation time and cannot be changed afterward.

Who can manage protected tags

Only the Owner, Admins, and Non-Signing Admins can approve protected tag operations. The Editor role can initiate operations but cannot approve them.

Approval model

Protected tag operations that require approval follow a two-phase flow:

• Phase 1: Request submitted. When an authorized user initiates a change, Fireblocks stages the request and returns an approvalRequestId. The change is not yet applied.
• Phase 2: Approval granted. An Owner, Admin, or Non-Signing Admin reviews and approves the request through the Fireblocks mobile app or API Co-signer. Once approved, the change is applied and the tag state is updated across the platform.

If the request is rejected or cancelled, no change is made.

Approval requests can be in one of six states: PENDING, APPROVED, REJECTED, FAILED, CANCELLED, or EXPIRED.

Approval groups

Fireblocks provides two dedicated approval groups for protected tag operations. Each has its own quorum configuration, so you can apply different approval requirements to editing tags versus attaching them to vaults.

Both groups are available in Settings > Quorums > Approval Groups, under the Security and Compliance category.

For each group, you can configure which workspace members must approve and how many approvals are required before the change takes effect. For example, you might require a higher quorum for attaching tags to vaults than for editing a tag's label.

Creating a protected tag

1. In the Fireblocks Console, go to Settings > Tags (Utilities > Tags in some workspaces).
2. Select Create Tag.
   
3. Enter a name, and optionally a description and color.
4. Select the Protected tag checkbox.
5. Select Create tag.

Creating a protected tag takes effect immediately with no approval required.

Attaching and detaching protected tags

Attaching or detaching a protected tag always requires quorum approval. After submission, the change is staged and applied only after an Owner, Admin, or Non-Signing approves the request through the Fireblocks Mobile app or Co-signer.

To attach or detach tags on a single vault account:

1. In the Fireblocks Console, go to Accounts > Vault and find the vault account you want to tag.
2. In the Tags column, select +.
3. Select the tags you want to attach or detach.
4. Select Apply.

To attach tags to multiple vault accounts at once:

1. In the Fireblocks Console, go to Accounts > Vault.
2. Select the checkbox for each vault account you want to tag.
3. Select Bulk attach tags.
   
4. Select the tags you want to attach.
5. Select Apply.

If a request contains a mix of protected and standard tags, the standard tag changes are applied immediately while the protected tag changes go through the approval flow.

Filtering vault accounts by protected tag

In Accounts > Vault, use the Tags filter to show only vault accounts that match one or more selected protected tags.

Editing a protected tag

Editing a protected tag's label, description, or color requires Owner, Admin, or Non-Signing Admin approval. The change is staged and applied only after the request is approved. A tag with a pending approval request cannot be edited again until the pending request is resolved.

1. In the Fireblocks Console, go to Settings > Tags (Utilities > Tags in some workspaces).
2. On the row of the tag you want to edit, select Edit tag.
3. Update the tag's details.
4. Select Save changes.

Deleting a protected tag

Before deleting a protected tag, detach it from all vault accounts. Deletion requires Owner, Admin, or Non-Signing Admin approval and is applied only after the request is approved.

1. In the Fireblocks Console, go to Settings > Tags (Utilities > Tags in some workspaces).
2. On the row of the tag you want to delete, select Delete tag.
3. Confirm the deletion.

Using protected tags in Policy rules

Once a protected tag is attached to vault accounts, you can reference it in Policy rules. At transaction submission time, Fireblocks evaluates the tags on the source and destination vault accounts and applies any matching rules.

Common patterns include:

• Require additional approvals for high-risk destinations. If the destination vault is tagged High-Risk, require approval from two designated approvers.
• Restrict outbound transactions to treasury vaults only. Allow outbound transactions only from vault accounts tagged Treasury.
• Block transactions to unlabeled vaults. Block any transaction to a vault account that does not have the Whitelisted tag.

Example: Geographic routing

Create protected tags for each operational region, such as US-East, EU-West, and APAC. Attach each tag to the vault accounts that operate in that region. In your Policy rules, you can then require transactions from US-East vaults to be signed by US-based co-signers, block transactions between EU-West and APAC vaults for compliance reasons, and apply different approval thresholds based on the source vault's geographic tag.

As your vault inventory grows, attach the relevant regional tag to new vaults; your Policy rules do not need to change.

Why use tags instead of vault IDs

Policy rules written around individual vault IDs break as your vault inventory grows. You need to update the rule every time a vault is added or removed. With protected tags, the rule stays fixed and you simply update which vaults belong to the tag, subject to quorum approval.

Wallet Pools: protected tags with transaction routing

Wallet Pools are a specialized type of protected tag that adds transaction routing to the governance model protected tags already provide. Where a standard protected tag groups vault accounts for policy enforcement, a Wallet Pool groups vault accounts as a single transaction source, distributing outgoing transactions across the pool using health-aware routing. Membership changes require the same quorum approval as any other protected tag, and pools can be referenced directly in Policy rules as a distinct source type. For high-volume operations where a single vault account would become a bottleneck, Wallet Pools are the recommended pattern. Learn more about Wallet Pools.

API

For all tag operations via API (including creating, listing, filtering, attaching, detaching, and managing approval requests), see Tags API reference.

When bulk-creating vault accounts via the API, you can attach standard and protected tags to all created accounts in the same request by including a tagIds array. If any of the specified tags are protected, an approval flow is triggered and an approvalRequestId is returned alongside the jobId.

Automation use cases

Tag-based automation is not currently supported. Tags and protected tags will become available as conditions and inputs in automation rules in a future release. This section describes the intended workflow once that support is in place.

Because protected tags represent stable, approval-controlled vault groupings, automation logic can operate on dynamic sets of vaults without hard-coding vault IDs or manually updating rules as the vault set changes.

Deposit sweeping

Group vault accounts that receive end-user deposits using a protected tag such as Deposit-Vaults. An automation rule will then be able to monitor all vaults with that tag, sweep incoming funds automatically, and transfer the funds to a designated omnibus or treasury vault. As new deposit vaults are added, attaching the tag will include them in the automation workflow automatically, with no change to the automation logic.

Limits and label rules

For all tag limits, label requirements, and constraints, see Tag Limits and Label Rules.

Frequently asked questions

Do I need approval to create a protected tag?

No. Creating a protected tag takes effect immediately. Approval is only required for edit, delete, attach, and detach operations.

Can I convert an existing standard tag into a protected tag?

Not currently. Protection status is set at creation time and cannot be changed afterward. If you need a protected version of an existing tag, create a new one with the Protected toggle enabled.

Can I undo a protected tag operation if I made a mistake?

If the approval request is still in PENDING, you can cancel it. If it has already been approved and applied, submit a new operation (for example, a detach request) to reverse it. The reversal also requires approval.

What happens if an approval request expires?

The change is not applied. Submit a new request.

Can I mix protected and standard tag operations in a single request?

Yes. Standard tag changes are applied immediately while protected tag changes go through the approval flow, all in the same request.

Who can approve a protected tag request?

The Owner, Admins, and Non-Signing Admins can approve protected tag operations, through the Fireblocks Mobile app or Co-signer.

Can I see which tags are on a vault account at any time?

Yes. Use GET /v1/vault/accounts/{vaultAccountId} to retrieve a single vault account with all attached tags and their metadata.

Are protected tags evaluated in real time during transactions?

Yes. At transaction submission time, Fireblocks fetches the current tags on the source and destination vault accounts and evaluates them against your active Policy rules before the transaction proceeds.