You do not need a new system. An existing ISO/IEC 27001 ISMS can cover AI agents if you treat each agent as an asset, a non-human identity and a supplier dependency, add agent-specific threats such as prompt injection to the risk assessment, and bring agent briefs under configuration and change control. Then update the statement of applicability and audit it.
What does ISO/IEC 27001 require?
ISO/IEC 27001 specifies requirements for an information security management system. In substance, the organisation must define the scope of the ISMS, understand its context and interested parties, have leadership commitment and an information security policy, assess and treat information security risks, select controls and justify them in a statement of applicability, provide resources and competence, operate the controls, monitor and measure, carry out internal audits and management reviews, and correct and improve.
Its annex of controls is grouped into organisational, people, physical and technological themes. Relevant ones for agents include asset inventory, access control and identity management, supplier relationships and cloud services, secure development and configuration management, logging and monitoring, information transfer and data leakage prevention.
Who does it apply to?
Organisations that run an ISMS, whether certified or not. Many regulated firms and most agent platform vendors hold certification. Whether an existing certificate already covers agents is answered in does ISO/IEC 27001 cover AI agents: only if the scope and risk assessment include them.
What changes when the system is an agent that acts?
An agent is unusual in information security terms because it is three things at once.
It is an asset. It holds configuration, memory and logs that contain or reveal information. It belongs in the asset inventory with an owner and a classification.
It is an identity. It authenticates to systems, reads and writes data and calls tools. Unlike a service account running fixed code, its behaviour is driven by language. Access control must assume it may try to do things outside its purpose, whether because it misunderstood or because it was manipulated.
It is a supplier dependency. It depends on a platform and usually a model provider. Changes they make can alter the agent's behaviour without any change on your side.
Agents also bring threats an ISMS risk assessment written before them will not list: indirect prompt injection through documents, excessive permissions, leakage of sensitive data through outputs, and unannounced changes to the underlying model.
How do you extend the ISMS?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Scope | ISMS scope statement updated to include agents, the platform and data flows to model providers | Revised scope document |
| Risk assessment | Agent threats added: injection, excessive agency, output leakage, model change | Risk register entries per agent |
| Asset inventory | Each agent recorded with owner, classification, data it touches | Asset register |
| Identity and access | Unique identity per agent; permissions per capability; periodic review | Identity register; access reviews |
| Supplier relationships and cloud services | Platform and model provider assessed; security terms in contracts | Supplier assessments; contracts |
| Configuration and change management | Agent briefs, sources and permissions treated as configuration under change control | Change records |
| Secure development | Testing of agents before release, including adversarial inputs | Test reports |
| Logging and monitoring | Agent actions logged; unusual activity alerts | Logs; alert records |
| Data leakage prevention | Outbound destinations restricted; sensitive data masked where possible | Allow-lists; masking rules |
| Statement of applicability | Updated with agent-related control decisions | Revised statement |
| Internal audit and management review | Agents included in audit programme and review agenda | Audit reports; review minutes |
The configuration row is the one most often missed. In many organisations, agent instructions are edited in a vendor console by business users with no ticket and no approval. Under the ISMS those edits are configuration changes and must be controlled like any other. The same applies to the model version behind the agent: ask the platform to notify you before it changes, and retest the agent when it does.
Where does ISO/IEC 27001 stop and other standards begin?
ISO/IEC 27001 protects information. It does not ask whether an agent's decisions are fair, accurate for its task or explained to the people affected. That is the territory of an AI management system under ISO/IEC 42001, which shares the same high-level structure so the two can run as one integrated system. Our comparison of ISO/IEC 42001 vs ISO/IEC 27001 for AI agent platforms sets out the split. For risk analysis specific to AI, see how ISO/IEC 23894 applies to AI agents.
When assessing a vendor, you may see a 27001 certificate or a SOC 2 report, or both; ISO/IEC 27001 vs SOC 2 for AI agent platforms explains what each tells you.
What will a certification auditor ask?
- Are agents within the ISMS scope? Show us the scope statement.
- Where are agent-specific threats in your risk assessment?
- How are agent identities and permissions managed and reviewed?
- How are changes to agent instructions controlled?
- How do you assess the model provider as a supplier?
- Have agents been covered in internal audit?
What does ISO/IEC 27001 not cover?
It does not address the quality, fairness or explainability of agent decisions. It does not satisfy AI-specific laws on its own. It does not certify individual agents. A certificate covers the scope stated on it, so check that scope before relying on a vendor's certificate. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Do we need to recertify after adding agents?
Not usually. Expanding the ISMS to include agents is a change within the system, assessed at the next surveillance audit. A large scope change may need discussion with your certification body.
Should each agent have its own risk assessment?
Group agents with similar access and actions, but assess separately any agent with access to sensitive data or the ability to take hard-to-undo actions. Its risks will be specific.
Who owns an agent in the asset register?
The business owner of the process it supports, not IT. IT owns the platform; the business owns what the agent does and the information it handles.