Skip to content

CONCEPT Cited by 1 source

Deny-by-default tool policy

Definition

A deny-by-default tool policy is the architectural posture for AI agent governance in which tools are denied unless explicitly allowed — the inversion of the empirically-common allow-by-default posture in early agent deployments where tools are available unless explicitly blocked.

"The default posture in most agent deployments is permissive: tools are available unless explicitly blocked. AgilityFeat's analysis of enterprise AI guardrails identifies the structural risk this creates, since an architecture not built on deny-by-default increases risk and creates upkeep costs." — Source: sources/2026-05-11-mongodb-fighting-tool-sprawl-the-case-for-ai-tool-registries

Why allow-by-default scales the attack surface

The structural property of allow-by-default is that each new agent deployment adds to the surface that security must monitor:

  • The cost of N agents is super-linear because each agent's policy is independent — security review burden grows with N.
  • Replicated across dozens of agent deployments, allow-by-default "produces an attack surface that scales with adoption."
  • Each new tool is automatically reachable by every agent unless someone — somewhere — adds an explicit block. The discovery problem ("who knew this tool existed?") doubles as the policy-gap problem ("who knew to block it?").

Inverting to deny-by-default flips this: each new tool is unreachable until something adopts it explicitly, and the adoption event becomes the review point at which security metadata is consulted.

The coordination point

Deny-by-default is not implementable per-team in isolation — it requires a coordination point:

"Inverting this requires a coordination point, a shared, organization-wide context. The registry itself isn't a governance layer, but it is what makes governance possible. When every tool an agent can use is registered with ownership, version, and review status, the governance layer has something concrete to enforce against."

The coordination point is the enterprise AI tool registry — the inventory substrate against which a deny-by-default policy can express "this tool is allowed for this agent identity in this environment for this action type." Without the registry, deny-by-default has nothing to allow against.

"A guardrail that references a tool the security team has never heard of cannot be written in the first place."

Composability with the policy layer

Deny-by-default at the tool layer is the default state that the policy layer (Frontegg-style guardrails, OPA, custom) writes exceptions against. The shape:

agent → policy layer → registry lookup → allow/deny
              ↓
         deny by default
              ↓
       except: explicit allow
       (per identity / team / env / action)

The policy layer's input is the registry's contents; the policy layer's output is the allow/deny decision; the default when no explicit allow exists is deny.

  • vs patterns/deny-overrides-allow: deny-overrides-allow is a conflict-resolution rule for when both allow and deny rules match (deny wins); deny-by-default is the base state before any rules match.
  • vs patterns/static-allowlist-for-critical-rules: static allowlist is a specific implementation choice (lists, not predicates) that composes naturally with deny-by-default but is one realisation among many.
  • vs concepts/centralized-ai-governance: centralised AI governance is the broader pattern of routing all AI traffic through one policy surface; deny-by-default is one of the policy postures that surface can implement (versus allow-by-default).

Open question: the bootstrapping problem

Deny-by-default introduces a bootstrapping cost: the first time an agent needs a new tool, something has to authorise it. The 2026-05-11 MongoDB post does not detail how to handle this — the canonical answers in production deployments tend to be:

  • Per-tool human-approval — the security team or the tool-owner approves the tool's registry entry at first registration, and per-agent allowlist is a separate event.
  • Pre-classified tool tiers — read-only tools are auto-allowed to broad agent populations; write/destructive tools require per-identity allow.
  • Sandbox-then-promote — a tool gets a sandboxed scope until someone reviews and promotes it.

The deny-by-default posture makes this bootstrapping cost explicit — the cost is upfront, not silently amortised across deployment until a security incident exposes it.

Seen in

Last updated · 542 distilled / 1,571 read