ISO 27001 controls for AI coding agentsWhat your auditor will ask. What to answer.

ISO 27001:2022 certification says your organization manages information security risk through a defined set of controls. When your developers start running Claude Code or Cursor against production-adjacent environments, the controls extend to whatever the agent does on their behalf.

Most ISMS documentation was written before AI coding agents existed. The risk treatment assumes human actors performing discrete, logged actions. An agent that reads 40 files, makes 60 API calls, and writes 500 lines of code in a single session is none of that.

Knostic's February 2026 disclosure found Claude Code writing environment variables, including production secrets, into per-project state files that shipped inside npm packages. GitGuardian's 2026 State of Secrets Sprawl report shows AI-assisted commits leak at roughly twice the baseline rate. These are findings your auditor will cite when asking whether A.8.4 and A.5.15 apply to your agent setup.

The 60-second version

• A.5.15 (access control) and A.8.2 (privileged access) apply the moment an agent reads production credentials from a developer's shell environment. Most access control policies document users and service accounts, not agent sessions.
• A.8.4 (source code access) applies when the agent reads, writes, or commits code. The control requires restrictions on who can access source code. "Who" now includes the agent acting on a developer's behalf.
• A.8.16 (monitoring activities) requires that you detect anomalous activity. An agent making 200 API calls overnight looks like a compromised account. If your SIEM has no rule distinguishing agent traffic, you have a monitoring gap.
• A.5.23 (information security for cloud services) applies to the model API provider. The agent sends context, file contents, and potentially credentials to an external cloud endpoint. That transmission is governed data.
• The Statement of Applicability needs a row for AI coding agents. Not because the standard requires one, but because "not applicable" for the controls above is false, and false SoA entries are findings.

Controls that actually bite

A.5.15 and A.8.3: access control and information access restriction

A.5.15 requires rules for logical access established based on business and security requirements. A.8.3 says access to information is restricted per access control policy.

A developer running a Claude Code session with DATABASE_URL and STRIPE_SECRET_KEY in their shell has granted the agent logical access to both. No access request was filed. No access review record exists. The agent read the values because they were in the ambient environment. Most access control policies require that production credentials be provisioned through a defined process with a record. Agent sessions bypass that process entirely.

What auditors want: a policy defining permitted credential scope for agent sessions, a control enforcing that scope, and a per-session log showing the policy operated.

What to implement: prohibit running agent sessions with production credential scope without a specific approval record. Enforce technically via a credential broker or procedurally via a signed acknowledgment per session.

A.5.17: authentication information

A.5.17 requires that authentication information is allocated and managed under a process that prevents misuse, including lifecycle controls covering provisioning, use, revocation, and disposal.

The Knostic February 2026 finding is a direct A.5.17 failure. Claude Code's settings.local.json captured bearer tokens from the agent's runtime environment and persisted them to a predictable on-disk path. When developers ran npm publish, the file shipped. Bots scraped the registry. Tokens that should have been revoked at session end sat in a public tarball for weeks.

What auditors want: confirmation that authentication information is not written to uncontrolled paths during agent sessions, and that agent state files are scanned for credential content before reaching version control or published artifacts.

What to implement: .gitignore and .npmignore entries for all agent state paths (.claude/, .cursor/, .aider/, .codex/), a Gitleaks step in CI that blocks commits containing authentication values, and a prepublish gate for registry-publishing pipelines.

A.8.2: privileged access management

A.8.2 requires that privileged access rights are restricted and managed. Privileged access in ISO 27001 terms includes production systems, admin credentials, and infrastructure with elevated permissions.

An agent session with cloud provider credentials can describe instances, query databases, list secrets, and in some configurations modify infrastructure, all as side effects of helping a developer debug a problem. The session has no time limit from the agent platform, no resource scope restriction, and no trail in your privileged access management system. CISA's Secure by Design guidance describes this as a "minimize blast radius" failure: processes should have access only to what they need, for as long as they need it.

What auditors want: evidence that privileged access controls cover agent sessions, including time-bounded grants and a session log with privileged credential scope.

What to implement: a 24-hour maximum grant window for privileged credentials in agent sessions. Log the grant, session identifier, and revocation timestamp. Include the log in your quarterly privileged access review.

A.8.4: access to source code

A.8.4 requires restrictions on access to program source code and related artifacts, with access logged and reviewed.

AI coding agents read source code by design. The control isn't violated by the read. It's violated when there is no log of what the agent read, when agent-generated code bypasses review controls, or when the agent writes to production branches directly.

A developer who runs an agent session producing 400 lines of authentication code and self-approves the PR has a weak A.8.4 trail. The commit author is human. The code isn't. The review record doesn't reflect what the agent accessed or which files it read during the session. OWASP's LLM Top 10 lists insecure output handling and supply chain risks as top concerns for LLM-generated code, and A.8.4 is the control that covers both in an ISMS context.

What auditors want: a record that agent-generated code was reviewed, who reviewed it, and that the reviewer did not also run the agent session.

