Partly. ISO/IEC 27001 covers an AI agent as an information system inside your management system's scope: its access, its data, its suppliers, its logs and its changes. It does not cover whether the agent behaves well: whether its answers are grounded, its decisions fair, or its actions within the job. That gap is what AI management standards address.
What does ISO/IEC 27001 actually cover?
ISO/IEC 27001 is the standard for an information security management system (ISMS). It asks an organisation to define a scope, assess risks to the confidentiality, integrity and availability of information, choose controls to treat those risks, and run the system with leadership, audits and improvement. Certification shows the management system works; it does not certify any single product.
For an agent inside your scope, the familiar controls apply: identity and access management, supplier security, logging and monitoring, change management, secure development, and incident management. An agent with credentials to your ledger is an identity with privileges, and your ISMS should treat it as one.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What does an agent add that 27001 was not written for?
Three things.
An identity that decides. Access control assumes a user or service account does what it is told. An agent chooses which of its permitted actions to take. Least privilege still matters, but it no longer bounds behaviour on its own, because an agent can misuse access it legitimately holds.
Integrity of reasoning, not just data. 27001 protects data from unauthorised change. It does not ask whether an agent drew the right conclusion from correct data, or was steered by an instruction hidden in an email it read.
Change without a change ticket. A model provider can update the model behind your agent, and the agent's behaviour shifts with no change to your code. Your change management needs to catch this.
How to stretch the ISMS to cover these is explained in ISO/IEC 27001 and AI agents: extending your ISMS.
What does 27001 handle, and what needs more?
| Agent risk | Covered by ISO/IEC 27001? | What closes the gap |
|---|---|---|
| Agent credentials stolen or over-privileged | Yes, access control | Per-capability permissions |
| Customer data leaks through the model provider | Yes, supplier security | Contract terms and data handling checks |
| Agent follows instructions planted in a document | Partly | Source provenance; untrusted content cannot authorise actions |
| Agent gives ungrounded or wrong answers | No | Testing against real cases |
| Agent acts beyond its job | Partly | Role scope and depth limits enforced at action |
| Agent behaviour drifts after a model update | Partly, via change management | Re-testing before reliance |
An illustrative example
Take a payments company with a mature, certified ISMS. It deploys an agent to resolve merchant disputes. The ISMS team registers the agent as an asset, gives it a service identity with access to the dispute system, puts the model provider through supplier review, and confirms logs go to the central log store. Every 27001 box is ticked.
Two months later, the agent starts issuing refunds on disputes where the merchant's evidence was strong, because a change to the dispute template confused it. No security control failed. The ISMS had no control for whether the agent's decisions were right. The company adds an AI risk assessment for each agent capability, re-tests the agent whenever its sources or templates change, and holds refunds above a limit for a person.
Which controls extend your ISMS for agents?
- Treat each agent as an identity with its own credentials, scoped per capability, reviewed like any privileged account.
- Classify agent inputs by provenance so content from outside the organisation is handled as untrusted.
- Include model providers and agent platforms in supplier security, with terms on data use and change notice.
- Log actions and reasons, not only access, so incidents can be reconstructed.
- Add AI risk assessment using guidance such as ISO/IEC 23894 applied to AI agents, or a full AI management system under ISO/IEC 42001.
The relationship between the two management system standards is set out in ISO/IEC 42001 vs ISO/IEC 27001 for AI agent platforms, and whether you need the newer one is answered in do you need ISO/IEC 42001 to deploy AI agents. For the full map, see AI agent regulation, mapped to controls.
Questions people ask
Can we bring agents into our existing 27001 scope?
Yes, and you should. Extending scope to include agents, their platform and their suppliers is usually simpler than running a separate security programme.
Is a vendor's 27001 certificate enough to trust its agent platform?
It tells you the vendor runs a working security management system. It does not tell you how agents on the platform behave or how they are bounded. Ask about both.
Does 27001 require testing agent outputs?
Not specifically. It requires testing of security in development and change. Testing whether an agent's decisions are right comes from AI risk management, not from 27001.