AI agents in production: the guardrails that matter.

Give the agent one job

Agents fail in proportion to how much they are asked to do. Define one job with a clear start and end, such as triaging incoming tickets or preparing a deployment for review. A narrow agent is easier to test, easier to secure and easier to explain to an auditor.

Permissions

• The agent gets its own credentials, never a person's
• Read-only by default, with write access granted action by action
• Access limited to the systems the job needs and nothing else
• Secrets are injected at runtime and never placed in prompts

Human approval for what cannot be undone

Sort actions into reversible and irreversible. Reading, drafting and proposing can be automatic. Deleting data, sending messages to customers, changing production and spending money should wait for a person to approve, at least until the agent has a track record.

Logging and audit

Record every step: what the agent was asked, what it read, which tools it called with which arguments, and what came back. When something goes wrong, this is the only way to find out why. When something goes right, it is how you prove it to security and compliance.

Budgets and limits

• A maximum number of steps per task, so a confused agent stops
• A spending limit per task and per day
• Timeouts on every tool call
• Rate limits on the systems the agent can touch

Prompt injection

An agent reads content written by other people: emails, tickets, web pages, documents. Any of it can contain text that looks like an instruction. Treat everything the agent reads as data, keep its permissions narrow enough that a successful injection can do little harm, and require approval before actions that send data out.

Roll out in stages

• Shadow: the agent runs alongside people and its output is only compared
• Suggest: it proposes actions and a person carries them out
• Act with approval: it carries out actions after a person confirms
• Autonomous: it acts alone, for low-risk and well-tested tasks only