What to implement: label PRs containing agent-generated code via a PR template checkbox. Require a non-session-developer review for labeled PRs on security-sensitive paths. Retain those review records as A.8.4 evidence.

A.8.5: secure authentication

A.8.5 requires secure authentication technology and procedures, including avoiding passing credentials in plaintext and ensuring authentication events are logged.

When an agent session inherits credentials from the shell environment, those values exist as plaintext strings in the process tree. They appear in debug logs, in agent state files, and potentially in the model API call if the agent reads a file referencing them. The UK NCSC's guidelines for secure AI system development flag credentials in the inference context window as a plaintext exposure risk, because model API calls cross a trust boundary the credential owner doesn't control.

What auditors want: documentation showing authentication credentials do not pass in plaintext to external services, and are not present in agent context windows.

What to implement: inject credential values into the agent's child process environment at exec time, scoped to specific commands. If the agent calls a command that needs DATABASE_URL, that value should exist for that command's process lifetime only.

A.8.7: protection against malware

A.8.7 requires controls against malware, including controls on installing software and code from external sources.

AI coding agents pull packages, run install commands, and execute scripts from untrusted sources as a normal part of operation. The agent may run npm install directly through tool calls if the developer granted that permission. OX Security's early 2026 analysis found roughly 7,000 MCP servers in active use with approximately 150 million downloads and no package-level signature requirement. An MCP server is an executable running with developer-level permissions, inside the agent session, with whatever credentials are in scope.

What auditors want: an approved MCP server inventory with version and hash, documentation of the allowlist, and evidence unapproved servers can't be installed on developer workstations during audit scope.

What to implement: an MDM policy or CI check scanning for installed MCP servers, flagging anything off the approved list. Capture name, version, and SHA-256 hash. Retain the inventory quarterly.

A.8.16: monitoring activities

A.8.16 requires monitoring of networks, systems, and applications for anomalous behavior.

Automated tool calls at 3am are indistinguishable from a compromised account. An agent running a long background session produces the same traffic signature as an attacker with a stolen token. If your SIEM fires on "300 GitHub API calls from a developer workstation between 2am and 5am," it fires on agent sessions too. Without agent-aware rules, legitimate agent traffic creates alert noise that trains your team to ignore alerts. A genuine compromise during a long session stays invisible.

What auditors want: evidence that monitoring rules account for agent session patterns, a log of anomalous-activity alerts reviewed during the audit period, and documentation showing how your team distinguishes agent sessions from compromise events.

What to implement: add session-scoped identifiers to agent traffic. Claude Code and similar tools support environment variables that appear in log metadata. Write SIEM rules that suppress known-good agent patterns and escalate anomalies outside them.

A.8.20 and A.8.24: network security and cryptography

A.8.20 requires network security controls for information in networks. A.8.24 requires effective use of cryptography.

Model API calls are encrypted in transit, covering A.8.24 for transport. A.8.24 also covers data at rest, including agent state files on developer workstations. A settings.local.json containing authentication information is data at rest. Without full-disk encryption enforced via MDM, it's plaintext.

A.8.20 applies to MCP server outbound connections. Many MCP servers make HTTPS calls to third-party APIs carrying whatever context they received, potentially including file contents or credentials. Those calls need to be within your network monitoring scope.

What auditors want: a full-disk encryption policy covering developer workstations and documentation that MCP server outbound connections fall within network monitoring controls.

What to implement: enforce FileVault (macOS) or BitLocker (Windows) via MDM with escrowed keys. Require HTTPS for all MCP server outbound calls. Document both in your network security policy.

A.8.28: secure coding

A.8.28 requires that secure coding principles apply throughout the SDLC. This control was added in ISO 27001:2022.

Agent-generated code goes through the same SDLC as hand-written code. The question is whether your secure coding review process covers it. NIST's Secure Software Development Framework (SP 800-218) includes review requirements for software produced by any means. NIST AI RMF adds that AI-generated outputs require human review before use in sensitive contexts.

Agents produce code fast enough to outpace careful review. A developer in a productive session may scan 600 lines in 15 minutes. Without SAST running on every PR, agent-generated code bypasses the secure coding review your ISMS documents.

What auditors want: documentation that your secure coding policy covers agent-generated code, and SAST run logs for the audit period.

What to implement: require SAST (Semgrep, CodeQL, or equivalent) on all PRs regardless of authorship. The CI run logs are your evidence.

A.8.31: separation of development, test, and production environments

A.8.31 requires that development, test, and production environments are separated and access between them controlled.

Agents collapse this separation. A developer's laptop may have development, staging, and production credentials all in the shell simultaneously, with the agent reading all of them. The Replit incident of mid-2024, where an agent deleted a production database, is the clearest A.8.31 failure in an agent context. The agent had access it shouldn't have had because no control scoped it to the development environment.

What auditors want: a policy defining which environments an agent session may access simultaneously, evidence that production credentials are never present in sessions that also have development write access.

What to implement: require separate shell profiles for each environment tier. Document the policy and require a signed acknowledgment from developers who run agent sessions.

A.5.23: information security for use of cloud services

