Step 1: Inventory what the agent can actually touch
Before you control an agent, list every system and action it can reach: which databases, which APIs, which write operations, which external calls, which tools it can invoke. Agents fail differently from a chatbot because they act, and an action against a production system is where the real risk lives. A model that gives a wrong answer is a quality problem. An agent that takes a wrong action is an incident. The inventory almost always turns up capabilities no one deliberately granted, because agents inherit the permissions of the credentials they run under. The output of this step is a plain list of every capability the agent has, whether or not you intended to grant it.
Step 2: Set least access, then defend it
Give the agent the least access that still ships the outcome, and treat every added permission as a decision someone has to justify. Read access is not the same as write access, and write access to a sandbox is not the same as write access to production. Scope the capability, not just the identity: what the agent is allowed to do matters more than what role it was assigned, because a broad role quietly grants a hundred actions the use case never needed. Start from zero and add only what the workflow requires, rather than starting from an admin credential and hoping to narrow it later. Later rarely comes. The output is a permission set you can explain line by line to someone who will ask why each one exists.
Step 3: Put a checkpoint on high-impact actions
Not every action deserves the same trust. Moving money, deleting records, sending external messages, changing a customer's state, or committing a transaction are actions where a human checkpoint earns its cost. Decide which actions the agent can take on its own and which require a person in the loop, and enforce that split at the point the action is taken, not in a policy document no one reads. The test is one question: if this action went wrong a thousand times before anyone noticed, how bad would it be? Where the answer is bad, put a human between the intent and the effect. Where it is trivial, let the agent run. Getting this split right is most of what separates an agent you can sleep through from one you have to watch.
Step 4: Log every action as it happens
An agent you cannot audit is an agent you cannot run in a regulated business. Record every action the agent took, what it was asked, and what it returned, at the moment it happened. Reconstructing that after an incident does not work, because the context is already gone. Under ISO/IEC 42001:2023 and the EU AI Act (Regulation (EU) 2024/1689), the record is part of what you are expected to produce, not a nice-to-have. The log has to be tamper-evident and readable by someone who was not in the room, because the point of an audit trail is to answer questions from people who were not there. The output is a record that answers 'what did it do and why' without guesswork.
Step 5: Review the access on a schedule
Access that made sense at launch drifts. New tools get wired in, permissions get widened for a one-off and never narrowed, and an agent that started with three capabilities ends the quarter with fifteen. Put a standing review on the calendar where the owner walks the agent's current capabilities against the ones it needs and cuts the difference. Tie the review to the audit log, so you can see which permissions the agent actually used and which have sat unused and dangerous. Access control is a discipline you keep, not a setting you configure once. The output is a recurring check that keeps least access true over time instead of only on day one.
A worked example: an agent that pays invoices
Put the steps against a concrete case. An agent that pays approved invoices is exactly the kind of high-stakes actor that access control exists for. Step one, inventory: it can read the invoice queue, look up vendor records, and issue payments, and it turns out the credential it runs under can also create new vendors, which no one intended. Step two, least access: revoke vendor creation immediately, because the payment workflow never needs it, and scope read access to the specific queue rather than the whole finance system. Step three, checkpoint: payments above a set threshold, or to any vendor the agent has not paid before, require a human approval before they execute, while small repeat payments to known vendors run on their own. Step four, logging: every lookup, every approval request, and every payment is recorded as it happens, with the invoice it relates to, so finance can reconcile and an auditor can trace. Step five, review: monthly, the owner checks which permissions the agent actually used and removes the ones sitting idle. The result is an agent that does the boring high-volume work unattended and pulls a human in exactly where a mistake would hurt.