Threat Intelligence

Threat intelligence matches your agents' actions against a shared, privacy-first feed of threat indicators specific to AI agent governance, and responds to each match the way you configure. Traditional threat intel focuses on network IOCs (indicators of compromise) and malware signatures. MITRITY's feed tracks behavioral patterns, injection signatures and tool abuse techniques observed across the platform.

Overview

The threat intelligence system operates on three principles:

• Privacy-first: no tenant data, agent identifiers or payloads are shared. Only anonymized, abstracted threat patterns are distributed.
• Tenant-isolated: each tenant's data is isolated. Threat indicators are generated from aggregate, anonymized observations.
• Actionable: every indicator includes a severity, a recommended action and detection rules that can be applied automatically.

When MITRITY detects a novel attack pattern against one tenant, it abstracts the pattern into a threat indicator and distributes it to all tenants through the threat feed. The more tenants use MITRITY, the stronger the threat detection becomes for everyone.

Indicator Types

An indicator is a single record with one pattern. The edge compiles that pattern as a Go RE2 regular expression, except for behavioral hashes, which are exact matches. Otherwise, indicators are always regular expressions, with no regex: prefix.

• Indicators reach the edge on the heartbeat.
• The edge evaluates them on every action, sorted critical-first, and the first match wins.
• The edge skips a pattern that does not compile.
• Matching is unanchored, so anchor with ^ and $ when you mean the whole value.

The target depends on the surface:

• on MCP surfaces, the tool name (so <action type>:<target> repeats it);
• for mesh egress, the destination host;
• for LLM calls, provider:model.

Because the target carries this per-surface detail, tool_abuse_pattern and delegation_pattern can express something an action_pattern cannot.

Indicators are point-in-time matches on a single action. "A followed by B within a window" is not something an indicator can express, and a behavioral hash fingerprints a single action too. Behavior across several actions is what the edge's drift score measures, when ML is on (see Core Concepts).

Every indicator has the same shape:

{
  "id": "5d4e3f2a-1b2c-4d5e-9f8a-7b6c5d4e3f2a",
  "indicator_type": "action_pattern",
  "pattern": "^mcp:fs__(list_directory|enumerate|walk)$",
  "name": "Recursive filesystem enumeration",
  "description": "Systematic directory enumeration is the reconnaissance step observed before bulk exfiltration attempts across the platform.",
  "severity": "high",
  "feed": "platform_generated",
  "contributing_tenant_count": 3,
  "total_event_count": 47,
  "enabled": true,
  "expires_at": null,
  "created_at": "2026-02-15T08:00:00Z",
  "updated_at": "2026-02-28T14:30:00Z"
}

Action Pattern

Matches the action type alone. Use it for tools or tool families that are dangerous regardless of arguments:

{
  "indicator_type": "action_pattern",
  "pattern": "^mcp:[^:]+__(run_command|exec|shell)$",
  "name": "Shell execution through an MCP tool",
  "severity": "medium",
  "feed": "mitrity_curated"
}

Behavioral Hash

Matches the exact behavioral hash that the edge computes for an action: a SHA-256 over the agent's ID, the action type, the target and the parameters (see Core Concepts). Because the agent's ID is part of it, the hash identifies one agent's exact action. pattern holds the 64-character hex value verbatim:

{
  "indicator_type": "behavioral_hash",
  "pattern": "5f0c1e2b9a7d4c3e8b6a1f0d2c9e7b4a3d8f6e1c0b2a9d7e5c4b3a2f1e0d9c8b",
  "name": "Recorded exfiltration call",
  "description": "The exact action an agent took in a confirmed exfiltration incident.",
  "severity": "critical",
  "feed": "platform_generated"
}

Injection Signature

Matched against the action type, and then the target. On MCP surfaces the target is the tool name, so this catches tools whose names smuggle instructions, such as a malicious MCP server advertising ignore_previous_instructions. Request payloads are scanned by the prompt injection engine, not by indicators:

{
  "indicator_type": "injection_signature",
  "pattern": "(?i)(ignore|override|disregard)_(previous|prior|system)_(instructions|prompt)",
  "name": "Instruction-override tool name",
  "severity": "high",
  "feed": "mitrity_curated"
}

