The AI agent blast radius formula: mathematical safety in production

Why perimeter security fails for autonomous agents

Enterprise security historically operated on the assumption of trusted actors inside a hardened perimeter. If an identity authenticated via Single Sign-On (SSO) and satisfied network access control policies, systems granted execution privileges to the designated database role.

Autonomous AI agents break this security model. An agent is neither a human engineer nor a static background cron job. It is a probabilistic reasoning engine operating with credentials to mutate production state.

When an autonomous agent connects to PostgreSQL, Stripe, GitHub, or an Electronic Health Record system, perimeter firewalls cannot predict what commands the agent will generate. A prompt injection attack, a context drift episode, or a multi-turn hallucination can cause the model to issue catastrophic statements through an authenticated channel.

If an agent holds a connection string with broad database privileges, a single instruction like DROP TABLE orders CASCADE or UPDATE users SET balance = 0 executes instantly. The firewall observes only an authenticated connection from an authorized host.

To evaluate whether an autonomous agent is safe to deploy, engineering leads and risk committees cannot rely on perimeter defenses. They must calculate the agent blast radius: the maximum potential damage the agent could inflict if its reasoning fails completely.

The blast radius formula

Deedglass evaluates agent security through a mathematical formula implemented in the open-source CLI scanner. The core assessment formula starts from a baseline of 100 points and applies bounded deductions based on physical configuration risks:

Code What the screen or file shows, copied as is.

Points = 100
       - 35 (if the database role is a superuser or has BYPASSRLS)
       - 20 x min(2, high findings)
       -  8 x min(3, medium findings)
       -  4 x min(5, write paths with no check)

Points = max(Points, 0)
Grade  = A (>= 90), B (80 to 89), C (65 to 79), D (50 to 64), F (< 50)

This quantitative formula translates architectural vulnerabilities into an unambiguous risk grade according to the published scan grade formula.

The formula models four fundamental dimensions of operational risk:

Code What the screen or file shows, copied as is.

Blast Radius = Credential Depth + Mutation Scope + Reversibility Deficit + Unverified Paths

Each dimension reflects physical state at the storage and operating system layers, rather than subjective evaluations of prompt quality.

Evaluating the four variables

To understand how the formula prevents catastrophic deployment failures, we examine each risk dimension in detail:

1. Credential depth (35 point deduction)

The most dangerous vulnerability in modern agent deployments is excessive privilege assignment. Developers testing Cursor, Claude Code, or LangGraph assistants frequently copy their personal development database URL into agent configuration files:

Code What the screen or file shows, copied as is.

DATABASE_URL="postgresql://postgres:secret@localhost:5432/app_production"

The postgres role is the bootstrap superuser. A superuser bypasses all Row-Level Security (RLS) policies, can truncate any table in any schema, can create or drop database roles, and can execute operating system commands via untrusted procedural languages.

If an agent holding superuser privileges is tricked by indirect prompt injection or enters a hallucination loop, no internal database guardrail can stop it. The formula penalizes superuser credentials and BYPASSRLS flags with an immediate 35-point deduction, dropping the maximum possible grade to 65 (Grade C).

2. High-severity findings (20 points each, capped at 40)

High-severity findings represent direct execution vectors that allow an agent to perform destructive modifications without approval. Examples identified by npx deedglass scan include:

• Archived or unmaintained MCP database servers: Running database connectors with unpatched SQL injection vulnerabilities or broken connection pooling.
• Auto-approve mode in shell environments: Configuring coding assistants with flags that automatically execute shell scripts without human review.
• Unbounded DDL privileges: Granting agents ALTER TABLE, DROP TABLE, or CREATE TABLE permissions on production schemas.

Each high finding deducts 20 points, capped at two findings (40 points total).

3. Medium-severity findings (8 points each, capped at 24)

Medium-severity findings reflect configuration weaknesses that increase the likelihood of data leaks or privilege escalation:

• Database connection strings with plaintext credentials stored in client configuration files rather than environment variables.
• Roles holding CREATEROLE or REPLICATION attributes that exceed task requirements.
• Granted EXECUTE privileges on SECURITY DEFINER functions that run with the privileges of the function creator.

Each medium finding deducts 8 points, capped at three findings (24 points total).

4. Write paths with no check (4 points each, capped at 20)

A write path is any tool, function, or database socket capable of altering persistent state: inserting rows, updating balances, deleting records, or issuing payments.

If an agent has access to 5 tools that modify data (e.g., postgres.execute, stripe.create_refund, github.merge_pr), and none of those tools are routed through a deterministic admission gate with write-ahead log verification, each unrouted path deducts 4 points (up to 20 points).

A setup with superuser credentials (-35), one high finding (-20), two medium findings (-16), and five unrouted write paths (-20) scores 9 points: an undeniable Grade F.

Deductions and scoring in practice

To illustrate how the blast radius formula applies to real-world architectures, consider three typical deployment stages:

