A chat assistant produces text that a person reads. An AI agent does something. It calls an API, edits a ticket, queries a database, or opens a pull request, using credentials you gave it, based on what a model decided.
That changes the risk question. With an assistant, you worry about what it says. With an agent, you worry about what it can do. The answer is set by its permissions, not by its instructions, because instructions can be overridden by whatever text the agent reads.
This article treats an agent as what it is from an access control point of view: a non-human identity, often privileged, whose behavior can be influenced by untrusted input. The controls that follow are familiar. The discipline is in applying them to something that feels like a feature rather than a user.
Give every agent its own identity
The most common shortcut is the most damaging. An engineer connects an agent using their own token, or a shared service account that already exists. Now the agent has every permission that person or account has, and the logs cannot tell you which actions were the agent's.
Instead:
One identity per agent, per purpose. An agent that triages support tickets and an agent that drafts release notes get separate identities, even if the same team runs both.
A named human owner. Someone accountable for what the agent is allowed to do, who approves changes to its permissions.
An inventory entry. The agent belongs in your AI system inventory, with the systems it can reach and the data it can see.
Separate identities make every later control possible. You cannot scope, review, or revoke something you cannot tell apart from a person.
Scope by task, not by convenience
Least privilege is not new. Agents make it harder to apply, because the person setting one up wants it to be useful, and broader access always looks more useful.
Start from the task and work outward:
List the actions the task requires. Not the actions the agent might find helpful. The actions the task cannot be done without.
Separate read from write. Many agent tasks need broad read access and narrow write access. Grant them separately.
Scope to resources. One project, one repository, one queue, one table. Not the whole tenant.
Limit the tools. If the agent reaches systems through a tool layer, such as a set of Model Context Protocol tools, expose only the tools the task needs. A tool that is not offered cannot be misused.
Prefer short-lived credentials. Tokens that expire limit the damage from a leaked credential and force a periodic decision about whether access is still needed.
The same principles appear in managing privileged access. An agent with write access to production is a privileged identity, and it deserves the same treatment as a person with that access.
Treat every input as untrusted
An agent reads things: emails, tickets, web pages, documents, code comments. Any of that text can contain instructions, and current models do not reliably tell your instructions apart from a stranger's. This is prompt injection, and there is no complete defense against it today.
The practical consequence is that the agent's permissions are its blast radius. Assume that anything the agent can do, a sufficiently clever input could make it do. Then ask whether you are comfortable with that.
Some patterns that follow:
An agent that reads content from outside your organization should not hold write access to sensitive systems without an approval step in between.
An agent that can read confidential data should not also be able to send data to arbitrary external destinations.
Keep the agent that gathers information separate from the agent that acts on it, where the task allows.
Put approval gates on consequential actions
Not every action needs a human. Requiring approval for everything trains approvers to click without reading. Classify the actions instead.
| Action class | Examples | Approval |
|---|---|---|
| Read | Query a record, read a document, list resources | None, within scope |
| Reversible write | Draft a document, add a comment, open a ticket | None, or sampled review |
| Consequential write | Change a configuration, merge code, modify a policy, change access | Named human approves each action |
| External or irreversible | Send to a customer, delete data, make a payment, publish | Named human approves each action, with the exact content shown |
The approval step only works if the approver sees exactly what will happen: the target, the change, and the content. "Agent wants to update the policy" is not enough to approve. A diff is.
Record every approval: who approved, what they saw, when, and the outcome. That record is the evidence that a human remained accountable.
Log what the agent did, and why
When something goes wrong, you need to reconstruct the sequence. For each action, the trail should show:
The agent identity, and the human or event that started the task
The tool or API called, with its parameters
The result, including errors
Any approval, with the approver's identity
A timestamp from a trusted source
Send these logs to the same place as your other security logs, as described in centralized logging for compliance, and protect them from modification by the agent itself. An agent that can edit its own audit trail does not have one.
Review agent access like any other access
Agents accumulate permissions the way people do. A scope added for one experiment stays. Include agent identities in your periodic access reviews, with the owner as reviewer. The approach in access reviews that hold up applies directly: export the population, record the decision, remediate, and confirm.
Two additions specific to agents:
A kill switch. The owner, and security, must be able to disable the agent immediately, by revoking its credentials. Test that this works.
Permission changes as change management. Widening an agent's scope goes through the same change process as any other access change, with a recorded approval.
A hypothetical, scoped end to end
Say a 40-person SaaS company wants an agent that triages incoming support tickets: it reads each ticket, looks up the customer's plan, suggests a priority, and drafts a first reply.
Scoped by task, that agent gets its own identity, owned by the support lead. It has read access to the ticket queue and to the plan field in the billing system, not to payment details. It can add internal notes and set a suggested priority, both reversible. It cannot send a reply. A support engineer reviews the draft and sends it under their own name.
The tickets come from outside the company, so the agent's input is untrusted. That is why it holds no write access to anything a hostile ticket could abuse, and why the one external action, the reply, needs a person. Every lookup, note, and priority change is logged under the agent's identity. When the next access review runs, its permissions are on the list.
How this maps to frameworks
No new framework is needed to govern agents. Existing controls cover them once agents are treated as identities.
ISO/IEC 27001:2022 Annex A 5.15 to 5.18 (access control, identity management, authentication information, access rights), 8.2 (privileged access rights), and 8.15 (logging).
SOC 2 common criteria CC6, on logical and physical access.
ISO/IEC 42001 Annex A controls on AI system operation and monitoring, event logs, and responsible use. The framework page summarizes them.
How TrustLynce helps
TrustLynce provides MCP tools for AI agents with human approval on actions and an audit trail of every call, so an agent works within a defined set of tools and every consequential change has a named approver on record.