AI Agent Guardrails: Limit What Agents Can Do

AI agents can do more than answer questions. Given tools, they can search records, update data, send messages and trigger workflows, choosing their own steps along the way. That flexibility is what makes them useful, and it is also what makes them risky. An agent that misreads an instruction, follows text planted in a document or loops through expensive calls can cause real damage before anyone notices. AI agent guardrails are the controls that limit what an agent can access and do, check what goes in and comes out, require approval for risky actions and record everything for review. This guide explains the main types of guardrail, how to apply them in business settings and how to test that they work.

Why agents need guardrails

Agents differ from simple AI features in a few important ways:

• They take actions, not just produce text
• They decide which tools to use and in what order
• They may run several steps without a person checking each one
• They often read content from outside sources, such as emails, documents and web pages

Anthropic's guidance on building agents notes that their autonomous nature means higher costs and the potential for compounding errors, and recommends extensive testing in sandboxed environments along with appropriate guardrails (Anthropic: Building effective agents).

Understand prompt injection

A particular risk for agents is prompt injection: input that changes the model's behaviour in unintended ways. The OWASP Gen AI Security Project lists prompt injection as a top risk for language model applications and describes indirect prompt injection, where the model accepts input from external sources such as websites or files that contain instructions (OWASP LLM01: Prompt Injection).

For an agent with tools, a hidden instruction in an email or web page could try to make it export data or send messages. Guardrails are designed so that, even if the model is misled, the damage it can do is limited.

Limit tools and data

The most effective guardrail is limiting what the agent can reach. OWASP's mitigations for prompt injection include enforcing privilege control and least-privilege access, giving the application its own API tokens and handling functions in code rather than giving them directly to the model. In practice:

• Give each agent only the tools it needs for its task
• Prefer read-only tools; add write tools only when necessary
• Scope data access to the records relevant to the task
• Use dedicated service accounts with restricted permissions
• Keep sensitive operations, such as payments or bulk exports, out of the agent's reach entirely

Require approval for risky actions

Some actions should never happen without a person agreeing. OWASP's guidance also recommends requiring human approval for high-risk actions. Typical candidates include:

• Sending messages to customers or external parties
• Changing financial values, such as prices or discounts
• Deleting or bulk-updating records
• Granting access or changing permissions

The agent can prepare the action and explain its reasoning; a person reviews and approves. This keeps the speed benefit while keeping accountability with people.

Check inputs and outputs

Validate what goes into the agent and what comes out:

• Mark external content clearly as untrusted data, separate from instructions, as OWASP recommends when it advises segregating and identifying external content
• Strip or flag suspicious content where practical
• Require structured outputs for actions, such as specific fields and allowed values
• Check proposed actions against rules before executing them, such as allowed recipients or value ranges
• Block outputs that include sensitive data the task does not need

Set limits on steps, time and cost

Agents can loop or wander. Set hard limits:

• Maximum number of steps or tool calls per task
• Maximum run time
• Budget limits on model usage
• Rate limits on actions, such as messages sent per hour

When a limit is reached, the agent should stop and hand the task to a person with a summary of what it did.

Worked example: AI agent guardrails for a sales assistant

The table below shows hypothetical guardrails for an agent that prepares follow-ups after sales calls. Tools and limits are illustrative.

AreaGuardrailWhyToolsRead call notes and CRM records for the rep's own accounts; draft emails; create tasksOnly what the job needsData scopeOnly accounts owned by the requesting repLimits exposure if misledWrite actionsCreate tasks automatically; emails saved as drafts onlyTasks are low risk; emails reach customersApprovalRep must review and send each emailKeeps people accountable for customer contactInput handlingEmail and document content marked as untrusted dataReduces effect of planted instructionsOutput checksRecipients must be existing contacts on the accountPrevents sending to unknown addressesLimitsMaximum 15 tool calls and 2 minutes per taskStops loops and runaway costLoggingEvery tool call, input and output recordedSupports review and investigation

The agent saves reps time on notes and drafts, while the riskiest action, contacting customers, stays with a person.

Log everything

Record every agent run: the request, each tool call with its inputs and outputs, the final result and any approvals. Logs let you investigate problems, spot misuse and improve the agent over time. Protect logs appropriately, since they may contain sensitive data.

Test the guardrails

Do not assume guardrails work; test them:

• Run the agent on realistic tasks and check results
• Try inputs designed to mislead it, such as documents containing instructions
• Attempt actions outside its permissions and confirm they are blocked
• Check that limits stop long or looping runs
• Repeat tests whenever prompts, tools or models change

Test in a sandbox or with test data before connecting to live systems. OWASP also recommends regular adversarial testing that treats the model as an untrusted user.

Monitor in production

Track run counts, failures, blocked actions, approval rates, corrections and costs. A spike in blocked actions or unusual tool use may indicate an attack or a problem with instructions. Review a sample of runs regularly.

Start narrow

Begin with agents that have narrow tasks and limited tools, prove their value and safety, then expand carefully. Our guide to multi-agent workflows explains when splitting work across agents helps and when a simpler design is better, and our guide to AI agents for IT support shows guardrails applied in a support setting.

Frequently Asked Questions

What are AI agent guardrails?

They are controls that limit what an AI agent can access and do, check its inputs and outputs, require approval for risky actions, cap steps and cost, and log its activity.

What is prompt injection?

It is input that changes a language model's behaviour in unintended ways, including instructions hidden in external content such as emails, documents or web pages.

Which agent actions need human approval?

Actions with external, financial or hard-to-reverse effects, such as messaging customers, changing prices, deleting records or granting access.

How do you test AI agent guardrails?

Run realistic tasks, try misleading inputs, attempt actions outside permissions, check limits and repeat tests whenever prompts, tools or models change.

Put AI agents to work safely

We design and build AI agents with scoped tools, approvals, input and output checks, limits and full logging. See our AI agent orchestration and RAG service, or talk to us about AI agent guardrails.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.