Tool Abuse Pattern

Matched against <action type>:<target>, so the pattern can constrain both the tool and where it is pointed:

{
  "indicator_type": "tool_abuse_pattern",
  "pattern": "^llm:send:(openai:gpt-3\\.5-turbo|anthropic:claude-2)",
  "name": "Deprecated model family in use",
  "severity": "medium",
  "feed": "mitrity_curated"
}

For an LLM call, the matched string is llm:send:openai:gpt-3.5-turbo:openai:gpt-3.5-turbo, so the pattern above fires. For mesh egress, it is egress:send:<...>:<destination host>.

Delegation Pattern

Matched against <action type>:<target> for delegation hops:

• on the mesh, an agent-to-agent hop has the action type delegate:delegate_to, and the callee's agent ID as target;
• through the gateway, the hop is the MCP tool call mcp:delegate__delegate_to, with the tool name as target.

{
  "indicator_type": "delegation_pattern",
  "pattern": "^delegate:delegate_to:",
  "name": "Agent-to-agent delegation over the mesh",
  "severity": "medium",
  "feed": "mitrity_curated"
}

For a mesh hop to the agent 3f2a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c, the matched string is delegate:delegate_to:3f2a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c, so the pattern above fires.

Severity Levels

Each indicator is assigned a severity level:

Feed Sources

Indicators come from three sources:

MITRITY Curated

Hand-crafted indicators maintained by the MITRITY security research team. These are high-confidence, well-documented patterns, based on active research and incident analysis.

• Update frequency: weekly, or as needed for critical threats
• Confidence: very high
• Documentation: detailed analysis and remediation guidance included

Platform Generated

Generated automatically by MITRITY's ML models, from patterns observed across the platform. These indicators represent anomalies detected at scale.

• Update frequency: continuous
• Confidence: high (validated by ML models)
• Documentation: an automated description with statistical context

Community

Indicators submitted by MITRITY customers through the threat submission API. The MITRITY security team reviews and validates community indicators before distribution.

• Update frequency: varies
• Confidence: moderate (requires validation)
• Documentation: a submitter-provided description, validated by MITRITY

Tenant Matching

MITRITY matches threat indicators against the actions of agents whose policy has the Threat Intelligence feature on (Log or Enforce). A new policy has it Off, so turn it on in each policy where you want matching. When MITRITY finds a match, it creates a tenant match event.

How Matching Works

1. The control plane sends the indicators of your subscribed feeds to the edge, in the mission profile of each agent whose policy has Threat Intelligence on. New indicators arrive with the heartbeat.
2. The edge (gateway, sidecar, mesh authorizer or LLM gateway) evaluates each agent action against the active indicator set.
3. On a match, the edge decides the action, as described in Actions on a Match. A blocked result denies the agent's action when the policy is on Enforce.
4. The edge reports the match, and the control plane records it as a match event.

Actions on a Match

The edge decides what a match does, in this order:

1. A per-indicator suppression: silent drops the match, and log_only records it as suppressed.
2. A per-indicator severity_override replaces the indicator's severity for the next steps.
3. A per-indicator action_override decides the action.
4. Otherwise, the tenant's per-severity action for that severity (critical_action, high_action, medium_action, low_action or info_action), if one is set.
5. Otherwise, the tenant's default_action.

By default, a match of any severity is alerted, not blocked: default_action is alert, and no per-severity action is set. To block critical matches, set critical_action to block, or in the dashboard, set Per-Severity Actions → Critical to Block on the Settings tab.

The policy's Threat Intelligence mode applies last. On Log, a blocked result is recorded as logged, and the action proceeds. On Enforce, a blocked result denies the action. The edge also has a built-in fallback, critical and high block and the rest alert, for a profile that carries indicators without a tenant action policy, but the control plane always sends the two together.

Match Event Structure

