Functional Safety and Safety Integrity Levels When Agents Write the Code

In short

IEC 61508 assigns a safety integrity level, SIL 1 to SIL 4, to each safety function from the risk reduction it has to deliver, and grades the techniques, the verification and the independence of assessment by that level. The level is a property of the safety function, and an AI coding agent writing the implementation leaves it where it was. A tool that generates code belongs, by the standard's description of support tools, to the class whose errors can reach the executable, and that class has to be justified, with evidence that the tool conforms to a specification. A language-model agent cannot meet that condition the way a compiler can. The route that remains is the standard's own fallback, which NASA spells out for auto-generated code: no credit for the tool, its output verified "using the same software standards and processes as hand-generated code", by means the agent did not control, with assessor independence that rises with the level.

What IEC 61508 asks

IEC 61508 is the base standard for functional safety of electrical, electronic and programmable electronic systems, in seven parts, second edition published in 2010. Its introduction describes "a generic approach for all safety lifecycle activities" and says it "introduces safety integrity levels for specifying the target level of safety integrity for the safety functions" (IEC 61508-1:2010, public preview, introduction). An overview hosted by the IEC's advisory committee on safety defines the two terms: functional safety is the "part of the overall safety that depends on a system or equipment operating correctly in response to its inputs", and a safety integrity level is a "Discrete level (one out of a possible four) for specifying the safety integrity requirements of the safety functions", with the note that "SIL is a property of a safety function" (Overview of IEC 61508 and Functional Safety, 2022, hosted by the IEC).

The level comes from risk, and part 1 is explicit that "The standard does not specify the safety integrity level requirements for any safety function, nor does it mandate how the safety integrity level is determined." Each level carries a target failure measure, and the same overview gives the risk reduction bands, from a factor between 10 and 100 at SIL 1 to a factor between 10,000 and 100,000 at SIL 4.

The standard does not in general quantify software failure: "Even though the probability of occurrence of systematic failures cannot in general be quantified the standard does, however, allow a claim to be made". The claim rests on process. Part 3, the software part, "applies to any software forming part of a safety-related system or used to develop a safety-related system", and provides "measures and techniques, which are graded against the required systematic capability, for the avoidance of and control of faults and failures in the software" (IEC 61508-3:2010, public preview, scope). A software element has to achieve a systematic capability equal to the SIL of the function it implements, and the Annex A tables are graded by that capability. Annex A grades the techniques for each lifecycle activity in ten tables, from the software safety requirements specification to functional safety assessment. The higher the level, the more of them become highly recommended, and the one independence the standard grades by level is the assessor's: part 1 sets "Minimum levels of independence of those carrying out functional safety assessment" in its Tables 4 and 5, and the UK nuclear regulator summarizes the principle: "A graded approach to levels of independence, based on the class of the system, should be adopted" (ONR, NS-TAST-GD-046, issue 7).

The level is fixed by the hazard and the risk reduction required, and the rigor of the software work follows from it. Nothing in that chain asks who or what wrote the code.

Where the standard already meets the agent: the tool question

Part 3 does ask about tools. Its scope "provides specific requirements applicable to support tools used to develop and configure a safety-related system", listing "development and design tools, language translators, testing and debugging tools, configuration management tools". The requirements sit in clause 7.4.4 of part 3, and the classes of off-line support tool they rest on are defined in part 4, in clause 3.2.11. Neither clause is public; the descriptions below are the ones UL Solutions and TUV Rheinland reproduce in public presentations (UL Solutions, IEC 61508: why tool qualification, 2024; TUV Rheinland and CISQ, 2020). A T1 tool "generates no outputs which can directly or indirectly contribute to the executable code". A T2 tool, in UL's wording, "supports the test or verification of the design or executable code, where errors in the tool can fail to reveal defects but cannot directly create errors in the executable software", such as a static analyzer or a coverage tool. A T3 tool "generates outputs which can directly or indirectly contribute to the executable code of the safety related system", and the example both presentations give is an optimizing compiler.

