Destination Allowlists

Destination allowlists control where an agent can send data. They are the destination layer of MITRITY DLP.

Their companion is DLP pattern authoring, the content layer of DLP, which controls what data is allowed to flow. Together, the two layers give defence in depth:

• pattern bindings catch sensitive content, even when the destination is permitted;
• allowlists catch unapproved destinations, even when the payload looks innocuous.

This page covers the destination layer. For content patterns and per-policy bindings, see DLP Pattern Authoring.

Overview

An AI agent with network access could exfiltrate sensitive data to external services. Destination allowlists prevent this with a per-agent list of approved destinations. The gateway inspects every outbound request:

1. It extracts the destination URL from the agent's request.
2. It checks the URL against the agent's allowlist.
3. If the destination matches an approved pattern, the request proceeds, subject to policy evaluation (including any DLP content-pattern bindings).
4. If the destination does not match, the request is blocked and a DLP event is created.

Agent ──request──► Gateway ──check allowlist──► Approved? ──Yes──► Forward request
                                                    │ No
                                                    ▼
                                              Block + DLP event

The check runs when the policy's DLP mode is not off and the agent's allowlist has at least one entry. In log mode, a destination that does not match is recorded, and the request proceeds.

How Allowlists Work

Per-Agent Configuration

Each agent has its own destination allowlist. So a CRM agent can access api.salesforce.com while a data analytics agent cannot, even though they share the same tenant.

Domain Pattern Matching

Allowlist entries use domain patterns with optional path matching:

Protocol Handling

Allowlist patterns match regardless of protocol (HTTP or HTTPS). However, MITRITY logs a security warning if an agent tries to send data over unencrypted HTTP.

Port Handling

By default, patterns match the standard ports (80 for HTTP, 443 for HTTPS). To allow non-standard ports, include the port in the pattern:

api.internal.com:8080
*.internal.com:3000

DLP Event Types

When the edge's DLP checks fire, MITRITY records a DLP event with one of these types:

MITRITY records each detection with its type and the action taken. DLP Event Management says where you see detections.

Unauthorized Destination

This is the most common DLP event. The agent tried to send data to a domain or URL that is not on its allowlist.

Sensitive Exfiltration

The agent sent data that matches a sensitivity tag (pii, credentials or financial). The check runs after the allowlist check, so it also covers destinations on the allowlist. A destination that fails the allowlist is reported as an unauthorized destination instead.

Accumulation

The agent read sensitive data at least 10 times within an hour. Each read whose content matches a sensitivity tag counts, and is recorded as an inbound accumulation event with the action logged. Once the count reaches 10 within the hour, an outbound action from the agent that passes the destination and sensitive-data checks raises an accumulation event with the action alerted, and the action itself is not blocked. The window and the threshold are fixed.

Pattern Match

A DLP pattern that the agent's policy binds to the tool matched the content. What happens then is the binding's choice. DLP Pattern Authoring describes patterns and bindings.

Sensitivity Tags

Sensitivity tags identify data types that require special handling. MITRITY uses these tags to detect sensitive data in agent payloads and generate sensitive_exfil DLP events.

There are three tags. The set is fixed: whenever a policy's DLP mode is not off, the edge checks outbound payloads for all three.

Built-In Tags

Managing Allowlists

Via the Dashboard

1. Navigate to Agents > [Agent Name] and find Data Access > Destination Allowlist.
2. The current allowlist is displayed with all approved patterns.
3. Type a new pattern in the field (for example *.slack.com) and click Add.
4. Click the × next to a pattern to remove it.
5. Changes take effect immediately.

Add a Destination via API

curl -X POST https://api.mitrity.com/api/v1/agents/agt_sales-bot/destinations \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "domain_pattern": "api.salesforce.com"
  }'

Response (201 Created):

{
  "id": "dest_4k2m",
  "tenant_id": "tnt_4f9a",
  "agent_id": "agt_sales-bot",
  "domain_pattern": "api.salesforce.com",
  "created_at": "2026-03-01T10:00:00Z"
}

Destination Fields

A destination has no other settings.

List Destinations

curl https://api.mitrity.com/api/v1/agents/agt_sales-bot/destinations \
  -H "Authorization: Bearer mk_your-api-key"

Response:

[
  {
    "id": "dest_4k2m",
    "tenant_id": "tnt_4f9a",
    "agent_id": "agt_sales-bot",
    "domain_pattern": "api.salesforce.com",
    "created_at": "2026-03-01T10:00:00Z"
  },
  {
    "id": "dest_5n3p",
    "tenant_id": "tnt_4f9a",
    "agent_id": "agt_sales-bot",
    "domain_pattern": "*.sendgrid.com",
    "created_at": "2026-03-01T10:05:00Z"
  }
]

Remove a Destination

curl -X DELETE https://api.mitrity.com/api/v1/agents/agt_sales-bot/destinations/dest_4k2m \
  -H "Authorization: Bearer mk_your-api-key"

After removal, an agent action that targets the removed destination is blocked, as long as the allowlist still has other entries. An allowlist with no entries does not restrict destinations, except in the governed shell, where it allows no egress.

DLP Event Management

Finding DLP Blocks

When DLP blocks an action, the action's audit event records it with blocked_by set to dlp. In the dashboard, open the Audit Log and choose DLP in the blocking-component filter. Through the API:

curl "https://api.mitrity.com/api/v1/audit?agent_id=agt_sales-bot&blocked_by=dlp&limit=25" \
  -H "Authorization: Bearer mk_your-api-key"

See Audit Trail for the audit log itself. Each agent's page also shows the most recent actions that DLP blocked in the last 30 days, under Data Access > Recent DLP Blocks, with a link to the filtered audit log. DLP detections appear in the Sensitive data section of compliance reports, which counts the period's detections by action taken and lists the most recent ones, without the matched content. They also feed the DLP matches signal of the compliance Risk register.

DLP detections are not forwarded to your SIEM destinations. Those receive the decisions on agent actions.

Best Practices

Start with a Restrictive Allowlist

Begin with a minimal allowlist: only the destinations the agent absolutely needs. Add more as you identify legitimate use cases.

Use Specific Patterns

Prefer api.salesforce.com over *.salesforce.com. Broad wildcard patterns increase the risk of allowing unintended subdomains.

Review DLP Events Weekly

Schedule a weekly review of DLP events. Unauthorized destination events may indicate agent misconfiguration (legitimate destinations that need to be added) or genuine exfiltration attempts.

Combine with Tool Permissions

Destination allowlists complement agent permissions. Permissions control which tools an agent can use, and allowlists control where agents can send data. Use both, for defense in depth.

Related Documentation

• Tool Catalog: define and manage the tool catalog
• Agent Permissions: per-agent tool permission assignment
• Mesh Egress Allowlist: enforce these per-agent destination allowlists on agent traffic leaving an Istio mesh
• Injection Detection: detect prompt injection attacks
• Compliance Reports: DLP events in compliance reports
• API Overview: the full API reference