SIEM Integration

MITRITY can forward the decisions it makes about your agents' actions to your SIEM (security information and event management system). Your security team then sees agent governance next to the rest of your security data.

You add one or more destinations. MITRITY posts each runtime decision to every enabled destination that takes that decision. The same destinations also receive notification events, such as a finished compliance report or a resolved governance review.

What is forwarded

MITRITY forwards runtime decisions: one event for each action an agent took through a MITRITY edge (the runtime beside your agents), as recorded on the audit trail. Every forwarded event has the event_type agent_action, and events differ by their decision. Each destination chooses which decisions it receives:

alerted is an action that was allowed with an alert. held is an action held for human approval that was still pending when the edge answered. Allowed actions are high volume: turn on forward_allowed only if you need complete audit coverage.

Each event carries these fields. A field with no value is left out.

Nothing else is forwarded. DLP matches, activity imported from SaaS platforms and governance changes are recorded in MITRITY, and are not sent to SIEM destinations. DLP matches appear in the Sensitive data section of compliance reports and on the risk register. SaaS-platform activity and governance changes appear in the audit log, under their own sources.

Supported Destinations

A destination's type sets the format of what MITRITY posts to it. Every type is delivered the same way: see Delivery.

Splunk HTTP Event Collector (HEC)

A splunk_hec destination receives each event as JSON, wrapped in Splunk's HEC envelope:

{
  "event": {
    "id": "0c9f6d2e-3b41-4d8a-9e57-2f1a6b8c4d10",
    "tenant_id": "b2c3d4e5-6f70-4812-9a3b-4c5d6e7f8091",
    "event_type": "agent_action",
    "agent_id": "4f1d2c3b-5a69-4e7f-8a1b-2c3d4e5f6a7b",
    "action": "mcp:fs__write_file",
    "policy_id": "6e2a1c94-7b3d-4f58-a0c2-9d81e5f4b3a7",
    "decision": "blocked",
    "behavioral_hash": "9f86d081884c7d65",
    "drift_score": 0.42,
    "occurred_at": "2026-10-13T08:00:00Z",
    "created_at": "2026-10-13T08:00:01Z"
  },
  "sourcetype": "mitrity:audit",
  "source": "mitrity-iag",
  "time": 1791878400
}

time is when the action happened, in seconds since the epoch. You cannot set the source type or the index in MITRITY. Search for the events with sourcetype=mitrity:audit.

Syslog CEF (QRadar, ArcSight)

A syslog_cef destination receives each event as one CEF (Common Event Format) line. The line is the body of an HTTPS POST, with Content-Type: text/plain.

MITRITY does not send syslog over TCP or UDP. The endpoint must be an https:// URL that accepts CEF lines, and the API refuses a syslog:// URL with 400.

CEF:0|MITRITY|IAG|1.0|agent_action|mcp:fs__write_file|8|tenantId=b2c3d4e5-6f70-4812-9a3b-4c5d6e7f8091 agentId=4f1d2c3b-5a69-4e7f-8a1b-2c3d4e5f6a7b decision=blocked driftScore=0.4200 behavioralHash=9f86d081884c7d65 rt=1791878400000

Header fields escape \ and |, and extension values escape \, = and line breaks, as CEF requires. The extension keys are MITRITY's own, so map them in your SIEM. The CEF line carries no event ID.

Generic Webhook

A webhook destination, or a custom one, receives each event as a JSON object, with Content-Type: application/json. The object holds the fields under What is forwarded, plus two of its own:

• source: always mitrity-iag;
• forwarded_at: when MITRITY sent the event, in RFC 3339.

The only header you can set is Authorization, from the destination's auth_header, for example a bearer token. Other headers, such as an API-key header, are not supported.

Delivery

Delivery is best effort:

• each event gets one POST to each destination that takes it, with a 10-second timeout and no retry;
• a response of 400 or above, a timeout or a connection error is a failed delivery. It is recorded on the destination as last_error, and last_sent_at is cleared. The event is not sent again, and delivery to your other destinations goes on;
• events wait in a queue in the control plane before they are sent. When the queue is full, new events are dropped, and events still waiting when the control plane shuts down can be lost.

The audit trail keeps every event, so you can compare it with what your SIEM received, by event id.

The endpoint URL must:

• use https://;
• resolve to a public address. MITRITY does not deliver to private, loopback or link-local addresses, or to cloud metadata hosts;
• answer directly. MITRITY does not follow redirects.

MITRITY checks these rules again at every delivery.

Notification events

