An AI agent that acts on your systems, directly or through an MCP server, is an identity in ISO 27001 terms, and the Annex A controls that govern people and service accounts govern it. A.5.16 to A.5.18 cover its identity, its authentication information and its access rights: provisioned, scoped to the task, reviewed and removed. A.8.2 to A.8.5 limit privileged and restricted access and require secure authentication. A.8.15 and A.8.16 require its actions to be logged against that identity and monitored, and A.8.32 keeps a person approving the changes it makes to production. In practice that means one revocable credential per agent connection, the narrowest scopes the task needs, write operations that re-check authorisation when they run, and agent connections included in the access review.
The Model Context Protocol and similar interfaces let an AI agent call tools on your systems: read records, file tickets, change configuration, open pull requests. ISO 27001 has no clause about agents and does not need one, because its access, logging and change controls are written for any identity that can act. This article maps the controls onto agents and MCP servers and ends with how Noru's own MCP server applies them.
An agent is an identity
Annex A does not distinguish people from service accounts from agents. A.5.16 asks for the full life cycle of every identity to be managed; A.5.17 for the authentication information behind it to be protected; A.5.18 for access rights to be provisioned, reviewed and removed according to the access control policy in A.5.15. An agent connection that holds a credential is such an identity, and the questions are the usual ones: who owns it, what can it reach, who approved that, when was it last reviewed, and how is it removed.
The controls, applied to agents
| Annex A control | What it means for an AI agent |
|---|---|
| A.5.15 Access control | The policy names agents as a category of identity and says how their access is decided |
| A.5.16 Identity management | One identity per agent connection, with a named human owner; no shared agent accounts |
| A.5.17 Authentication information | Short-lived tokens, rotated and revocable, never pasted into prompts or shared between agents |
| A.5.18 Access rights | Scopes limited to the task, granted by someone entitled to grant them, reviewed with user access, removed when the use case ends |
| A.8.2 Privileged access rights | No standing administrative scopes for agents; privileged actions need a separate, time-limited grant |
| A.8.3 Information access restriction | The agent sees only the organisation's and the role's data; tenant boundaries hold inside the tool |
| A.8.4 Access to source code | Agent commits are proposals; merge rights stay with people |
| A.8.5 Secure authentication | OAuth with PKCE or an equivalent, with the human who authorised the connection protected by MFA |
| A.8.15 Logging | Every tool call, or at minimum every write, logged with the agent's identity, the tool, the arguments that matter and the time |
| A.8.16 Monitoring activities | Volume, failures and unusual tools per agent identity watched like any account |
| A.8.32 Change management | Changes an agent makes to production go through review and approval by a person |
| A.5.19 and A.5.23 | The agent platform and model provider are suppliers and cloud services, with the terms and assessment that implies |
MCP servers: scopes and run-time checks
An MCP server exposes tools, and the credential's scopes decide which tools the agent can call. Three design choices decide whether A.5.18 and A.8.2 hold. The tool list offered to the agent should reflect its scopes, so a read-only credential never sees a write tool. Each write should re-check authorisation when it runs, because a tool list fetched at connection time can outlive a demotion or a removal. And separate use cases should hold separate credentials, so a reporting agent's scopes cannot be borrowed by one that changes records. Review agent connections alongside user access reviews, and remove the ones nobody uses.
Logs the auditor can read
A.8.15 asks for logs of activities, exceptions and events, protected and reviewed. For agents the test is simple: pick a write the agent made and show the log entry with the agent's identity, the human who authorised the connection, the tool and the time. Agent actions should land in the same logs as human actions so one review covers both, and the logs should distinguish the agent from its owner. The evidence list covers what the auditor samples for A.8.15 and A.8.16.
Agents that write code
A coding agent with repository access touches A.8.4 and the secure development controls A.8.25 to A.8.32 at once. The pattern that satisfies them is the one already used for junior engineers: the agent works on a branch, its changes are proposals, a person reviews and approves them, tests run before merge, and development, test and production stay separated under A.8.31. Give the agent no deploy rights, and log its commits under its own identity rather than its owner's.
What auditors ask
- Which agents and MCP connections exist, who owns each, and where is the inventory?
- How were their scopes decided, and when were they last reviewed?
- Show the log of a write an agent made, and the approval of a change it proposed.
- What happens to an agent's access when its owner leaves or changes role?
- Is the agent platform in the supplier register, and what does its agreement say about your data?
How Noru's MCP server is built
Noru runs an MCP server for its own customers, and its public documentation describes the same controls. Each OAuth connection is tied to one user, one organisation and that user's role; scopes group the tools, and a viewer can only grant read scopes. Tools outside a credential's scopes are not listed, and write tools re-check the scope when they run. A user demoted to viewer loses write tools on the next call, and removing a member breaks the connection's refresh. Writes through MCP land in the same logs as a click in the app. The MCP server documentation and the security model describe it in full, and the SOC 2 version of this article maps the same practices onto the Trust Services Criteria.