ISO 27001 Secure Coding (A.8.28) When AI Agents Write the Code: What the Auditor Asks

What does ISO 27001 A.8.28 ask for?

Control 8.28 of ISO/IEC 27001:2022, Secure coding, asks an organization to apply secure coding principles to its software development. It appeared with the 2022 edition. Its guidance in ISO/IEC 27002:2022 runs in three stages, planning before coding, during coding, and verification and maintenance, and reaches beyond your own code to third-party and open-source components.

The certification body DQS described the new control in January 2023, in a post by its auditor Markus Jegelka: the framework "is to be applied holistically both to the company's own program code and to software from third parties and open source sources." The 2022 edition is the only one an auditor uses now: the transition from the previous edition ended on 31 October 2025, and certificates against it expired that day, as the Irish certification body NSAI notes, citing the IAF's mandatory document MD 26.

An auditor reads 8.28 together with the development controls around it, and each of them turns into a plain question once agents write the code:

The titles are those of the 2022 Annex A. ISO sells the texts of its standards, so the wording quoted in this guide comes from certification bodies and consultancies that reproduce it.

Does ISO 27001 say anything about AI coding agents?

ISO 27001 says nothing about AI coding agents. Its 2022 edition dates from October 2022, has received one amendment since according to ISO's catalogue, and none of its Annex A controls is about AI. Code an agent writes in your repository, under an account you gave it, is your code, and the same development controls apply to it.

That answer disappoints people who expect a special clause, and it is the more useful one. The 8.28 guidance already asks you to keep insecure practices out of the code, among them hard-coded passwords and unapproved code samples, as ISMS.online summarises ISO 27002. An agent that copies a pattern from elsewhere in the repository or from its training is producing exactly that, an unapproved code sample, faster than a reviewer can read it line by line. The control was written for code from any source, and agents are one more source.

Two other questions come up when a team uses agents, and both sit outside 8.28. What does the agent send to its model provider, and is that provider assessed as a supplier? Our guides on what Claude Code sends to Anthropic and what Cursor stores answer the first for each tool. And if someone asks whether you need ISO/IEC 42001, the AI management system standard ISO published in December 2023 for organizations "providing or utilizing AI-based products or services", it is a separate certification, and ISO 27001 does not require it.

What evidence does the auditor ask for when agents write the code?

The auditor asks for three kinds of evidence: documents that say how you develop securely, configuration that shows your checks are enforced, and records showing they ran on the changes of the audit period. With agents, the documents have to name the agents, and the records have to cover every merged change, including the ones no person wrote.

The consultancy Advisera puts the test for 8.28 in one line on its page on the control: the auditor checks "if principles for secure coding are integrated into the software lifecycle process", and if they are not found, "this is considered a nonconformity". The documents themselves "are not mandatory, but are recommended", a Secure Development Policy for a small or mid-sized company, a Secure Coding Policy for a larger one. In practice the auditor asks a handful of questions and samples changes to check the answers:

Tests deserve a warning of their own. When the agent writes the feature and its tests in the same session, a green test run proves the code does what the agent understood. In CybeDefend's controlled study, at least a third of the rule deviations the agent left in the code were covered by its own passing tests, so CI would never have flagged them. A security test the agent did not write, a scan or a check from your CI, gives 8.29 its meaning.

Is a CLAUDE.md or AGENTS.md file proof of secure coding?

A rules file is not proof: it is a policy the agent reads at the start of a session, and nothing in it records whether the code followed it. In CybeDefend's controlled study of 24 August 2026, a realistic rules section left as many broken rules per ticket as no file at all, 2.27 against 2.28.

Teams that prepare an audit with agents often put their secure coding standard in CLAUDE.md or AGENTS.md, and it is a sensible place for the agent to find it. Anthropic's own documentation on memory sets the limit: Claude treats these files "as context, not enforced configuration", and "there's no guarantee of strict compliance". Our study measured what that means on real tickets. One agent, Claude Opus 5, worked thirty developer tickets in three setups, ninety runs scored blind against sealed rubrics. With a hand-kept rules section, the agent implemented 7 of 55 rule specifics exactly, the same score as with no file. With the complete rule corpus pasted verbatim into the file, it reached 7 of 11. The details are in our article on whether Claude Code follows CLAUDE.md.

For an auditor this is the difference between design and operation. The file shows that you wrote the standard down and handed it to the agent, which helps with 8.25 and 8.28. It shows nothing about the code that came out. Serving each rule at the moment the agent writes the line did better in the same study, 0.28 broken rules per ticket, and that is what VibeDefend does. Even then, the auditor accepts as evidence only the check that ran on the change and the record it left.

How do you show which code an agent wrote?

Your git history shows it, if your agents leave a trace there. Claude Code adds a Co-Authored-By trailer that names the model to each commit by default, and one setting removes it. On 27 October 2026, 467 of the 494 commits on the main branch of our own website repository over the previous 90 days carried that trailer.

We ran two commands on that repository to count them:

git log origin/main --since=2026-07-29 --no-merges --format=%H | wc -l
git log origin/main --since=2026-07-29 --no-merges -i --grep="Co-Authored-By: Claude" --format=%H | wc -l

The trailers name five different Claude models over the period, so the history says which model wrote which change, and the other 27 commits carry no trailer at all. The settings reference explains where it comes from: by default Claude Code adds Co-Authored-By: <name> <noreply@anthropic.com>, where the name is the model in use, and setting attribution to false hides it. A trace that each developer can turn off is a convention. If you want it in your evidence, set it in the managed settings your organization deploys, and check what your other agents leave in commits and pull requests, because each tool does it differently.

