Permission Statements

Alongside the search QUERY command and the other commands, FSQL provides four statements for managing and inspecting access control in your Query tenant: GRANT, REVOKE, EXPLAIN GRANTS, and EXPLAIN GROUPS.

These let a tenant administrator control which groups and users can use or edit connectors and detections, and who can create new resources or read the audit log.

Unlike QUERY, these statements do not run a search. They are dispatched to Query's authorization service rather than the search engine. Every grant is scoped to the current tenant — the tenant of the authenticated caller — and there is no syntax for targeting another tenant.

📘

General notes

• Keywords are case-insensitive. GRANT, grant, and Grant are equivalent, as are the verb names (can_use, etc.).
• Multiple statements can be separated with ;.
• Comments use -- to the end of the line, either inline or on their own line.

How authorization works in Query

Before the syntax, a quick mental model of what you're granting, to whom, and over what.

Subjects — who you grant to. Permissions are granted to groups (and, where needed, individual users). Every tenant draws its groups from two sources:

• entra: — groups synced from your Entra ID / Active Directory directory.
• query: — Query-native groups, including the built-in admin and member groups.

Granting to a group is the usual path: it lets you manage access for many people at once and keeps permissions in sync as directory membership changes.

Verbs — what you grant. There are two kinds of verb, and the kind determines whether the statement needs an ON <resource> clause.

A resource verb names a specific connector or detection, so it requires an ON clause. A tenant verb applies to the whole tenant, so it must be used without ON. Using a resource verb without ON, or a tenant verb with ON, is a syntax error.

Objects — what a permission applies to. Resource verbs apply to a single connector or detection (see Resource references below). Tenant verbs apply to the tenant as a whole.

Resource references

A resource is CONNECTOR <ref>, DETECTION <ref>, or a #tag shortcut. A <ref> can be written four ways:

These forms apply equally to connectors and detections:

GRANT can_edit ON DETECTION brute-force      TO GROUP soc-analysts
GRANT can_edit ON DETECTION 'Brute force AD' TO GROUP detection-engineers

Tag shortcut. #<tag> expands to every connector currently carrying that tag at the moment the statement runs:

GRANT can_use ON #siem TO GROUP soc-analysts

This writes one grant per matching connector. It is a point-in-time expansion, not a live rule: connectors tagged siem later are not retroactively granted, and connectors that lose the tag keep grants already issued. If no connector carries the tag, the statement returns an error rather than silently doing nothing. Tag names are lowercase letters, digits, and /, 2–64 characters.

📘

The #tag shortcut applies to connectors only.

Identity references

The TO (for GRANT) and FROM (for REVOKE) clauses name the subject of the grant:

Group sources and ambiguity. As described above, groups come from the entra: and query: sources. If a bare group name matches in both sources, the statement fails with an ambiguity error and you must add the entra: or query: prefix. If the name matches no group, the statement fails with a "no group named … found" error. Use EXPLAIN GROUPS to discover the exact names available in your tenant.

GRANT

Grants a permission to a group or user.

GRANT <resource-verb> ON <resource> TO USER|GROUP <identity>
GRANT <tenant-verb>                 TO USER|GROUP <identity>

Examples:

-- Resource-scoped
GRANT can_use  ON CONNECTOR splunk-prod         TO GROUP 'SOC Analysts'
GRANT can_edit ON CONNECTOR 550e8400-...-440000 TO GROUP soc-analysts
GRANT can_use  ON #siem                         TO GROUP soc-analysts
GRANT can_edit ON DETECTION 'Brute force AD'    TO GROUP entra:detection-engineers
GRANT can_use  ON CONNECTOR splunk-prod         TO USER [email protected]

-- Tenant-scoped (no ON clause)
GRANT can_create_connector TO GROUP soc-leads
GRANT can_create_detection TO GROUP detection-engineers
GRANT can_read_audit       TO GROUP query:compliance-readers

Re-granting an existing permission is idempotent — it succeeds rather than complaining that the grant already exists. When a tag expands to several connectors, each grant is written independently; the result reports how many connectors were affected and lists any per-connector failures.

REVOKE

Mirrors GRANT, with FROM in place of TO.

REVOKE <resource-verb> ON <resource> FROM USER|GROUP <identity>
REVOKE <tenant-verb>                 FROM USER|GROUP <identity>

Examples:

REVOKE can_use  ON CONNECTOR splunk-prod FROM GROUP soc-analysts
REVOKE can_use  ON #siem                 FROM GROUP soc-analysts
REVOKE can_edit ON DETECTION brute-force FROM GROUP detection-engineers
REVOKE can_create_detection              FROM GROUP soc-leads

Revoking a permission that isn't currently in effect is a no-op success, not an error. For the #tag form, REVOKE removes grants from the connectors that carry the tag now — a connector granted under #siem that has since been untagged needs an explicit per-connector REVOKE.

EXPLAIN GRANTS

Lists the grants configured in the current tenant. Both filters are optional and can be combined.

EXPLAIN GRANTS [ON <resource>] [TO USER|GROUP <identity>]

Examples:

EXPLAIN GRANTS                                              -- all grants in this tenant
EXPLAIN GRANTS ON CONNECTOR splunk-prod                     -- grants on one connector
EXPLAIN GRANTS ON DETECTION 'Brute force AD'                -- grants on one detection
EXPLAIN GRANTS TO GROUP soc-analysts                        -- grants held by one group
EXPLAIN GRANTS ON CONNECTOR splunk-prod TO GROUP soc-analysts

Each row shows the subject (rendered as a group display name where known), the object (the connector or detection display name, or tenant for tenant-scoped grants), the relation, who granted it, and when. The relation column can show grants beyond the five verbs above (for example, admin) when they exist in the model.

EXPLAIN GROUPS

Lists the groups available to grant to in the current tenant — the discovery surface for finding the names to use in GRANT … TO GROUP.

EXPLAIN GROUPS [LIKE '<pattern>']

The optional LIKE pattern is a glob (shell-style wildcards: * matches any run of characters, ? matches one), matched case-insensitively against the display name. The quotes are required.

EXPLAIN GROUPS                 -- every group in this tenant
EXPLAIN GROUPS LIKE 'soc*'     -- groups whose name starts with "soc"

Each row shows the group's source (entra / query), its id, its display name, and — for the built-in Query groups — its system kind (admin / member).