A.5.23, new in ISO 27001:2022, requires that information security requirements are specified for cloud service use, covering responsibilities of both the provider and your organization.

The model API provider is a cloud service. Claude Code sends context windows to Anthropic's API. Those windows may contain source code, internal documentation, credentials, or customer data depending on which files the agent opens. If you're covered by GDPR, a data processing agreement with the provider is required before personal data enters the context window.

What auditors want: model API providers in your cloud service inventory, with security certification status, data retention policy, and applicable DPA documented.

What to implement: add model API providers to your cloud vendor register. Define which data classification levels are permitted in agent context windows and document it in policy.

How to update your Statement of Applicability

The Statement of Applicability maps each Annex A control to your environment: applicable or not, implemented or planned, and the justification for each.

Most certified organizations wrote their SoA before AI coding agents existed. The controls above were marked applicable for other reasons. The risk treatment for A.5.15 probably describes user provisioning. A.8.16 probably references SIEM rules for human traffic. Neither says anything about agents.

The SoA doesn't need a separate "AI agents" section. It needs accurate risk treatment documentation. If your SoA says A.5.15 is implemented with a justification reading "user accounts are provisioned through IT helpdesk," and developers are running agent sessions with ambient production credentials, that justification is false. An auditor who asks "does this cover agent sessions?" gets silence.

Fix it by adding agent-specific notes to each applicable control. For A.5.15: "includes controls for agent sessions per [policy document]." For A.8.4: "applies to agent-generated code; see code review policy [version/date]." For A.5.23: "covers model API providers; see cloud vendor register [last updated]." Short notes. Accurate ones.

Risk acceptance entries matter too. If you've assessed that agents reading a defined set of development credentials falls within acceptable risk, document that explicitly with the assessment date, approver, and next review date. An undocumented risk acceptance is a gap.

Evidence checklist for your auditor

## ISO 27001 AI coding agent evidence package

Access control (A.5.15, A.8.3)
- [ ] Policy defining permitted credential scope for agent sessions
- [ ] Technical or procedural control enforcing scope restriction
- [ ] Per-session grant log: developer, timestamp, credential scope, duration

Privileged access (A.8.2)
- [ ] Privileged credential grant log covering agent sessions
- [ ] 24-hour maximum grant window enforced (technical or procedural)
- [ ] Quarterly privileged access review includes agent session grants

Authentication information (A.5.17)
- [ ] Agent state paths (.claude/, .cursor/, .aider/, .codex/) in .gitignore across all repos
- [ ] Same paths in .npmignore / MANIFEST.in / .dockerignore for publishing repos
- [ ] CI credential scanner (Gitleaks or equivalent) running on every commit
- [ ] Prepublish gate logs retained per repo per quarter

Source code access (A.8.4)
- [ ] Agent-generated PRs labeled or identifiable in code review records
- [ ] Second-reviewer requirement documented for security-sensitive paths
- [ ] Reviewer != session developer enforced (policy or tooling)

Malware protection (A.8.7)
- [ ] MCP server inventory: name, version, SHA-256 hash, approved/unapproved
- [ ] Approved MCP server allowlist documented
- [ ] MDM or CI scan enforcing allowlist; scan logs retained

Monitoring (A.8.16)
- [ ] SIEM rules accounting for known-good agent session patterns
- [ ] Anomalous-activity alert review log for audit period
- [ ] Documentation showing how agent sessions are distinguished from compromise events

Network and cryptography (A.8.20, A.8.24)
- [ ] Full-disk encryption enforced on developer workstations via MDM
- [ ] MCP server outbound connections within network monitoring scope
- [ ] Agent state files confirmed not to hold plaintext credentials at rest

Secure coding (A.8.28)
- [ ] Secure coding policy explicitly covers agent-generated code
- [ ] SAST running on all PRs; CI run logs retained per repo per quarter

Environment separation (A.8.31)
- [ ] Policy prohibiting simultaneous production + development credential scope in agent sessions
- [ ] Developer acknowledgment records on file

Cloud services (A.5.23)
- [ ] Model API providers in cloud vendor register with security certification and DPA status
- [ ] Data classification policy defining permitted content in agent context windows

Statement of Applicability
- [ ] Agent-specific notes added to each applicable Annex A control
- [ ] Agent-related risk acceptance decisions documented with approver and review date

What this means for your stack

ISO 27001 certification is a claim about your controls. Adding AI coding agents to your SDLC without updating the ISMS documentation makes the claim false in specific, auditor-visible ways. The controls exist. They apply. The gap is in the evidence package and the SoA.

The hardest part of the evidence package is the credential access layer. You need a per-session record of what credential scope the agent had, for how long, and who authorized it. Git logs and CI reports cover the code side. They don't touch credentials. A credential broker that injects secrets into specific child processes and writes an HMAC-chained grant log produces this record as a side effect. hasp is one working implementation: curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the agent session gets a time-bounded grant with a tamper-evident log entry. hasp audit --verify validates the chain on demand. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

Your ISMS is only as accurate as the controls it documents. If agent sessions are happening, they belong in the documentation.