{
  "id": "0c5d4f3a-1b2c-4d5e-9f8a-7b6c5d4e3f2a",
  "tenant_id": "9f8a7b6c-5d4e-3f2a-1b2c-4d5e6f7a8b9c",
  "indicator_id": "5d4e3f2a-1b2c-4d5e-9f8a-7b6c5d4e3f2a",
  "indicator_name": "Recursive filesystem enumeration",
  "indicator_type": "action_pattern",
  "agent_id": "1b2c4d5e-6f7a-8b9c-0d1e-2f3a4b5c6d7e",
  "agent_name": "data-bot",
  "event_id": "3f2a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c",
  "matched_value": "mcp:fs__list_directory",
  "action_taken": "alerted",
  "severity": "high",
  "occurred_at": "2026-03-01T14:30:00Z",
  "created_at": "2026-03-01T14:30:01Z"
}

action_taken is one of blocked, alerted, logged or suppressed. The suppressed value appears only when a per-tenant suppression with mode: log_only was active at match time: see Suppressions below.

Viewing Matches

To see all indicator matches for your tenant, go to Security > Threat Intel in the dashboard and open the Matches tab.

Settings

Tenant-Wide Settings

Tenant-wide threat-intel settings cover four things:

• the feeds you subscribe to;
• the opt-in to contribute anonymized data;
• the default action applied to every match that doesn't have a per-indicator override;
• optional per-severity actions, which replace the default action for one severity.

curl https://api.mitrity.com/api/v1/threat-intelligence/settings \
  -H "Authorization: Bearer mk_your-api-key"

{
  "id": "5d4e3f2a-1b2c-4d5e-9f8a-7b6c5d4e3f2a",
  "tenant_id": "9f8a7b6c-5d4e-3f2a-1b2c-4d5e6f7a8b9c",
  "contribute_data": true,
  "subscribed_feeds": ["mitrity_curated", "platform_generated", "osv"],
  "default_action": "alert",
  "critical_action": "block",
  "high_action": null,
  "medium_action": null,
  "low_action": null,
  "info_action": null,
  "created_at": "2026-02-01T00:00:00Z",
  "updated_at": "2026-03-01T00:00:00Z"
}

Update with PUT /api/v1/threat-intelligence/settings:

curl -X PUT https://api.mitrity.com/api/v1/threat-intelligence/settings \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "contribute_data": true,
    "subscribed_feeds": ["mitrity_curated", "platform_generated", "osv"],
    "default_action": "alert",
    "critical_action": "block"
  }'

Members and above can update the settings, and Viewers receive 403 Forbidden. In the dashboard, Owners and Managers change these settings.

Per-Indicator Overrides

You can override the severity or action of a specific indicator within your tenant. Overrides need the Pro plan or above.

curl -X PUT https://api.mitrity.com/api/v1/threat-intelligence/indicators/5d4e3f2a-1b2c-4d5e-9f8a-7b6c5d4e3f2a/override \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "severity_override": "critical",
    "action_override": "block",
    "note": "Verified this pattern matches a real incident in our environment"
  }'

Overrides take precedence over default_action. Remove an override entirely with DELETE:

curl -X DELETE https://api.mitrity.com/api/v1/threat-intelligence/indicators/5d4e3f2a-1b2c-4d5e-9f8a-7b6c5d4e3f2a/override \
  -H "Authorization: Bearer mk_your-api-key"

DELETE /override clears all override fields and any active suppression on that indicator. If you only want to lift the suppression and keep the severity/action tweaks, use DELETE /suppress (below).

Tenants on the Starter plan receive 402 Payment Required with code: plan_upgrade_required when calling these endpoints.

Suppressions

Suppressions silence noisy indicators for your tenant, without dropping them from the feed entirely. They need the Pro plan or above.

There are two modes. Pick one when you suppress, depending on whether you want the audit trail:

curl -X POST https://api.mitrity.com/api/v1/threat-intelligence/indicators/5d4e3f2a-1b2c-4d5e-9f8a-7b6c5d4e3f2a/suppress \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "mode": "log_only",
    "until": "2026-06-01T00:00:00Z",
    "reason": "Known maintenance run; revisit after the migration completes"
  }'

Expired suppressions stop applying immediately, because the check happens at match-evaluation time, not in a cron job. To lift a suppression early, use DELETE:

