---
title: "Before an AI agent can act safely"
description: "Giving a model a tool is easy. Deciding what it may touch, when it must stop, and how someone can undo the result is the real work."
canonical: "https://innovate-blog.com/articles/what-ai-agent-needs-before-it-can-act"
last-updated: "2026-09-20"
---

# Before an AI agent can act safely

> Giving a model a tool is easy. Deciding what it may touch, when it must stop, and how someone can undo the result is the real work.

By Moez Zhioua. Published 2026-08-22. Updated 2026-09-20. Category: AI at work. Estimated reading time: 9 minutes.

## In brief

- Give the agent only the tools and data required for one job.
- Enforce permissions in the system instead of relying on instructions in a prompt.
- Before launch, make sure someone can stop it, inspect its actions, and undo the worst allowed result.

## Wrong answers are cheap. Wrong actions are not.

The risk changes when a model moves from drafting text to sending a message, changing a record, approving a refund, or deleting a file. It is now part of an operating process, with consequences outside the chat window.

No prompt will cover every misunderstanding, malicious instruction, or bad tool choice. Safer systems limit what can happen when the model gets something wrong.

## 1. Give it one job

Write the job like a small contract: accepted inputs, permitted tools, expected output, time limit, and reasons to hand the work to a person. Phrases such as handle anything or use whatever you need are warning signs.

OWASP describes excessive agency as too much functionality, permission, or autonomy. Reduce all three. An agent that reads approved documents does not also need a general browser, database write access, and publishing rights.

## 2. Enforce permissions outside the prompt

Telling a model not to delete records is not access control. The API should refuse because the agent's credential has no delete permission.

Use separate credentials for separate jobs. Start with read-only scopes, restrict data to the current user or account, and check authorisation again when the tool is called.

## 3. Match approval to consequence

A confirmation screen before every read makes a tool exhausting. Low-consequence work, such as reading a public page or classifying a ticket, can run with less interruption. External messages, money, publishing, permission changes, and deletion need approval or a staged state.

Show the reviewer the proposed action, the target, the source evidence that matters, and the likely effect. Approving a vague summary gives someone accountability without enough information to exercise it.

## 4. Split observation from execution

Use three steps. Gather evidence first. Produce a proposed action and reasons second. Finally, pass the proposal to a controlled executor that checks the rules before doing anything.

Those seams create places to inspect and test the system. The reasoning step can use realistic data while the executor stays disabled.

## 5. Keep a record and a way back

Log who requested the work, which evidence was used, the model and policy version, the proposed action, any approval, the tool call, its response, and the resulting state. The agent that acts should not be able to rewrite that record.

Prefer actions that can be undone. Draft before sending, archive before deleting, and stage before publishing. Limit the number and value of actions within a time window. The stop control must work without asking the model for permission.

## Before the first live account

Test ambiguous requests, conflicting sources, hostile instructions hidden in a document, a missing tool, partial success, and a user trying to reach data outside their scope.

- Can the agent reach a tool this job does not require?
- Can it see data outside the requesting user's scope?
- Can a high-impact action happen without informed approval?
- Can the executor reject a proposal without asking the model?
- Can an operator stop the system and reconstruct the sequence?
- Can the business undo the maximum action allowed in one hour?

## Autonomy needs a boundary

Useful autonomy removes needless handoffs inside a safe area. It does not remove the edge of that area.

NIST recommends ongoing governance, mapping, measurement, and management throughout an AI system's life. After launch, review near misses, rejected approvals, manual corrections, and requests for broader permissions. They will tell you when the original boundary needs another look.

A mature system does not remove people for the sake of it. It uses their judgement where uncertainty and consequence make it worthwhile.

## Sources and further reading

- [LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), OWASP GenAI Security Project
- [AI Risk Management Framework 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10), National Institute of Standards and Technology

Canonical URL: https://innovate-blog.com/articles/what-ai-agent-needs-before-it-can-act