The same destinations also receive notification events: what the platform tells your team about, delivered to a system instead of a person.

You switch each notification kind on or off per destination type in Settings → Notifications, in the same matrix that routes Slack and email. The Webhook column sends that kind to every enabled webhook destination. There is no account-wide switch beside the destinations themselves: an enabled destination is where events go, and disabling it is how they stop. A syslog_cef destination receives runtime decisions only, never notification events.

Kinds that reach webhooks by default:

You can enable any other kind for webhooks in the matrix. Model risk findings and AIBOM drift advisories reach your destinations through their own richer payloads, and are not repeated through this channel.

Envelope

Every notification event is one POST with:

• Content-Type: application/json;
• your destination's stored authorization header;
• two request headers: X-Mitrity-Event (the kind) and X-Mitrity-Event-ID.

A Splunk HEC destination receives the envelope wrapped as {"event": …, "sourcetype": "mitrity:notification"}.

{
  "type": "governance.review_resolved",
  "version": "1.0",
  "event_id": "7b1c9a7e-8f2d-4a31-9c77-1d2e3f4a5b6c",
  "tenant": { "id": "b2c3d4e5-6f70-4812-9a3b-4c5d6e7f8091" },
  "severity": "info",
  "title": "Governance review attested",
  "body": "The onboarding review of Billing assistant was attested.",
  "link_url": "/app/governance/9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a",
  "generated_at": "2026-09-24T08:00:00Z",
  "payload": {
    "review_id": "9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a",
    "kind": "onboarding",
    "status": "attested",
    "subject_name": "Billing assistant",
    "dedup_key": "9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a"
  }
}

For governance.review_resolved, the title and body name the decision: approved, attested, sent back for changes or denied, as in Governance review sent back for changes and The risk assessment review of Billing assistant was sent back for changes. In the payload:

• status is the decision as the API names it: approved, attested, changes_requested or denied;
• kind is the kind of review: onboarding, risk_assessment, periodic_review, change or incident;
• subject_name is the agent's name, left out when the agent could not be read;
• dedup_key repeats the review id.

What every envelope guarantees:

• event_id is the same for every destination that received the event. Use it to deduplicate.
• title, body and link_url are what a person would have read in the dashboard, so a receiver that knows nothing about a kind can still file it. payload is the kind's own data. It never carries a credential, a prompt or a matched value.
• version stays 1.0 when a field is added, and changes when one is removed or renamed.
• A delivery that fails is recorded on the destination (the SIEM Integrations page shows the last error), and does not stop delivery to your other destinations.

Setup

In the dashboard, open Settings → Notifications, and choose Manage integrations under SIEM Destinations. The SIEM Integrations page lists your destinations, and Add Destination creates one. You can also use the API:

# Create a Splunk HEC destination
curl -X POST https://api.mitrity.com/api/v1/siem-destinations \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Splunk production",
    "destination_type": "splunk_hec",
    "endpoint_url": "https://your-splunk:8088/services/collector/event",
    "auth_header": "Splunk your-hec-token",
    "forward_blocked": true,
    "forward_alerted": true,
    "forward_allowed": false,
    "enabled": true
  }'

Owners and Managers manage destinations. Each destination reports its latest delivery as last_sent_at and last_error. GET /api/v1/siem-destinations lists them, and PUT or DELETE on /api/v1/siem-destinations/{id} updates or removes one.

A PUT replaces the destination's settings, so send every field: a flag you leave out is read as false. The auth_header is the exception:

• leave it out, and the stored header is kept;
• send an empty string to remove it;
• send a new value to replace it.

A stored header is never sent to a new endpoint. A PUT that changes endpoint_url must send auth_header again, or an empty string if the new endpoint needs none, and is refused with 400 otherwise. The dashboard asks for the same when you change a destination's endpoint.

You can configure several SIEM destinations. For example, send blocked and alerted decisions to your primary SIEM, and every decision to a long-term log archive.

Troubleshooting

• Events not arriving: open the destination on the SIEM Integrations page. A failed delivery shows its error. Check that the URL uses https://, resolves to a public address and does not redirect. See Delivery.
• Gaps in your SIEM: delivery is best effort, and a failed delivery is not retried. Compare your SIEM with the audit trail by event id.
• High volume: leave forward_allowed off unless you need every allowed action for compliance.
• Fields not parsed in QRadar or ArcSight: the CEF line uses MITRITY's own extension keys (tenantId, agentId, decision, driftScore, behavioralHash). Map them in your SIEM.