You already run AWS for the application stack and Microsoft Sentinel as the SIEM. IntentGate sits inline in front of your agent tool servers and emits audit events on every decision. Both lanes of your existing log pipeline pick those events up with no schema invention and no SOC retraining.

Reference topology

                         ┌─────────────────┐
                         │   IntentGate    │
                         │   gateway pod   │
                         └────┬──────┬─────┘
                              │      │
              audit events    │      │   audit events
              (hot lane)      │      │   (cold lane)
                              ▼      ▼
        ┌──────────────────────────┐   ┌─────────────────────┐
        │  Sentinel forwarder      │   │  S3 sink            │
        │  (built-in, Logs         │   │  (built-in, v1.7+)  │
        │   Ingestion API)         │   │  gzipped NDJSON     │
        └────────────┬─────────────┘   └──────────┬──────────┘
                     ▼                            ▼
        ┌──────────────────────────┐   ┌─────────────────────┐
        │  Sentinel Custom Table   │   │  S3 Standard        │
        │  IntentGate_CL           │   │  Hive partitions    │
        │  12 months hot           │   │  → Glacier IR       │
        └────────────┬─────────────┘   │  → Deep Archive     │
                     ▼                 └──────────┬──────────┘
        ┌──────────────────────────┐              ▼
        │  KQL queries / alerts    │   ┌─────────────────────┐
        │  Sentinel Analytics      │   │  Athena in-place    │
        └──────────────────────────┘   │  query (Glue table) │
                                       └─────────────────────┘

Hot lane · Microsoft Sentinel forwarder

The gateway ships a native Sentinel emitter targeting the modern Logs Ingestion API. It batches events, signs with an Azure AD service principal, and ships to a Data Collection Endpoint that routes into your Log Analytics workspace via a Data Collection Rule.

Operator steps:

  1. Provision a custom table IntentGate_CL in your Log Analytics workspace.
  2. Create the Data Collection Endpoint (DCE) and Data Collection Rule (DCR).
  3. Create an Azure AD service principal and grant it the Monitoring Metrics Publisher role on the DCR.
  4. Set six environment variables on the gateway pod and restart.

Gateway environment variables:

INTENTGATE_SIEM_SENTINEL_DCE_URL
INTENTGATE_SIEM_SENTINEL_DCR_ID
INTENTGATE_SIEM_SENTINEL_STREAM
INTENTGATE_SIEM_SENTINEL_TENANT_ID
INTENTGATE_SIEM_SENTINEL_CLIENT_ID
INTENTGATE_SIEM_SENTINEL_CLIENT_SECRET

Confirm the wiring with GET /v1/admin/integrations — look for name: "sentinel" with a recent last_flush_ts and non-zero events_flushed.

Cold lane · native S3 sink

Gateway v1.7+ ships a native S3 sink. The emitter writes batched audit events as gzipped NDJSON, keys them under a Hive-style partition tree (year=YYYY/month=MM/day=DD/hour=HH), and respects the bucket's default encryption.

Operator steps:

  1. Provision the S3 bucket and apply the lifecycle policy. Sample lifecycle policy on GitHub →
  2. Grant the gateway pod IRSA / instance-role write access to the prefix. Sample IAM policy →
  3. Set two environment variables on the gateway pod and restart.

Minimum required env vars:

INTENTGATE_SIEM_S3_BUCKET=my-audit-bucket
INTENTGATE_SIEM_S3_REGION=eu-west-1

Optional knobs are INTENTGATE_SIEM_S3_PREFIX, INTENTGATE_SIEM_S3_KMS_KEY_ID, and INTENTGATE_SIEM_S3_GATEWAY_ID. See the S3Config source for the full surface.

Athena Glue table

One CREATE EXTERNAL TABLE run once in Athena tells the Glue catalog how to read the JSON the gateway writes. The DDL uses partition projection so Athena infers partitions from the prefix template without a per-day MSCK REPAIR.

The DDL ships with the gateway and stays in sync with the audit event schema (a CI test fails if a field is added to audit.Event without a matching column in the DDL):

deploy/athena/intentgate_audit.sql →

To apply it from your Athena workgroup:

aws athena start-query-execution \
  --query-string "$(cat deploy/athena/intentgate_audit.sql)" \
  --result-configuration "OutputLocation=s3://your-query-results/"

KQL starter pack for the SOC

Sentinel KQL queries that answer the security-team questions IntentGate audit answers natively — denied calls, escalations, policy-check failures by rule, latency p95, etc. Pack lives in the gateway repo:

deploy/kql/ →

Copy any .kql file into Sentinel's Logs blade. Queries assume the custom table IntentGate_CL with the gateway's default field mapping.

Compliance reporting

Two complementary surfaces:

  • The hot lane satisfies SOC live-monitoring requirements (12 months retention in Sentinel).
  • The cold lane satisfies BIO, ISO 27001, and EU AI Act retention requirements (multi-year, Athena-queryable).

The gateway's own GET /v1/admin/audit/verify endpoint is the authoritative tamper-evident check; the S3 archive is the queryable surface for historical reporting. Treat them as complementary — /audit/verify answers "has the chain been tampered with," Athena answers "what happened."

Related

See Architecture for the gateway's deployment topology, the API reference for the audit and integrations endpoints, the deployment runbook for the day-1 install, and the gateway deploy directory for every code artifact this page references.