ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
AI agent security is mostly a privilege problem. A chatbot that gets something wrong produces bad text. An agent that gets something wrong, or is manipulated into it, sends the email, issues the refund, changes the record or runs the code. ISO/IEC 27090 gives this point some of its most detailed guidance: the agent’s permissions, not the model’s intelligence, decide how bad a failure can get.
This guide covers why agents change the risk, the least-privilege model ISO 27090 recommends, controls for the three common agent patterns, oversight that actually works, and a worked example.
A language model on its own only generates output. An agent wraps a model in a loop that can plan, call tools and act across systems on someone’s behalf. ISO 27090 identifies what that adds:
The standard also names two non-attack causes of unwanted behaviour that agents make worse: overreliance, where users trust the system too much, and excessive agency, where engineers give it more functionality, permissions or autonomy than it needs. The OWASP Top 10 for LLM Applications lists the second as LLM06:2025 Excessive Agency.
ISO 27090 clause 6.11.3.3 sets out least privilege for AI systems and agents as a run of specific recommendations. In our words:
| Principle | What it means in practice |
|---|---|
| Minimise autonomy | Decide which actions the agent may take without confirmation, starting from none |
| Fit privileges to context and pattern | An agent serving the public gets less than an internal one doing the same task |
| The agent holds the privilege, not the model | Each agent or service has its own identity; it never simply inherits its user’s full rights |
| Task-specific | Permissions defined per task type, not for the agent in general |
| Time-bound | Credentials issued per task or session and expire when it ends |
| Delegated within clear identity boundaries | Both the delegating user and the agent appear in every authorisation decision |
| Proportionate | Stronger checks for higher-impact operations |
On top of that, the standard asks for cryptographically verifiable agent identities, authorisation that adapts to context, robust audit trails, clear delegation controls, and graduated intervention that can cut privileges back when behaviour looks anomalous.
ISO 27090 distinguishes three implementation patterns, each needing a different control at the point of action.
The agent acts by calling defined APIs and tools. Route every call through a mediating gateway that checks it against the task’s allow-list and parameters before it executes. The gateway, not the model, is where policy lives.
The agent operates a user interface: clicking, typing, reading the screen. Run it in a restricted, disposable environment with an explicit allow-list of applications, sites and actions, and keep it away from the user’s stored credentials. Anything on screen can carry an injected instruction.
A system coordinating several models or agents. Isolate each component behind strong security boundaries, so a compromised sub-agent cannot command the others beyond its own scope, and so no component can grant itself or another wider permissions.
Least privilege limits the damage. Oversight catches what gets through. ISO 27090 describes two forms, chosen by risk:
Practical design points: show the overseer the evidence behind a proposed action, vary the interaction so approval is not habitual, track override rates (a rate near zero may mean rubber-stamping), and make sure there is a documented way to stop the agent and fall back to a manual process.
Take a customer-support agent that can look up orders and issue refunds.
| Decision | Weak design | Least-privilege design |
|---|---|---|
| Identity | Runs with the support team’s shared API key | Its own service identity, with a short-lived token per conversation |
| Data access | Can query any customer | Can read only the authenticated customer’s orders |
| Refunds | Any amount, any order | Up to a set limit, on that customer’s orders, within the refund policy window |
| Above the limit | Proceeds | Drafts the refund for a human to approve |
| Out-of-scope requests | Attempts them | Blocked at the gateway and logged |
| Anomalies | Not watched | Unusual refund volume steps permissions down and alerts the team |
Now imagine a customer pastes in a message containing a hidden instruction to refund every order on file. With the weak design that is a serious incident. With the least-privilege design the agent can, at worst, draft refunds within its limit on that one customer’s orders, and the anomaly check fires.
Every agent action should be logged with the agent identity, the delegating user, the task, the action, its parameters and the result. That trail is what lets you reconstruct an incident, review whether permissions are still needed, and evidence the controls. ISO 27090’s logging guidance also recommends capturing the model version and the input and output of each model call.
An agent that passes all ten is not immune to manipulation, but its worst case is bounded. That is the realistic goal of AI agent security today.
No. ISO 27090 recommends treating the agent as the privilege holder, with its own identity and a task-scoped subset of rights. Requests outside that subset are blocked whatever the user could do themselves.
No. It depends on the consequence. Trivial, reversible actions can rely on guardrails; significant or hard-to-reverse actions, or those affecting people’s rights, should need approval.
Prompt injection is one of the main ways an agent can be misused, and it cannot be reliably blocked. Least privilege decides what a successful injection achieves. See our guide to prompt injection prevention.
NIST’s AI 100-2e2025 covers the security of agents and attacks that compromise connected resources.
Good AI agent security leaves records: a standard that sets the rules, a register of every agent with its identity, tools, permissions, expiry and intervention thresholds, and logs that show the rules working. For the wider threat list, see the ISO 27090 overview; for how these controls sit in a management system, ISO 27090 vs ISO 42001.
Our ISO 27090 Toolkit includes an AI Agent Least Privilege Standard, an AI Agent Permission Register, a Human Oversight and Guardrails Procedure, and agent-specific detection use cases and test cases, organised on the clauses of ISO/IEC 27090.
October 29, 2026
October 28, 2026
October 28, 2026
October 27, 2026
October 27, 2026