Scenario A: The default developer setup (Grade F)

A platform team connects Cursor Composer to their development database to assist with schema migrations and test fixture generation:

• The agent connects using the default postgres role (-35 points).
• The reference PostgreSQL MCP server has write privileges to all tables without an admission gate (-20 points, high finding).
• Plaintext database credentials sit in .cursor/mcp.json (-8 points, medium finding).
• Six database tables are directly writable without change-log verification (-20 points for 5 capped write paths).

Calculation: 100 - 35 - 20 - 8 - 20 = 17 points (Grade F).

If the model hallucinates during a refactoring task, it can drop production tables, alter foreign keys, or wipe out historical records. You can experience this exact failure mode in the interactive playground, where an agent updating order statuses inadvertently triggers a trigger that alters 301 records.

Scenario B: Hardened permissions without admission gates (Grade C)

The team revokes superuser privileges and assigns the agent a custom role agent_user:

• Superuser deduction eliminated (0 points deducted).
• Credentials moved to environment variables (0 points deducted).
• The agent retains UPDATE and DELETE privileges on 5 tables without admission gates (-20 points).
• The agent configuration lacks a policy restricting statement kinds (-8 points).

Calculation: 100 - 0 - 0 - 8 - 20 = 72 points (Grade C).

The setup is improved, but an unbounded UPDATE without WHERE statement will still corrupt entire tables.

Scenario C: The Deedglass verified architecture (Grade A)

The team wraps their MCP database connector with Deedglass:

• Dedicated least-privilege role agent_reader holding only SELECT privileges for read tools.
• Write operations routed through deedglass mcp wrap --connector dev.
• Deterministic Common Expression Language (CEL) admission gate blocking DROP, TRUNCATE, and unbounded mutations.
• PostgreSQL logical replication slot monitoring the Write-Ahead Log to verify committed row diffs.
• Automatic atomic undo SQL generated for every committed transaction.

Calculation: 100 - 0 - 0 - 0 - 0 = 100 points (Grade A).

The agent can perform productive tasks, but its blast radius is mathematically constrained to near zero.

Remediating high-risk setups

Raising an agent security score from an F to an A does not require complex rewrites. It involves four systematic configuration steps:

Step 1: Create a dedicated database role

Never grant an agent superuser status. Create a dedicated role with least-privilege grants:

Code A database command in SQL. The text around it says what it does.

CREATE ROLE deedglass_agent WITH LOGIN PASSWORD 'secure_random_token';
GRANT CONNECT ON DATABASE app_production TO deedglass_agent;
GRANT USAGE ON SCHEMA public TO deedglass_agent;
GRANT SELECT, INSERT, UPDATE ON public.orders TO deedglass_agent;
REVOKE TRUNCATE, DELETE ON ALL TABLES IN SCHEMA public FROM deedglass_agent;

This immediately restores 35 points in the scan evaluation.

Step 2: Route tools through an admission gate

Wrap all MCP servers and database tools using the Deedglass wrapper:

Code Commands typed in a terminal. The text around it says what happens.

deedglass mcp wrap --connector prod_db -- npx -y @modelcontextprotocol/server-postgres "$DATABASE_URL"

Configure a CEL policy rule that halts destructive statements at the wire socket:

Code A settings file: the rules a tool reads before it acts.

policies:
  - id: database-safety-gate
    rules:
      - id: block-destructive-sql
        match:
          connector_type: postgres
        when: sql.kind in ["drop", "truncate"]
        decision: deny
        reason: Destructive database modifications are blocked for agents.

Step 3: Enable write-ahead log logical decoding

Enable logical decoding in postgresql.conf:

Code What the screen or file shows, copied as is.

wal_level = logical
max_replication_slots = 4

Initialize the Deedglass connector to create an isolated replication slot:

Code Commands typed in a terminal. The text around it says what happens.

deedglass connector postgres init --dsn "$DATABASE_URL"

Deedglass will now decode physical row diffs directly from the database change log, comparing the model’s reported results against physical reality.

Closing unverified write paths

To verify your organization’s agent security score, run the local scanner against your repository:

Code Commands typed in a terminal. The text around it says what happens.

npx deedglass scan --postgres-dsn-env DATABASE_URL

The scanner analyzes local configuration files, parses database role attributes in a read-only transaction, and outputs an itemized deduction register.

You can incorporate the scan directly into continuous integration workflows to enforce minimum standards:

Code Commands typed in a terminal. The text around it says what happens.

npx deedglass scan --fail-under B

If a pull request introduces an unrouted write path or grants excessive privileges to an agent role, the CI job exits 1 and blocks merging.

Perimeter security was designed for human operators who make mistakes occasionally. Autonomous agents operate at machine speed, generating hundreds of queries per minute. By calculating blast radius mathematically and enforcing deterministic storage-level gates, engineering teams can unlock autonomous productivity with mathematical safety.

Written with AI assistance and checked against our claims register.