Authorship tells the auditor which changes to look at, while the control itself is the set of gates every change goes through. Our article on reviewing an AI agent's pull requests explains why a dedicated machine account with signed commits beats a label a contributor can leave off.

Does SOC 2 ask for the same thing?

SOC 2 asks for much the same thing through two criteria. CC8.1 asks that changes to software be authorized, designed, developed, documented, tested, approved and implemented. CC7.1 asks for detection and monitoring that catch new vulnerabilities, and vulnerability scans are among its points of focus. A Type II report then tests that these controls worked over a period.

The AICPA's Trust Services Criteria sit behind a login on the AICPA site, so the text below is the one reproduced in Wazuh's documentation. CC8.1: "The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives." CC7.1: "To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities." Among the points of focus listed under them, CC8.1 includes "Tests System Changes" and "Approves System Changes", and CC7.1 includes "Conducts Vulnerability Scans".

The difference with ISO 27001 is the form of the result. ISO certifies a management system, with the Annex A controls you selected in your Statement of Applicability. SOC 2 is an attestation report. In the words of the audit firm TrustNet, "A licensed CPA gives an opinion on whether your controls are properly designed (Type I) and, if applicable, effectively operating over time (Type II)". With agents, a Type II period means records for every change across months, and the auditor samples them the way an ISO auditor samples them. A team ready for one is close to ready for the other.

What should you have ready before the audit?

Have a secure development policy that names your agents, a secure coding standard, a scan on every change behind a gate that refuses critical findings, an exception log with approvers and expiry dates, tested and approved pull requests, and a report covering the audit period, all of it current on the day the auditor samples.

1. The policy names the agents. Which agents, which accounts, which repositories, and what the agent may not do on its own, such as merging or deploying.
2. The standard is short and enforceable. It lists what you ban and points to the check that finds each item. A rule no check can find is a rule only a reviewer can enforce.
3. Every change gets the same scan. Code, dependencies, secrets and infrastructure files, on each pull request, whether a person or an agent opened it.
4. The gate decides, and records. A critical finding blocks the merge; lower risk warns and ships. Each exception is scoped, dated, justified and approved by name.
5. Approval and tests stay with the change. The pull request carries the approval, the CI run and the scan result, so a sampled change explains itself.
6. The report covers the period. One document the auditor can read, built from the scans and not pasted from a spreadsheet.

Ticket with requirementsAgent writes the changeScan on the changeGate blocks or warnsApproved and testedIn the report

Points 3, 4 and 6 are what CybeDefend's AppSec platform produces. It scans each repository for code weaknesses (SAST), dependencies (SCA), secrets, infrastructure as code, containers and CI/CD pipelines. A security policy written as code blocks the merge on a critical finding and warns on lower risk, across the organization, its teams and their projects, and an exception is scoped to a path, dated, justified and approved by name, each one leaving an audit line. Security reports map the findings to the OWASP Top 10 and the CWE Top 25, by organization, team or project, exported in PDF for the auditor, in HTML or in JSON for a GRC tool. If you are preparing ISO 27001 or SOC 2 with a team that codes with agents, we can walk through it with you. For the wider picture of what changes when agents write code, start with our guide to AI coding agent security.

Frequently asked questions

Does ISO 27001 allow AI coding agents?

Yes. Nothing in ISO/IEC 27001:2022 forbids them, and none of its Annex A controls is about AI. Code an agent writes in your repository is your code, so controls 8.25 to 8.29 and 8.32 apply to it as they apply to code a developer typed. Your policy has to say which agents are allowed and how their changes are checked.

Is ISO 27001 Annex A 8.28 mandatory?

For a company that develops software, in practice yes. ISO 27001 lets you exclude an Annex A control, but clause 6.1.3 d) requires a justification in your Statement of Applicability, and excluding secure coding while you write code is hard to defend. An auditor who finds no secure coding principles in your development process records a nonconformity.

What is a secure coding policy for ISO 27001?

A document that sets the coding principles your developers and agents follow and how you check them. ISO 27001 does not make it mandatory, but auditors expect to see the principles somewhere: a Secure Development Policy in a small or mid-sized company, a separate Secure Coding Policy in a larger one.

Is a CLAUDE.md or AGENTS.md file enough for an ISO 27001 audit?

No. It shows that you gave the agent your standard, not that the code follows it. Anthropic says Claude treats these files as context, not enforced configuration, and in CybeDefend's study of 24 August 2026 a realistic rules file left 2.27 broken rules per ticket, against 2.28 without one. The auditor wants records of checks that ran on each change.

Does every change an AI agent writes need a human review?

The auditor expects each change to be approved before release: approving system changes is a point of focus of SOC 2 CC8.1, and ISO 27001 8.32 covers change management. Your policy decides how agent changes are approved, and the auditor checks that the sampled pull requests match what the policy says.

Do we need ISO 42001 to use AI coding agents?

No. ISO/IEC 42001:2023 is a separate standard for an AI management system, designed by ISO for organizations providing or using AI-based products or services. ISO 27001 does not require it, and your 27001 auditor assesses your use of agents through the 27001 controls.

Does SOC 2 require vulnerability scanning?

The criterion CC7.1 asks for detection and monitoring that identify new vulnerabilities, and "Conducts Vulnerability Scans" is one of its points of focus. The criteria name no tool. The auditor tests the controls you described, and in a Type II report, tests them over the whole period.

How do I prove which code an AI agent wrote?

Use what your agents write into git. Claude Code adds a Co-Authored-By trailer naming the model to each commit by default, and the attribution setting can remove it, so lock it in managed settings. A dedicated machine account with signed commits is stronger. Authorship gives the auditor the scope; the controls on each change are the evidence.