Safeguard Tag

Roadmap — not yet available. Safeguard Tag is a concept, not a shipping feature. This page documents the intended direction so you can evaluate it; it is not built and should not be planned against as one. It would build on the inbound-command hook already present in Safeguard's ChatOps integrations data model.

The idea behind Safeguard Tag is simple: instead of leaving a Slack, Teams, or Discord conversation to open Safeguard and act on something, you'd tag or @-mention Safeguard directly in the message — for example, on a thread flagging a suspicious dependency, or with an inline question — and have that count as a direct input to Safeguard, without a separate slash-command syntax or context switch. Nothing described on this page exists in the product today; it is a direction, not a spec.

Why this is plausible, not pure speculation

Safeguard's ChatOps integrations are documented today as outbound-only in the UI — Safeguard posts findings and events into a channel, but there's no way to talk back to Safeguard from inside Slack, Teams, or Discord. However, the underlying data model already has a hook for the inbound direction. As Bidirectional input (slash commands) documents, both the Slack and Discord integration configuration types (SlackConfiguration / CreateSlackConfigurationRequest and DiscordConfiguration / CreateDiscordConfigurationRequest) already include a slashCommandEnabled field. That field isn't exposed anywhere in the Settings connection flow, and there is no self-service way to turn it on — but its presence means Safeguard's integration model was architected to support a user sending something back into Safeguard from within a Slack or Discord conversation, not just receiving notifications.

Safeguard Tag, if built, would most likely build on that same foundation rather than a new integration path. That's the entire basis for calling this plausible: an existing field in the data model, not an announcement, a design doc, or a committed timeline. As the ChatOps page puts it, "the field being present doesn't guarantee a shipped, supported command surface yet" — and that caveat applies fully here.

A few things worth being precise about, since it's easy to over-read the connection:

• The slashCommandEnabled field is a boolean toggle for enabling some inbound command surface — it says nothing about an @-mention-based trigger specifically. Tag, as the name and this page describe it, is about tagging Safeguard in a message rather than typing a slash command, and no such mention-triggered mechanism exists in the data model today.
• The only @-mention-related fields that currently exist in the ChatOps data model (mentionUsers / mentionGroups, Slack-only) are for outbound notifications — they let a channel mapping ping a person or group when a finding fires. They are unrelated to Tag's proposed use of an @-mention as an inbound trigger, and should not be read as early evidence of one.
• Microsoft Teams has no equivalent hook. Neither TeamsConfiguration nor CreateTeamsConfigurationRequest has a slashCommandEnabled field or anything like it — Teams is notification-only at both the UI and data-model level. Of the three platforms, Teams is the weakest candidate for Tag, and any future design would need to solve inbound Teams interaction from scratch rather than extending an existing field.

Planned capabilities

Nothing below is built. This table sketches the kind of interaction the concept is aiming at, based on how it's been described, not a committed feature list.

To make the direction concrete rather than abstract: imagine a vulnerability alert lands in #security-alerts from an existing Safeguard notification, and a teammate replies in that same thread tagging Safeguard with something like "is this actually reachable in our checkout service?" instead of copying the package name into a separate Safeguard search. That is the shape of interaction Tag is aiming at — it is not a real command, syntax, or supported flow today; no such reply is understood by Safeguard in any channel right now.

What's unclear or unresolved

This is a name and a direction, not a specification. In particular, none of the following are decided or documented anywhere:

• What exact trigger syntax would be used — an @-mention, a reaction, a thread reply, or something else.
• What commands or questions Tag would actually support, or how responses would be scoped to a tenant, project, or user's permissions.
• Whether Tag would extend the existing slashCommandEnabled hook as-is, replace it, or require new data-model fields entirely.
• Whether Microsoft Teams would ever get an inbound path, given it currently has no equivalent field to build on.

If inbound, in-chat interaction with Safeguard matters to your workflow, ask your Safeguard account team about the current status — this page describes the reasoning for why it's plausible, not a delivery commitment.

Questions we expect

Does the slashCommandEnabled field mean Slack or Discord already support this? No. The field exists in the SlackConfiguration and DiscordConfiguration data models, but it isn't exposed anywhere in the Settings connection drawer, and there's no self-service way to turn it on. It's evidence the data model was built to support inbound interaction eventually — not a working feature you can enable today.

Can I enable Safeguard Tag for my workspace right now? No. Nothing on this page is built. There is no UI, trigger, command, or setting for it in Safeguard today, in Slack, Teams, or Discord.

Will this work in Microsoft Teams? Unclear, and it's the weakest case of the three platforms. Teams' configuration model (TeamsConfiguration / CreateTeamsConfigurationRequest) has no slashCommandEnabled field or equivalent — any inbound path for Teams would need to be designed from scratch rather than extending something that already exists.

Isn't this basically the same as the Slack mentionUsers/mentionGroups fields ChatOps already has? No, and it's worth being precise about the difference: those fields are outbound only — they let a channel mapping @-mention a person or group when a finding fires. Tag's proposed use of an @-mention is the opposite direction, as an inbound trigger a user sends to Safeguard. The two aren't related beyond both involving the @ symbol.

Is there a release date or committed timeline? No. This page exists to document the reasoning for why the idea is plausible, not to announce a feature. If timing matters to your evaluation, ask your Safeguard account team for the current status rather than inferring one from this page.

Related

• Slack, Teams & Discord — the existing ChatOps integrations, including the slashCommandEnabled data-model field this concept would likely build on.
• Griffin AI — Safeguard's existing natural-language query interface (e.g. asking about vulnerabilities, affected components, or licenses across your SBOM); the kind of question Tag envisions asking inline is conceptually similar to what Griffin already answers inside the Safeguard UI today.
• Guard SDK — embeds live Safeguard policy enforcement directly into your own agent or MCP server process, for teams who want programmatic rather than chat-based interaction today.