How to Build the Infrastructure That Makes AI Agents Safe to Deploy

If you haven’t read why this matters, the short version: a startup lost its entire production database and every backup in nine seconds last month. An AI coding agent did it. The agent wasn’t the problem. The architecture was. This post is about how to fix the architecture.

The five controls below are not exotic. Most engineering teams have implemented versions of them for human actors already. The gap is almost always in applying them consistently to non-human actors: agents, scripts, CI jobs, and automated pipelines. Closing that gap is mostly engineering, not policy.

1. Scoped credentials, per agent and per task

The startup that lost its database had a single API key with delete permissions on both production and backups. That is the root cause, full stop. Everything else is downstream of that decision.

The fix is least privilege applied seriously, not just in principle. In practice:

• No long-lived, broadly privileged keys held by any agent
• Each agent run obtains a credential scoped to the exact set of operations and resources that the specific task requires
• Credentials expire after the task completes
• No credential should be able to touch both primary data and its backups

Most teams know this principle. Few apply it to agent runs because agents “feel like internal tooling.” They are not. Treat every agent credential as if it were issued to an external contractor with no loyalty to the organisation.

2. Separate trust boundaries for backups

A backup that can be deleted by the same credential that deleted the original is not a backup. It is a copy in the same blast radius.

Real backup separation means:

• Different account or environment from production
• Different credentials, with no overlap with production-side access
• A deletion policy that cannot be overridden by any production actor, human or agent
• Ideally, a write-once or object-lock mechanism that enforces immutability at the storage level

This is the control that turns a nine-second total loss into a nine-second incident with a clean recovery. It is also the control most commonly missing in companies that consider themselves well-architected.

3. Mandatory approval gates on destructive operations

An AI agent should be able to propose, prepare, and surface a destructive operation. It should not be able to complete one.

Any operation the platform classifies as irreversible (drops, truncations, bulk deletes, or backup removals) should require an out-of-band approval that cannot be satisfied by the same agent or session that requested it. This is the explicit, engineered replacement for the human hesitation that used to catch these mistakes informally.

Implementation considerations:

• The approval request should include the full operation, the scope of impact, and the agent’s stated justification
• The approver should be a human, not another automated system
• The approval should be logged with the same permanence as the operation itself
• Timeouts on pending approvals should default to rejection, not execution

4. Immutable, append-only audit logs

Every privileged action, by every actor, is written to a log that the actor itself cannot modify or delete.

This serves two purposes worth separating. The first is forensic: when something goes wrong, you need to reconstruct exactly what happened and in what order. The second is preventive: an audit log that is itself treated as a protected resource forces discipline on the rest of the architecture. If every action is permanently recorded, the incentive to scope credentials correctly and gate destructive operations properly becomes concrete rather than theoretical.

Practically:

• Audit logs should live in a separate environment from the systems they record
• Write access to the log should be append-only, with no delete or overwrite permissions granted to any production actor
• The logs themselves should have their own retention policy and access controls
• Treat the audit log as personal data if it contains user-identifiable actions, because it does

5. Blast radius limits per credential

The four controls above are structural. This one is a backstop for when the structure is imperfect, which it always is.

For each credential, define a maximum amount of damage it is permitted to cause in a single time window, enforced at the platform level:

• Per-key rate limits on destructive operations
• Per-table or per-resource change caps within a single session
• Spend ceilings for credentials with cost implications
• Automatic suspension when a credential’s activity pattern deviates significantly from its baseline

These are blunt instruments. They are exactly what catches a runaway agent before the structural controls have a chance to react. Think of them as the circuit breaker in an electrical system: crude, reliable, and worth having even when everything else is working correctly.

The order of implementation

If you are starting from a position where none of these controls is in place, the order matters:

1. Separate backup trust boundaries first. This is the control that turns a catastrophic loss into a recoverable incident.
2. Scoped credentials second. This limits the blast radius of any single compromised or misbehaving actor.
3. Approval gates on destructive operations third. This replaces the informal human safety net with an explicit engineered one.
4. Immutable audit logs fourth. This gives you the forensic foundation to identify and close gaps in the first three.
5. Blast radius limits last. Once the structural controls are in place, this is the final layer of defence.

Where Ozymind comes in

When we deploy agentic AI for clients, these five controls are non-negotiable before any agent touches production. Not as a checklist, but as a working architecture we build, test, and hand over. The engagements where this foundation is already close to correct move fast. The ones where it isn’t, we fix it first, because every shortcut here shows up later as an incident.