SIEM Integration

GrantFlow records every privileged action in its audit log: activations, approvals, role and policy changes, account checkouts, sign-in strength refusals and more. The audit feed lets your SIEM pull that log continuously, so you can correlate GrantFlow with the rest of your security data and alert on it.

The feed is pull-based. Your SIEM polls one HTTPS endpoint with a feed token and keeps a cursor; GrantFlow never pushes data out of your tenant. Each token reads the audit log of one GrantFlow tenant.

This guide is for administrators. It covers the feed tokens and what to watch. The per-SIEM guides cover the connection itself:

• Microsoft Sentinel
• Splunk
• Any other SIEM: also the full API and event reference

Before you start

You need:

• A GrantFlow administrator who can sign in with a strong method, such as a passkey or Windows Hello for Business. Creating a feed token needs it; see Step-up Authentication for every method that qualifies.
• A SIEM that can poll an HTTPS endpoint with a bearer token, and keep a small piece of state (the cursor) between polls.
• Outbound HTTPS from your SIEM's collector to the GrantFlow API.

If the panel says "The audit feed is not enabled for this deployment", the feed is switched off for your GrantFlow environment. Ask your GrantFlow contact to enable it. Existing tokens are still listed and can still be revoked.

1. Create a feed token

1. In GrantFlow, open Audit & Compliance → SIEM Integration.
2. Select New Token.
3. Enter a name that says which SIEM uses it, for example Sentinel SOC prod.
4. Choose how long it lives: 30, 90, 180 or 365 days. The default is 90.
5. Select Create Token. If your sign-in is not strong enough, GrantFlow asks for a stronger one first.
6. Copy the token now. It is shown once and never again. Store it in your SIEM's secret store.

The panel also shows the endpoint to poll and the header to send under Connect your SIEM. Copy both into your SIEM's configuration.

The token reads your whole audit log

A feed token is a bearer credential: whoever holds it can read every audit event of your tenant, including user names, IP addresses and justifications. Keep it in a secret store, never in a ticket, chat or repository.

Rules for tokens:

• Up to 20 active tokens per tenant. Use one token per SIEM, so you can revoke one without affecting the others.
• Names are 1 to 100 characters and unique among your active tokens. A name cannot contain gfa_, look like an ID, or contain control characters.
• A token belongs to the tenant, not to the administrator who created it. It keeps working if that person loses the Admin role or leaves. Review your tokens when administrators change.

2. Watch the token's state

Each token is a card in SIEM Integration. It shows the expiry, who created it, when it last polled, from which network and country, and how many events it has served. Its state is one of:

State	Meaning
Never used	No SIEM has polled with it yet.
Pulling	A SIEM polled within the last 30 minutes.
Stalled	No poll for 30 minutes. Check the SIEM connector. A SIEM set to poll less often than every 30 minutes always shows Stalled.
Expired	Past its expiry date.
Revoked	Revoked by an administrator.

Expires soon appears 14 days before the expiry. A filter at the top switches between Active, Revoked, Expired and All.

Pulling means the SIEM authenticated and polled. It does not prove the SIEM ingested the events; check that in the SIEM.

3. Replace a token without a gap

Tokens expire, so plan their replacement:

1. Create a new token.
2. Put it into the SIEM, in place of the old one. Keep the SIEM's cursor: the cursor belongs to your tenant, not to the token, so the SIEM continues where it stopped.
3. Wait until the new token's card shows Pulling.
4. Revoke the old token.

Revoking a token

Select Revoke on the token's card and confirm. The SIEM using it stops receiving events within 30 seconds. Revoking cannot be undone; create a new token instead.

You can also list and revoke tokens through GrantFlow's MCP server: ask for the "SIEM connections". Tokens can only be created in the web app.

Detecting a stolen token

GrantFlow audits how each token is used. These events appear in the audit log and in the feed itself:

Action	When
audit_feed_token.create	A token was created, or creation was refused (outcome denied) because the sign-in was too weak.
audit_feed_token.revoke	A token was revoked.
audit_feed_token.first_use	The token polled for the first time.
audit_feed_token.new_origin	The token polled from a different network or country than before. At most once an hour.
audit_feed_token.history_requested	Someone asked for history from a start time rather than continuing from a cursor. At most once an hour.
audit_feed_token.auth_failed	A request presented the token with a wrong secret, or presented a revoked token.

A new_origin or history_requested you did not expect, or a sudden jump in Events served, means someone else may be using the token. Revoke it and create a new one.

Secret scanning. Every token has the same shape, so secret scanners can find leaked ones. Add this pattern to your scanner (GitHub, GitLab or your DLP):

gfa_[0-9]{1,3}\.[A-Za-z0-9_-]{135}\.[0-9a-f]{8}

What the feed contains

• Every audit event GrantFlow records, as JSON in a stable, versioned format (schemaVersion "1"). See the event reference.
• Events appear in the feed about 60 seconds after they happen. The delay guarantees that a slow write is never skipped.
• Delivery is at least once: after a retry the SIEM can see an event twice. Deduplicate on the event's id.
• A backfill with start_time reaches back only to the GrantFlow release that began recording events for the feed, shortly before the feed itself shipped. Older audit events are not in the feed; they remain in GrantFlow's own audit log.