How do we stop an AI agent from taking an action it should not?

An agent that can only read is easy to approve. The moment it can write, someone has to answer for what it writes. Four controls, layered, cover almost every scenario.

Scope permissions at the service account

The first control is not in the agent at all. Give the agent its own service account in every connected system, with the narrowest possible scope. If the agent never needs to delete, it should not hold delete permission — do not rely on the prompt to prevent it.

Classify actions by reversibility

Sort every available action into three buckets. Reversible and low value — let it run. Reversible but visible to a customer — log it and notify. Irreversible or financial — require human approval before execution. This classification, not the model, is what your risk team will actually review.

Use allow-lists, not block-lists

The agent should be able to call only the tools you have explicitly registered. A block-list assumes you can enumerate every bad action in advance, and you cannot.

Log everything the agent reasoned about

Store the goal, the plan, each tool call with its inputs and outputs, and the final result. When something goes wrong, the question is always “why did it do that”, and without the intermediate steps you cannot answer it.

Test with adversarial inputs

Before go-live, run the agent against inputs designed to talk it out of its constraints — instructions embedded in documents it reads, contradictory requests, and edge cases in your own data. Guardrails that only hold against cooperative users are not guardrails.