Guardrails That Keep AI Agents Safe in Mumbai — And What To Do About It
The specific guardrails every AI agent deployment needs to prevent runaway costs, production errors, and autonomous actions that should have required human approval.
As the founder of Perceptra, a Mumbai digital growth studio, I work with real businesses on these challenges every week. This guide is written for owners and decision-makers, not engineers.
Why guardrails are the most important engineering work in any agent deployment
The essential guardrails, each explained
Spending cap on the LLM API account. Set a hard cap — a maximum monthly spend above which the API provider cuts off access — before deploying any agent. This is the single most important financial control and takes two minutes to configure.
Action limit per run. Every agent should have a maximum number of actions (tool calls, API calls, internal steps) it can take in a single run. Typical range: 20–50 for an SMB task. If the agent reaches this limit, it should halt and report back to a human, not attempt to find another path forward.
Timeout on every external call. Every call to an external API, web search, or database should have a maximum wait time, after which the call is treated as failed. This prevents the agent from hanging indefinitely on a slow or unresponsive service.
Read-before-write permission structure. During any pilot period, and for most tasks permanently, the agent should have read access to the systems it needs to monitor or gather information from, but write access only for clearly defined, specifically-scoped fields — not broad write permissions to live production systems.
Human-in-the-loop gates for irreversible actions. Anything the agent intends to do that cannot easily be undone — sending a customer communication, deleting a record, making an external commitment — should require explicit human approval before proceeding.
Comprehensive logging of every action. Every action the agent takes should be recorded in a retrievable log: what tool was called, with what parameters, at what time, and what the result was. This is essential for debugging errors and for organisational accountability.
Monitoring and alerting on abnormal patterns. Configure alerts for unusual agent behaviour — significantly higher than normal token consumption per run, a high rate of tool call failures, runs taking significantly longer than normal — that surface to a human before a problem escalates.
The guardrail most commonly omitted in early deployments
The action limit. Spending caps are increasingly standard; timeouts are widely understood. The per-run action limit is the one that gets skipped most often, because it seems like it would "limit the agent's capability." In practice, a well-scoped agent should never approach this limit in normal operation — the limit's purpose is stopping abnormal behaviour, not constraining normal task execution.
Frequently asked questions
Some frameworks include certain guardrails as configurable features, but none currently provide all of these out of the box without explicit configuration — always verify which specific controls are configured and tested, not assumed.
Intentionally trigger each guardrail in a test environment — simulate a stuck agent loop to verify the action limit fires, simulate a slow API response to verify the timeout fires, simulate a spend event to verify the alert triggers. Do not assume guardrails work just because they are configured; test them.
Gradually and cautiously, after demonstrated reliable performance over a sustained period — not proactively, in advance of evidence that tighter controls are limiting genuine value. The guardrails are cheap to maintain; the events they prevent are expensive.
Ready to Build
This For Your Business?
Book a strategy session. We scope your first project in 30 minutes, no jargon, no obligation.