curl -X DELETE https://api.mitrity.com/api/v1/threat-intelligence/indicators/5d4e3f2a-1b2c-4d5e-9f8a-7b6c5d4e3f2a/suppress \
  -H "Authorization: Bearer mk_your-api-key"

DELETE /suppress clears only the suppression fields and preserves any severity or action override on the same indicator.

Review suppressions quarterly. Once the temporary justification is gone, the suppressed indicators are often the ones most worth your attention.

API Reference

All threat-intelligence endpoints are mounted at /api/v1/threat-intelligence. Bearer-token auth is required throughout; see API Overview for the auth scheme.

List Indicators

curl "https://api.mitrity.com/api/v1/threat-intelligence/indicators?severity=critical&indicator_type=injection_signature" \
  -H "Authorization: Bearer mk_your-api-key"

Returns the indicators visible to your tenant, that is, the indicators of the feeds you subscribe to in settings.subscribed_feeds. The response includes a per-tenant override object when one is set for that indicator.

Query parameters are all optional and independently composable. Empty-string values are treated as absent, and invalid values return 400.

Response:

[
  {
    "id": "7b6c5d4e-3f2a-1b2c-4d5e-9f8a7b6c5d4e",
    "indicator_type": "injection_signature",
    "pattern": "(?i)ignore\\s+previous\\s+instructions",
    "name": "Prompt injection: ignore previous",
    "description": "Detects common prompt-injection pattern",
    "severity": "high",
    "feed": "mitrity_curated",
    "contributing_tenant_count": 12,
    "total_event_count": 87,
    "enabled": true,
    "expires_at": null,
    "created_at": "2026-02-25T16:00:00Z",
    "updated_at": "2026-03-01T11:00:00Z",
    "override": {
      "severity_override": "critical",
      "action_override": "block",
      "suppressed_mode": null,
      "suppressed_until": null,
      "suppressed_reason": null,
      "note": "Verified incident in production",
      "created_at": "2026-03-01T09:00:00Z",
      "updated_at": "2026-03-01T09:00:00Z"
    }
  }
]

Get Indicator

curl https://api.mitrity.com/api/v1/threat-intelligence/indicators/7b6c5d4e-3f2a-1b2c-4d5e-9f8a7b6c5d4e \
  -H "Authorization: Bearer mk_your-api-key"

Returns a single indicator, in the same shape as one element of GET /indicators, including the override object when present.

Set / Clear Override

See Per-Indicator Overrides above for the request body and semantics.

PUT    /api/v1/threat-intelligence/indicators/{id}/override
DELETE /api/v1/threat-intelligence/indicators/{id}/override

Suppress / Lift Suppression

See Suppressions above for the request body and the log_only vs silent modes.

POST   /api/v1/threat-intelligence/indicators/{id}/suppress
DELETE /api/v1/threat-intelligence/indicators/{id}/suppress

List Matches

curl "https://api.mitrity.com/api/v1/threat-intelligence/matches?limit=50&offset=0" \
  -H "Authorization: Bearer mk_your-api-key"

Query parameters:

Returns an array of match-event objects, sorted by occurred_at desc.

Match Summary

curl https://api.mitrity.com/api/v1/threat-intelligence/matches/summary \
  -H "Authorization: Bearer mk_your-api-key"

Aggregate counts across all matches for the calling tenant: lifetime totals, with no time window.

Response:

{
  "total": 47,
  "by_severity": {
    "critical": 2,
    "high": 9,
    "medium": 21,
    "low": 12,
    "info": 3
  },
  "by_action": {
    "blocked": 11,
    "alerted": 28,
    "logged": 4,
    "suppressed": 4
  },
  "by_type": {
    "injection_signature": 18,
    "tool_abuse_pattern": 14,
    "behavioral_hash": 9,
    "action_pattern": 5,
    "delegation_pattern": 1
  },
  "top_agents": [
    {
      "agent_id": "1b2c4d5e-6f7a-8b9c-0d1e-2f3a4b5c6d7e",
      "agent_name": "data-bot",
      "match_count": 12
    }
  ]
}

Trending Indicators

curl "https://api.mitrity.com/api/v1/threat-intelligence/trending?window_days=30&limit=20" \
  -H "Authorization: Bearer mk_your-api-key"

