Our view: an instruction to an AI is a request. A permission is a lock. We build with locks.

The idea in one example

Imagine a new employee. You can tell them "please do not delete customer records", or you can give them an account that has no delete button. If they misread a screen, or someone tricks them, only the second one still holds.

An AI can misread, can make things up, and can be steered by text it reads. So its limits should not live only in the prompt. They should live in the system around it, where the AI cannot talk its way past them.

What we keep outside the AI

• What it can see. The system can hide fields from the AI, for example while a person is typing a password.
• What it can change. Read-only is the default. Editing or deleting needs a separate permission.
• What leaves the building. Anything sent to a customer, or anything that moves money, waits for a person to approve it.
• How much it can spend or retry. Caps on cost and retries stop a loop from running away.
• Whose data it touches. Each user's data stays separate from every other user's.

Trust is earned, not assumed

We start with a person approving every action. We record how often the AI's proposal is accepted without changes. Only after a long clean record do we loosen one action at a time, never everything at once.

We have not fixed one number that fits every case. The threshold depends on the action and on how costly a mistake would be. Actions that involve money are the last to be loosened.

Why this matters

OWASP lists "excessive agency", meaning an AI given more access or autonomy than its task needs, among the main risks for AI applications in its 2025 list. Our earlier article on why agentic AI projects get scrapped covers the wider picture. This article is about one habit that helps.

Three questions to ask any vendor

• Where are the limits enforced: in the prompt, or in the system?
• Can I see a log of every action the AI took?
• What needs a person's approval today, and what has to happen before that changes?