What belongs on a blocklist

A blocklist enumerates specific actions, destinations, or patterns an agent may never take. Common entries:

  • Destructive tools without approval: drop_table, delete_record in bulk, format.
  • Known-bad hosts: attacker domains, paste bins, personal email providers for outbound data.
  • Dangerous patterns: "ignore previous instructions", credential-shaped strings in outbound text.

Blocklists are the right tool for known threats you can name.

Blocklist vs allowlist

The weakness of a blocklist is the unknown. An attacker simply uses a host, tool, or phrase you did not list. An allowlist (default-deny) inverts this: the agent may only reach what you explicitly permit. For anything that moves data — email, HTTP, DB writes — allowlists are the safer posture.

Use both: an allowlist as the primary boundary, a blocklist as a fast reject for well-known bad patterns.

Maintaining the list

A stale blocklist is a false sense of security. Review it:

  • Whenever the agent's tools or integrations change.
  • Whenever a new injection pattern is observed in the wild.
  • On a fixed cadence (e.g. monthly) for high-risk agents.

Pair the list with logging so a blocked attempt is visible, not silent.

Where blocklists fail

  • Coverage gaps — anything not listed is allowed.
  • Obfuscation — "send the data" spelled creatively bypasses a keyword block.
  • Over-block — a too-aggressive list stalls legitimate work and trains users to bypass it.

Blocklists reduce known risk. They do not, by themselves, constitute oversight or safety. They are one control in a layered setup.

Authoritative references

  • OWASP LLM Top 10 — prompt injection: https://owasp.org/www-project-top-10-for-large-language-model-applications/
  • EU AI Act, robustness (Art. 15): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  • AI Act explorer: https://artificialintelligenceact.eu/