Injection Detection

Prompt injection is one of the most critical security threats to AI agents. An attacker crafts input that overrides the agent's instructions, causing it to perform unintended actions — exfiltrate data, bypass access controls, or execute malicious operations. MITRITY's injection detection system identifies these attacks in real-time and takes action before the compromised instruction reaches its target.

Overview

MITRITY inspects agent actions for prompt injection indicators using multiple detection methods. When a potential injection is detected, the system:

1. Assigns an injection probability score (0.0 to 1.0)
2. Identifies matched patterns describing the injection technique
3. Creates an injection event in the audit log
4. Takes the action you configured for the detection method that fired: block, alert, or log

Injection detection runs on every scanned agent action intercepted by the gateway, before policy rules are evaluated. A blocked injection therefore stops the action without any policy matching it.

Detection Methods

MITRITY uses four complementary detection methods. Each method produces an independent score, and the combined score determines the final injection probability.

Pattern Matching

Rule-based detection using a curated library of known injection patterns. This method catches common injection techniques with high precision and near-zero false positive rates.

Detected patterns include:

Statistical Analysis

Analyzes the statistical properties of the input to detect anomalies that suggest injection. This method catches novel injection techniques that do not match known patterns.

Signals analyzed:

• Entropy shift: Sudden change in information entropy within the input
• Language distribution: Deviation from the expected language model distribution
• Token frequency: Unusual frequency of command-like tokens
• Structural anomaly: Unexpected structural patterns (e.g., nested prompts within data)
• Length anomaly: Input significantly longer or shorter than the baseline for this action type

ML Classifier

A purpose-built machine learning classifier trained on labeled injection and benign samples. The classifier runs as part of the local DriftGuard model, providing sub-millisecond inference.

Model characteristics:

• Architecture: DriftGuard with an injection classification head
• Inference time: <0.5ms locally
• Model size: ~2MB (bundled with the gateway)
• Update frequency: Model updates are pushed via the heartbeat channel
• Training data: Curated dataset of 50,000+ labeled injection and benign samples

Combined Scoring

The final injection probability is a weighted combination of all detection methods:

combined_score = (pattern_score * 0.3) + (statistical_score * 0.2) + (ml_score * 0.5)

The weights are tuned to prioritize the ML classifier (highest accuracy) while giving significant weight to pattern matching (highest precision).

Injection Probability Scores

The injection probability score ranges from 0.0 (definitely benign) to 1.0 (definitely malicious):

These are guidance for reading a score, not a configuration. The outcome is decided by the per-method action settings below, not by score bands.

Configuring detection

Injection settings live in Settings > Security > Injection Detection and reach the edge in the agent's mission profile:

{
  "injection_detection": {
    "enabled": true,
    "pattern_matching": true,
    "statistical_analysis": true,
    "ml_classifier": false,
    "pattern_action": "block",
    "ml_action": "alert",
    "ml_threshold": 0.7,
    "scan_targets": ["llm:call", "mcp:*", "http:request", "builtin:*", "shell:*"]
  }
}

Two things are worth knowing about this model:

• There is no hold. An injection verdict is block, alert, or log. There is no alert_threshold / hold_threshold / deny_threshold triple and no human-approval queue for injections — a blocked action is denied outright. Holds come from approval workflows on policy rules.
• ml_threshold is the only score threshold. Pattern and statistical detections are not thresholded: any pattern hit fires pattern_action regardless of the score shown on the event.

The agent's injection mode sits above all of this. In log mode a would-be block is recorded as logged and the action proceeds; in off mode the scan does not run at all. Prompts sent through the LLM Gateway have a mode of their own, llm_injection_mode (enforce · alert · off, default alert): a hit in a prompt is recorded and the call proceeds unless the policy says enforce, while the tool call the prompt induces keeps injection_mode. off on injection_mode turns the scan off for prompts too.

Injection Events

When an injection is detected, an injection event is created in the audit log.

Event Structure

{
  "id": "inj_evt_8k2m",
  "tenant_id": "tnt_4f9a",
  "agent_id": "agt_support-bot",
  "agent_name": "support-bot",
  "event_id": "evt_71c2",
  "action_type": "mcp:web__fetch_url",
  "detection_method": "pattern",
  "injection_probability": 0.87,
  "matched_patterns": ["instruction_override", "data_exfiltration"],
  "flagged_content_hash": "9f2b1c…",
  "action_taken": "blocked",
  "false_positive": false,
  "occurred_at": "2026-03-01T14:30:00Z",
  "created_at": "2026-03-01T14:30:01Z"
}

detection_method is a single value — pattern, statistical, ml_classifier or combined — not a per-method breakdown. The flagged content itself is never stored: flagged_content_hash is a SHA-256 digest, so an event can be correlated without the payload leaving the edge.

Viewing Injection Events

Navigate to Security > Injection Detection in the dashboard. The injection events view shows:

• All detected injection attempts
• The injection probability and which detection method fired
• Matched pattern names
• Agent and action context
• False positive status

API Reference

List Injection Events

curl "https://api.mitrity.com/api/v1/injection-events?agent_id=agt_support-bot&limit=25" \
  -H "Authorization: Bearer mk_your-api-key"

Query parameters:

