How AI-agent tool calls enter ISMS scope and map to the 2022 Annex A controls — what certification auditors ask, where default setups fall short, and the evidence a gateway produces.
QUICK ANSWERISO 27001 certifies an organisation’s ISMS, not a protocol. MCP traffic enters scope through Clause 4.3 — interfaces and dependencies — and the asset inventory, then gets tested against the Annex A access, identity, logging and supplier controls: A.5.15–5.18, A.8.2–8.3, A.8.15–8.16, A.8.32 and A.5.19–5.23.
No protocol or product can “be ISO 27001 certified” — the certificate attests an organisation’s information security management system. What matters is whether your MCP traffic sits inside that system’s scope with the Annex A controls evidenced. Three things put it there.
The scope statement must cover interfaces and dependencies with other organisations’ services. MCP servers are exactly that — and in a default setup they are an undocumented one: no inventory entry, no defined boundary, no record of what crosses it.
The 2022 revision of A.5.16 extends identity management to non-human entities. An agent calling tools on a shared key has no managed identity at all — registration, provisioning and de-registration apply to agents like any service account.
Current auditor guidance is to fold AI tooling into the existing ISMS: register the assets, add the risks, reuse access, logging and supplier controls. A gateway gives those controls a single enforcement point for agent traffic.
The 2022 Annex A controls MCP traffic is tested against. For each: what it requires, the question asked at audit, the default-setup gap, and the control that closes it.
Documented rules governing logical access to information and assets, based on business and security requirements.
What policy governs which agents and people may invoke which MCP tools — and who authorised it?
Default MCP access is binary: connect to a server and every tool on it is callable. There is no rule layer to point an auditor at.
Deterministic allow/deny rules with argument conditions, evaluated on every call before it executes — the documented access policy, enforced.
31,002 tools across 4,628 servers is the surface a single access-control policy has to govern.
Full lifecycle management of identities — explicitly including non-human entities — covering registration, provisioning and de-registration.
Does each person and agent calling tools have a distinct, lifecycle-managed identity rather than a shared key?
One upstream API key in every client config: no per-identity attribution, no lifecycle, nothing to de-register.
Per-person scoped grants — a distinct, issued, revocable identity for every consumer, human or agent.
1,649 execute and 154 financial tools are the categories where unattributable shared identity carries the most risk.
Controlled allocation, storage and revocation of secrets — passwords, keys, tokens — used to verify identity.
Where do the upstream MCP credentials live, and how are they rotated and revoked?
Upstream keys pasted into client configs on every laptop and CI runner — uncontrolled distribution with no central revocation.
Central credential custody: upstream keys are held by the gateway and never issued to clients; rotation and revocation happen once, centrally.
Access rights are provisioned, periodically reviewed, and promptly removed on role change or departure.
Show the last review of who can call which tools — and a leaver’s revocation record.
With grants scattered across client configs there is no central registry to review, and revoking a leaver means hunting laptops.
Grants are centrally listed, reviewed and revoked — an access review is an export of the grant registry.
Reviews matter most where they bite: 7,607 write and 1,773 destructive tools in the corpus.
Privileged access is restricted, tightly managed, and every privileged action is logged and reviewed.
How are high-impact tools — destructive, code-executing, financial — restricted, and where is the log of their use?
Destructive tools sit beside read tools with identical access. No elevation distinction, no per-action record.
Policy gates the high-risk categories behind explicit rules; every invocation is logged with the rule that decided it.
1,773 destructive plus 1,649 execute tools — the privileged-equivalent operations needing this treatment.
Access to information and application functions is restricted to need-to-know under the access-control policy.
Is agent access scoped to the specific functions — and argument values — its task needs?
Tool access is all-or-nothing per server; nothing distinguishes “read repo X” from “read everything”.
Argument conditions restrict which functions and which argument values a grant may call, deny-by-default.
19,718 read tools form the bulk of the corpus — where need-to-know scoping, not blanket read, is the live question.
Security-relevant events are logged, protected and retained (A.8.15); systems are actively monitored for anomalous behaviour (A.8.16).
Produce retained records across the audit period showing who called which tool and the outcome — and how anomalies get spotted.
MCP traffic is ephemeral client-to-server exchange. Nothing records it centrally; anomalies are invisible.
Every call lands in the audit log — grant, tool, argument keys, deciding rule, verdict — and rate limits and spend caps act as enforced anomaly thresholds.
One log record per call across 31,002 catalogued tools, retained to your ISMS retention policy and any legal or customer requirements.
Changes to systems and information processing facilities go through formal, risk-assessed, authorised change control.
When a new MCP server or tool joins the fleet, what authorisation and review happens first?
Anyone can paste a new server into a client config — new tools reach production with no review at all.
Registering a server and attaching its policy is a controlled, logged change point — the chokepoint where review happens.
4,628 servers in the wild is the change-surface new tools arrive from.
Security risk from suppliers’ services is managed: register, agreements, supply-chain risk, ongoing monitoring, and cloud-service lifecycle processes.
Externally-operated MCP servers are third-party services. Where is the register, the risk assessment, and the monitoring of what data crosses to them?
External servers get onboarded ad hoc — no register entry, no assessment, and data flows out invisibly. (Internally-built servers are in-scope assets, not suppliers.)
The upstream server registry doubles as the supplier inventory; per-call logs evidence ongoing monitoring; central custody means the supplier never holds your users’ credentials.
4,628 catalogued servers — the population a supplier and cloud-service register has to account for.
Illustrative policies — not complete compliance controls on their own.
Allow reads and listings only — and only inside the project tree. Everything else, including writes, stays denied by default. Illustrative — in production, pair the path rule with canonical path handling and least-privilege credentials upstream.
{
"version": "1",
"default": "deny",
"tools": {
"list_directory": {},
"read_file": {
"deny_if": [
{
"conditions": [
{ "path": "args.path", "op": "regex", "value": "^(?!/srv/projects/)" }
]
}
]
}
}
} Queries run; statements that change or destroy data do not. Each denied attempt is itself an A.8.15 log record. Illustrative — in production, pair the gateway rule with read-only database roles upstream.
{
"version": "1",
"default": "deny",
"tools": {
"list_tables": {},
"query": {
"deny_if": [
{
"conditions": [
{ "path": "args.sql", "op": "regex", "value": "(?i)(DROP|TRUNCATE|DELETE|ALTER)\\s" }
]
}
]
}
}
} See Writing policies for the policy format, operators, and quota shapes.
Certification audits look for traceability — policy to procedure to execution to recorded proof — sampled over time, not a pre-audit screenshot. The artefacts for the controls above:
| What the auditor asks for | What the gateway exports |
|---|---|
| Statement of Applicability entries for the access, logging and supplier controls | Gateway capabilities support and evidence the selected implementation of these controls for MCP traffic — policy engine for A.5.15, grants for A.5.16/5.18, audit log for A.8.15. |
| Periodic access reviews, with reviewer and actions, across multiple periods (A.5.18) | Exportable grant registry: every identity, its scoped tool set, issue date and last review. |
| Provisioning and deprovisioning records (A.5.16) | Grant issue and revocation history per identity, timestamped. |
| Audit trail of privileged actions (A.8.2) | The per-call log filtered to destructive, execute and financial tool categories. |
| Event logs sampled across the audit period, plus monitoring output (A.8.15/8.16) | Per-call records — grant, tool, argument keys, deciding rule, verdict — plus rate-limit and spend-cap threshold events, retained to the ISMS retention policy. |
| Change records with authorisation (A.8.32) | Server registration and policy-change history. |
| Supplier and cloud-service register with risk assessments (A.5.19–5.23) | The upstream server registry with per-server risk classification and traffic records. |
That is the wrong frame — ISO 27001 certifies an organisation’s information security management system, not a protocol or product. The real question is whether your use of MCP sits inside a certified ISMS and satisfies the relevant Annex A controls: access, identity, logging and supplier management. A gateway makes that evidenceable.
Yes, through scope and the asset inventory. Auditors now treat AI tools and the MCP servers they reach as part of the logical boundary — inventoried, risk-assessed and managed under existing controls, or explicitly excluded by a documented decision. A.5.16’s extension to non-human identities pulls agents squarely into identity management.
ISO 27001 is a certification of an organisation-wide ISMS, weighted internationally; SOC 2 is an auditor attestation against selected criteria, the common US SaaS baseline. They overlap heavily and ask the same questions of MCP traffic — who can call what, is it logged, are suppliers managed — so the same gateway evidence feeds both.
Externally-operated ones do — a vendor-hosted MCP server is a third-party service belonging in your supplier register with a risk assessment and ongoing monitoring, and cloud-hosted ones also fall under A.5.23. Internally-built servers are not suppliers; manage those as in-scope assets instead.
No. ISO 42001 is a separate, adjacent standard for AI management systems — neither is a prerequisite for the other. An existing ISO 27001 ISMS extends to cover MCP and AI assets on its own, and a gateway’s logs and access controls are reusable evidence if you later pursue 42001.
| Default setup | Through the gateway |
|---|---|
| One shared upstream API key on every laptop | Per-person scoped grant tokens, revocable individually |
| No record of what agents called | Per-call audit log: grant, tool, argument keys, rule, verdict |
| Every tool on a server is callable | Deny-by-default — each tool and argument explicitly granted |
| Access rules scattered across client configs | One central, version-controlled policy |
PolicyLayer doesn’t certify your organisation — it gives your compliance team enforceable controls and exportable evidence for the MCP slice of the audit.
Last reviewed 04-06-2026 by the PolicyLayer research team. This guide maps how the framework intersects with MCP deployments — it is not legal advice.
Per-person grants, deny-by-default policy and a per-call audit log — the ISO 27001 evidence for the MCP slice of your programme. Live in minutes.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.