What a Passing Build Actually Proves

A green build proves one thing: the checks you wrote passed. About the checks you did not write it says nothing at all.

When software took longer to build, some risk analysis happened during implementation. A working prototype can now be ready within days. The code may therefore be finished before the team has examined how it could fail, leaving less time for the same pre-release analysis.

Why basic checks are often omitted

The problem is usually not a lack of knowledge. Most software engineers can explain the purpose of a negative authorization test.

Such controls are omitted for organizational reasons. Nobody requested them, nobody is waiting for them and they are invisible in a demo. Their value appears only when they prevent an incident, so visible feature work is often prioritized instead.

The team that benefits from the control may also differ from the team shipping the feature. One team delivers the change while another may later manage the incident.

Before release, identify which failure scenarios are covered by a test and which remain assumptions. A passing test suite does not answer that question by itself.

The minimum content of a release gate

A useful gate is short and specific. Not a document. A set of things that must be true, each of which someone can check.

Two controls deserve particular attention: a request from a logged-out user and a request from the wrong tenant. Neither may return protected information. Without those tests, authorization is a design intention rather than a demonstrated property of the system. Hiding a button in the interface is insufficient.

Coverage percentages are a weak proxy for any of this. A percentage tells you how much code ran during the tests, not whether the payment path, the authorisation path or the migration path were among them. Steer by risk, not by the number.

Data migrations require a separate control because reverting an application does not undo a destructive migration. Rolling back and applying a corrective migration are different procedures and should be planned before release.

And the pull request should carry the evidence: what was run, what is still open, who accepted the remaining risk. A finding without a fix or an explicitly accepted risk is not closed. It is forgotten.

This approach is consistent with the NIST Secure Software Development Framework, which places verification and vulnerability response inside the development process.³ OWASP ASVS provides a testable catalogue of application-security requirements rather than a single coverage target.⁴ CISA's Secure by Design guidance adds the organizational responsibility: security should be a core product requirement, not a cost shifted to the user.⁵

How AI changes the threat model

One category of check is genuinely new, and it is not about model quality.

As soon as a product reads documents, web pages, emails or tool output, that content is untrusted input. This includes the parts that look like instructions addressed to the model. OWASP's guidance for LLM applications puts prompt injection at the top of the list for exactly this reason.¹ Its 2026 guidance for agentic applications broadens the problem to tool misuse, excessive autonomy and unsafe inter-agent communication.⁶

Forenta therefore treats connected context as external evidence and not as system instruction. The exact filtering and orchestration stay internal. The public claim is narrower and testable: external content does not receive authority merely because a language model can read it.

The design rule underneath is simpler than it sounds: keep out of the model whatever can be enforced deterministically. Authorisation, amounts, limits, state transitions and business rules belong in code. Interpretation, classification and generation are what the model is for. Anything with real consequence, meaning publishing, money, deletion or personal data, gets a human gate. That is also where NIST's generative AI profile lands.²

Small batches are a testing strategy

A small change is easier to review and revert. Each task should therefore end with a runnable control, such as a test, build or script with an unambiguous result. That provides evidence rather than a statement that the work succeeded.

This is especially important when an agent writes the code. An agent can report success even when the result is wrong. The agent must be able to run the control itself, otherwise the development loop has no reliable feedback.

The standard Forenta applies to its own releases

Forenta applies the same principle to its organizational process: operational safeguards are enforced outside the language model. A blocking risk remains visible, an invalid review does not become an ordinary result and required checklist items can hold a stage transition.

An authorized person can override advice when the project context requires it. The reason and the original advice remain in the audit record. This keeps the final authority with people without allowing the process to rewrite its own history.

These controls distinguish code that merely ran from code that demonstrably meets the release conditions. That distinction enables controlled speed.