Score, outcome, false-positive and date filters are not supported on this endpoint — filter client-side, or use the SIEM feed for richer querying.

Response:

{
  "data": [
    {
      "id": "inj_evt_8k2m",
      "agent_id": "agt_support-bot",
      "agent_name": "support-bot",
      "action_type": "mcp:web__fetch_url",
      "detection_method": "pattern",
      "injection_probability": 0.87,
      "action_taken": "blocked",
      "matched_patterns": ["instruction_override", "data_exfiltration"],
      "false_positive": false,
      "occurred_at": "2026-03-01T14:30:00Z"
    }
  ],
  "meta": {
    "request_id": "req_inj001",
    "timestamp": "2026-03-01T15:00:00Z",
    "next_cursor": null,
    "total": 1
  }
}

Get a Single Injection Event

curl https://api.mitrity.com/api/v1/injection-events/inj_evt_8k2m \
  -H "Authorization: Bearer mk_your-api-key"

Returns the same event shape as the list endpoint.

Mark as False Positive

If an injection event is a false positive, mark it to improve future detection accuracy:

curl -X POST https://api.mitrity.com/api/v1/injection-events/inj_evt_8k2m/false-positive \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "false_positive": true,
    "reason": "Legitimate instruction from support workflow automation"
  }'

Response:

{
  "data": {
    "id": "inj_evt_8k2m",
    "false_positive": true,
    "false_positive_reason": "Legitimate instruction from support workflow automation",
    "false_positive_marked_by": "user_jsmith",
    "false_positive_marked_at": "2026-03-01T16:00:00Z"
  },
  "meta": {
    "request_id": "req_inj002",
    "timestamp": "2026-03-01T16:00:00Z"
  }
}

False positive feedback is used to retrain the ML classifier during the next model update cycle.

Get Injection Summary

curl "https://api.mitrity.com/api/v1/injection-events/summary" \
  -H "Authorization: Bearer mk_your-api-key"

Response:

{
  "data": {
    "total_events": 127,
    "blocked": 13,
    "alerted": 89,
    "by_method": {
      "pattern": 71,
      "statistical": 22,
      "ml_classifier": 18,
      "combined": 16
    },
    "by_agent": [
      { "agent_id": "agt_support-bot", "agent_name": "support-bot", "count": 78 },
      { "agent_id": "agt_chat-bot", "agent_name": "chat-bot", "count": 34 }
    ]
  },
  "meta": {
    "request_id": "req_inj003",
    "timestamp": "2026-03-01T17:00:00Z"
  }
}

False Positive Management

Common False Positive Scenarios

Reducing False Positives

1. Mark false positives promptly — This feeds the ML retraining pipeline.
2. Tune ml_threshold per agent — Customer-facing agents see more injection-like input than backend agents.
3. Use alert instead of block while you tune — or put the agent's injection mode in log while you measure, then switch to enforce.
4. Monitor the false positive rate — Target a false positive rate below 5%. If it is above 10%, your settings may be too aggressive.

Integration with Policies

Injection detection is its own stage of the governance pipeline, not a policy rule. The outcome comes from pattern_action and ml_action in the settings above and applies regardless of action type; scan_targets decides which action types are scanned at all.

There is no injection-score constraint on a policy rule. Rule constraints match the arguments of an action, and numeric constraints are integer upper bounds — see Writing Policies. A key such as injection_score_min is accepted by the API and then evaluated against nothing, so the rule matches as if it were not there.

Order matters here: the injection scan runs before policy rules are evaluated, so a detection set to block denies the action on its own, without any policy matching it. Policies decide what happens to the actions the scan lets through.

Best Practices

Enable Detection on All Agents

Injection attacks can target any agent, not just customer-facing ones. Enable detection across all agents and adjust ml_threshold and the two action settings to the agent's risk profile.

Separate the two detection paths

Keep pattern_action at block — a pattern hit is a known technique, not a guess — and ml_action at alert until you have measured the classifier's false-positive rate on your own traffic. Raising ml_threshold narrows the ML path without touching the pattern path.

Measure what gets through, not only what gets caught

Injection events tell you what detection caught. They cannot tell you what it missed. Red Teaming runs the other half of the measurement: it sends adversarial attempts at your own routes on a schedule and records the ones that reached their goal, so a detection gap shows up as a finding with a remediation rather than as silence in the event stream.

Review Injection Events Daily

Schedule daily reviews of injection events, especially in the 0.4-0.6 range. These borderline events are the most valuable for understanding your false positive rate and tuning ml_threshold.

Correlate with DLP Events

Injection attacks often precede data exfiltration. When you see an injection event, check for corresponding DLP events from the same agent.

Keep the ML Model Updated

The gateway receives ML model updates via the heartbeat channel. Ensure your gateway or sidecar maintains connectivity to the control plane for timely updates.

Related Documentation

• Red Teaming — Governed adversarial tests that measure what detection misses
• Delegation Chains — Govern agent-to-agent delegation
• Credential Broker — Secure credential management for agents
• Threat Intelligence — Shared threat feed for cross-tenant protection
• Destination Allowlists — DLP controls for data exfiltration prevention
• Approval Workflows — human-in-the-loop holds, which policy rules provide and injection verdicts do not