An agent that writes code generates outputs that contribute to the executable. It sits in the third class, with the compiler, whoever commits the code. The class follows the use: the same agent writing tests or reviewing code is a T2 tool with its own specification requirement, so its tests are producer evidence. The same material reproduces what the standard asks of that class: the selection of the tool "shall be justified", and "for each tool in class T3, evidence shall be available that the tool conforms to its specification or documentation", with each new version qualified again. In the worked example the UL material gives for the Annex A table on support tools, "increased confidence from use" is highly recommended for the tools and the translator at SIL 2.

One vendor publishes what that qualification looks like. Ferrocene is a Rust compiler its vendor describes as TUV SUD-qualified (ferrocene.dev), with public documents that state the scope, "industrial [IEC 61508:2010] (class T3)" among others (Ferrocene evaluation report); the qualification is scoped to a named compiler version and a language specification, and the method is a hazard analysis of the tool, traceability from each potential error to a test, and test suites run before any change is merged.

Set a language-model coding agent against that template. The compiler's route rests on a behavioral specification and evidence of conformance to it, and the agent has neither: its output is sampled from a probability distribution at each step, so the same prompt can produce different code on two runs, and its version changes under the user, often without notice, where the standard asks for each new version to be qualified. Confidence from use, the other evidence the clause allows, needs a frozen version and a record of similar use, which no current model has. With current models the route is closed.

The route that remains

The standard writes the fallback itself. In UL's summary of clause 7.4.4, tool validation records "shall be documented" with "effective measures to control failures of the executable safety related system that result from faults that are attributable to the tool", and "the suitability of the automatic translator development shall be assessed". No credit is taken for the tool; its output is verified as the project's own code. NASA's requirements for auto-generated code say how. NPR 7150.2D, the agency's software engineering requirements, requires the project manager to define an approach to automatic code generation that includes "Validation and verification of auto-generation tools", "Description of the limits and the allowable scope for the use of the auto-generated software", "Verification and validation of auto-generated source code using the same software standards and processes as hand-generated code", "Monitoring the actual use of auto-generated source code compared to the planned use", and configuration management of the generator, its inputs, its outputs and the modifications made to the output (NPR 7150.2D, section 3.8.1, SWE-146). The tool's own failure mechanisms are assessed first: invented interfaces, silently imported third-party code, deviations from the coding standard, and reviewers' trust in plausible output.

The UK nuclear regulator's guidance gives the principle that decides how much verification the output needs. Tool qualification "will be a function of its impact on the target software, and the likelihood that other tools or processes may detect faults introduced by that tool." It goes further: "One means of tool qualification is to use independent confidence building measures as part of an assessment, to identify the nature of the faults that can be introduced in the target software and their consequences." The checking has to be diverse from the producer: "The static analysis tool used for independent confidence building should be of proven design, qualified (see Appendix 6) and diverse from the tools used by the designers." The regulator's two legs, "production excellence demonstration and independent confidence building", map onto an agent-written safety function: the agent's work sits inside the first, the second is checking by an independent team with methods the agent did not touch.

Our white paper AI Has Moved the Bottleneck draws the same line from the organizational side: "AI can expand the engineering workforce. However, the need for appropriately qualified engineers and accountable technical authorities cannot be eliminated." The competence guidance the UK regulator issued with the engineering institutions agrees: "The achievement of sufficiently low levels of risk is critically dependent on individual and team competence" (HSE, Managing competence for safety-related systems). The paper's warning follows: "This should not be confused with the transfer of competence or accountability."

The evidence by lifecycle activity, with the rows an agent changes

The table follows the activities of IEC 61508-3 Annex A, whose titles are public. The middle column states what the standard grades by level, since the cells sit behind the paywall; the independence it grades by level is the assessor's, and independence of testers and validators from the authors is the practice the assessor looks for. The right column is ours.

