Agent Data Modification Blast-Radius Containment
Define and enforce limits on the scope of data resources a single AI agent can modify, ensuring that an agent malfunction, misuse, or prompt injection cannot propagate data corruption beyond a bounded and recoverable scope.
Objective
Contain the potential damage from agentic AI failures or adversarial manipulation by limiting the volume, scope, and irreversibility of data modifications any single agent can make within a defined time window.
Maturity Levels
Initial
Agents have unrestricted write access to all data resources they connect to. No limits on modification volume, scope, or rate.
Developing
Some agents have been given read-only access to sensitive databases as an informal precaution, but there is no systematic blast-radius policy.
Defined
A blast-radius containment policy defines maximum modification scope for agent categories by risk level. Agents are granted write permissions scoped to specific tables, records, or data partitions rather than entire databases or services. Rate limits constrain modification volume per time window.
Managed
Blast-radius limits are enforced at the API or database layer, not only as application-level policy. Modification rate anomalies trigger automated alerts. Recovery procedures are documented and tested for each agent's maximum blast-radius scenario.
Optimizing
Blast-radius containment is integrated with the agent deployment readiness assessment (AGT-016). Limits are reviewed and updated when agent task scope changes. Automated rollback of bulk agent modifications is available within defined time windows.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Blast-radius containment policy defining modification scope limits by agent risk category.
- —Per-agent write permission documentation showing table/record-level scope, volume limits, and rate limits.
- —Evidence that limits are enforced at the API or database layer with automated alerting on breach.
- —Documented and tested recovery procedures for each agent's maximum blast-radius scenario.
Implementation Notes
Distinction from environment isolation
Agent environment isolation (AGT-008) addresses compute and network isolation: preventing agents from making outbound connections to unauthorized networks or from accessing services outside their declared environment. Blast-radius containment addresses a different risk: what happens to data when an agent with legitimate write access malfunctions or is manipulated. An agent can be in a properly isolated environment and still corrupt a significant dataset if modification scope is unrestricted.
Design principles
Scope minimization: Write permissions should be granted at the finest possible granularity. Prefer table-level or record-type-level write access over database-level or schema-level access. Use row-level security where available.
Volume limits: Define a maximum number of records or rows an agent can modify in a single operation and in a defined rolling window (e.g., 1 hour). Limits should be calibrated to the agent's expected operational volume with a reasonable buffer, not set arbitrarily high.
Rate limiting: Enforce rate limits at the API or middleware layer, not just in application code. Application-layer-only rate limits can be bypassed by prompt injection that causes the agent to execute raw API calls.
Reversibility preference: Where the agent's task permits, design data operations to be reversible. Prefer soft-deletes over hard-deletes. Write to staging tables and apply via a separate commit step. Maintain a modification log sufficient to reconstruct the pre-agent state.
Partition isolation: For agents operating on multi-tenant or multi-customer data, enforce strict partition isolation so that a malfunction affecting one customer's data cannot propagate to another's.
Recovery planning
For each agent, document:
- Maximum blast radius under a worst-case malfunction (what data, how much, in what timeframe).
- Recovery procedure: how to identify affected records, restore from backup or event log, and validate recovery completeness.
- Recovery time objective: how quickly can the blast radius be contained and data restored?
Recovery procedures should be tested in a staging environment, not only documented.
Example Implementation
Agent Data Modification Blast-Radius Policy (excerpt)
Agent risk categories and maximum modification scope:
| Risk category | Criteria | Max records/operation | Max records/hour | Write scope | Hard-delete permitted |
|---|---|---|---|---|---|
| Low | Read-mostly; writes to non-sensitive, fully reversible data | 500 | 5,000 | Table-level, non-PII | No — soft-delete only |
| Medium | Writes to operational data; reversible with log | 100 | 1,000 | Table-level, non-regulated | No |
| High | Writes to regulated data or financial records | 10 | 100 | Row-level, specific record types | No — staging commit required |
| Critical | Writes with external effect (payments, notifications) | 1 (per confirmation) | 50 | Endpoint-specific | Prohibited |
Example enforcement: Customer Refund Processing Agent (High risk)
- Write access: Payments API refund endpoint only (not reversal, not settlement).
- Max per operation: 1 refund (each action is a single-record operation by design).
- Rate limit: 50 operations/hour enforced at API gateway; alert at 40/hour.
- Staging: All refund requests written to refund-queue table first; batch commit by payments service every 5 minutes. Window for cancellation: 4 minutes after queue entry.
- Recovery: Payments team can reverse any agent-initiated refund within 24 hours. Reversal log retained for 90 days.