An agent that takes actions rather than only producing text needs credentials, and the path of least resistance is to give it the same access as the person it is helping. That works immediately and it means an unexpected input can produce an action nobody intended, with full authority behind it.
AI agent access control is the difference between a bounded tool and an unbounded one, and it is mostly ordinary security practice applied to a new kind of caller.
Instructions in a prompt are not a control
Telling a model never to delete records is guidance rather than enforcement. It usually holds and it will not hold under an unusual input, a confusing instruction embedded in retrieved content, or a deliberate attempt to redirect it.
The control has to sit outside the model, in the permissions attached to the credentials it uses. If the agent technically cannot perform an action, no phrasing makes it possible, and that is the only guarantee available.
Give it its own identity
Agents should authenticate as themselves rather than borrowing a person’s account. A separate service identity makes the audit trail meaningful, lets permissions be scoped to the task, and means revoking access does not disrupt a human user.
- One identity per agent, not one shared across several.
- Permissions scoped to the specific operations the task requires, read-only wherever possible.
- Credentials held in a secrets manager and rotated, never embedded in a prompt or a repository.
- Separate credentials per environment, so a test agent cannot reach production.
Read-only by default is the highest-value rule here. A large proportion of agent tasks are retrieval and summarisation, and those need no write access at all.
Ask what the worst thing this agent could do with the credentials it holds. If the answer is uncomfortable, the credentials are wrong rather than the prompt.
Sam Ortiz, Director of Engineering, Engineered With AI
Decide which actions always need a person
Some actions warrant confirmation regardless of confidence: sending external communications, moving money, deleting anything, changing permissions, publishing publicly, or anything affecting a customer record irreversibly.
The approval should carry enough context to be a real decision. A prompt asking whether to proceed, with no detail about what will happen, produces reflexive approval and provides an audit trail rather than a control.
Rate limits catch the runaway case
A loop that sends one email is a bug. The same loop unbounded sends four thousand. Caps on actions per run and per hour, with an alert when one is hit, turn a potential incident into a stopped job and a notification.
Treat retrieved content as untrusted
Where an agent reads web pages, documents or emails, that content can contain text written to influence it. An instruction embedded in a document is data the agent happens to be reading, and it should never be able to grant capability.
This is why permission boundaries matter more than instruction quality. The defence is that the agent cannot perform the action being requested, rather than that it was told to ignore such requests.
Log actions separately from conversation
The record of what an agent did, as distinct from what it said, is what you will need during an investigation. Every action, with the identity used, the parameters, the result, and the run that triggered it.
Keep it queryable and keep it longer than the conversation logs. The question asked after an incident is invariably what changed and when, and reconstructing that from prose transcripts is painful.
Review the permissions periodically
Agent scope grows. A new capability gets added, a permission gets widened to unblock something, and nobody narrows it afterwards. Within a year the read-only assistant has write access to three systems.
Review what each agent can reach on a schedule, the same way you would for staff, and remove anything that is no longer required. This connects directly to keeping agents reliable in production, because most reliability incidents and most security ones share a root cause.
Agent running with broad access?
We will scope its permissions properly and put approval gates on the actions that need them.