The tools row is where the agent is declared and bounded. The verification row is where the regulator's sentence about detection by other tools and processes turns into a list of named, qualified tools that do not include the agent. The review checklist for agent-written changes gives the per-change questions behind both rows, and the assurance case is where the answers are kept together for the assessor.

Why the specification row comes first

The UK Health and Safety Executive analyzed 34 control system incidents and found "a total of 56 causes" among them. By phase, "inadequate specification" accounted for 44 percent of the primary causes, 32 points of it inadequate safety integrity requirements and 12 inadequate functional requirements; design and implementation took 15 percent, installation and commissioning 6, operation and maintenance 15, and changes after commissioning 20 (HSE, Out of control, second edition 2003). The authors note the "low statistical significance" of a small sample, and still conclude that "most control system failures may have their root cause in an inadequate specification."

An agent writes code from the specification it is given. It makes the implementation phase faster and, as our article on agentic engineering describes, raises the volume of what has to be verified and accepted. It does nothing to the phase where, on this analysis, most failures start. For a team adopting agents on safety-related software, the first investment is in the hazard analysis and the safety requirements that precede the agent, and the prompt must never stand in for the specification.

Where the standards are moving

ISO/IEC TR 5469, published in January 2024, is a technical report without normative force whose abstract names, among three uses of AI, the "use of AI systems to design and develop safety related functions" (IEC webstore, ISO/IEC TR 5469:2024); the ISO/IEC TS 22440 series that follows it is at committee draft stage (ISO project record). The third edition of IEC 61508 reached the final draft stage in October 2026, with the FDIS ballot opened on 2 October according to the IEC project data (IEC 61508-3 ED3 project record); the published abstract of the German draft of part 3 says it revises the requirements on off-line software tools, brings in software technology classes for AI inside the product, and sets no requirements of its own on AI as a development aid (DIN, draft E DIN EN IEC 61508-3:2026-09). As of October 2026 no standard or regulatory requirement names a language-model coding agent.

Where Kealu Vector fits

The Agentic Engineering Assurance Layer is the proposed category for the layer that governs how agentic engineering work is performed and evidenced, so that humans can trust and accept the resulting work. The white paper The Agentic Engineering Assurance Layer develops it as a vendor-neutral category, and the questions raised here hold whatever tools a team uses. Kealu Vector, currently designated Vector Assurance Assist, is our early-access implementation of that category. Any tool that produces or records verification evidence, Kealu Vector included, is itself an off-line support tool under the clause above and takes the same treatment.

FAQ

What is a safety integrity level in IEC 61508?

One of four discrete levels, SIL 1 to SIL 4, that specify the safety integrity requirements of a safety function, derived from the risk reduction the function has to provide. Each level carries a target failure measure for the function, and the software that implements it has to achieve a systematic capability equal to the level, with techniques, verification activities and assessor independence graded accordingly.

Does AI-generated code change the SIL of a safety function?

No. The level comes from the hazard and the risk reduction required, which IEC 61508 leaves to the risk analysis, and the rigor of the software work follows from the level. An AI coding agent changes the evidence: it is declared as a development tool with version and limits, its output is verified and validated as hand-written code would be, and the tools and people that check it are independent of it.

Can an AI coding agent be qualified as a tool under IEC 61508-3?

By the public descriptions of the standard's tool classes, an agent that generates code is in the class whose errors can reach the executable, which asks for evidence that the tool conforms to its specification, re-qualified at each version. A language-model agent has no output specification to conform to, is not deterministic, and changes version without notice, so with current models that route stays closed. What remains is the standard's own fallback: no credit taken for the tool, its failure mechanisms assessed, its output verified as the project's own code by independent, qualified means.

What evidence will a functional safety assessor want for agent-written code?

The development plan naming the agent as a tool with its version, intended use and limits; requirements and design dated before the code; verification by a qualified static analyzer and tests the agent did not control; traceability from requirements to the generated lines; the record of each agent session kept with the change; and assessor independence that rises with the SIL.