Indicators ranked by how many times they fired against your tenant within a rolling window. This endpoint powers the Landscape view in the dashboard.

Both query parameters are optional.

Response:

[
  {
    "indicator": { "id": "…", "name": "…", "severity": "high", "indicator_type": "injection_signature", "...": "..." },
    "match_count": 42,
    "affected_agent_count": 3,
    "first_match_at": "2026-05-15T10:00:00Z",
    "last_match_at": "2026-05-21T20:00:00Z"
  }
]

The indicator field uses the same shape as the List Indicators response, including the per-tenant override object when one is set. Ties on match_count break by last_match_at desc.

Settings

See Tenant-Wide Settings above.

GET /api/v1/threat-intelligence/settings
PUT /api/v1/threat-intelligence/settings

Dashboard Features

Indicators

The Indicators tab at Security > Threat Intel shows the active indicators visible to your tenant: name, type, severity, feed, pattern and expiry. Rows with a per-tenant override show a Tuned or Suppressed (log only / silent) badge in the Override column. Their severity cell shows the effective severity, with the original feed value crossed out alongside.

The action column on each row lets members and above:

• Set or clear a severity / action override.
• Suppress an indicator (log-only or silent, with optional expiry).
• Lift a suppression early.

These actions require the Pro plan. Tenants on Starter see a Pro → upgrade link in place of the row actions.

Matches

The Matches tab shows every threat match recorded for your tenant: when it happened, which agent triggered it, which indicator matched, the action taken (blocked, alerted, logged or suppressed), and the severity at the time of the match. Log-only suppressions appear here too, marked with action_taken: suppressed.

Landscape

The Landscape tab ranks indicators by how often they fired in a rolling window (7 / 30 / 90 days, switchable inline). Each row shows the indicator name, type, severity, match count, the number of distinct agents that triggered it, and how recently it last fired. Use it to spot noisy indicators that are candidates for a tenant override, or real attack-pattern spikes that warrant investigation.

Settings

The Settings tab covers the tenant-wide controls:

• Contribute anonymized data: a toggle for contributing to the community feed.
• Subscribed feeds: which of mitrity_curated, platform_generated and community your tenant ingests.
• Default action: what happens on every match, unless a per-severity action or a per-indicator override says otherwise.
• Per-Severity Actions: an action for each severity, or Follow default.

Best Practices

Stay Subscribed to the Curated Feed

The mitrity_curated feed is the highest-confidence source, so keep it in subscribed_feeds. Adding platform_generated and community brings broader coverage, at the cost of more noise.

Pick a Sensible Default Action

default_action: alert is the safe choice for most tenants: matches are logged and shown in the dashboard, without blocking legitimate agent activity. Move to block only once you've reviewed at least a week of alerted matches, and know what you'd be blocking. To block only the most severe matches, keep default_action: alert and set critical_action: block.

Override Before You Suppress

If a single indicator is misfiring on legitimate agent activity, try a severity / action override first: severity_override: low plus action_override: log keeps the indicator active but quiet. Reserve suppression for indicators that you've decided don't apply to your environment at all.

Prefer log_only Suppression

Log-only suppression keeps the audit trail. Use silent only when the noise is truly overwhelming (e.g. an indicator firing thousands of times against an internal red-team exercise). Without the audit trail, you lose the ability to spot, after the fact, real incidents that the suppression was hiding.

Set an Expiry on Suppressions

Suppressions without until are permanent and easy to forget. Default to a 30- or 90-day expiry, and let the next firing remind you to revisit. Expired suppressions stop applying immediately, with no cron lag.

Review Matches Regularly

Review threat intelligence matches every week. Even matches that were logged (not blocked) may indicate probing or reconnaissance activity.

Correlate with Other Security Signals

Threat intelligence matches are most valuable when you correlate them with other security signals: injection events, DLP events and delegation anomalies. The dashboard provides cross-referencing for this.

Related Documentation

• Injection Detection: prompt injection detection and response
• Delegation Chains: agent-to-agent delegation governance
• Credential Broker: secure credential management
• Destination Allowlists: DLP destination controls
• ML Insights: ML-driven behavioral analytics