Approach · Independence

We never certify our own work.

We build AI, and we test AI. The two share skills but never share a verdict. This page explains the rule, how we apply it, and how responsibility is divided on every build.

The rule

One thing we never do.

We never issue an independent security verdict on a product we built.

We test everything we build before handover. That testing is our own quality check, and it is labelled internal QA in every report. Formal independent testing is only ever performed on systems we did not build.

If you want independent sign-off on something we built, we refer you to another firm. A builder marking its own work is not assurance, however good the builder.

In practice

Two lines, and where each one ends.

Your needService lineWhat you receiveIndependent sign-off

You want an AI product builtYou have a use case, not the team.Line A · AI BuildDesign and build it, then test it ourselves before handover.Working productplus an internal QA report, labelled as such.Not permittedNever by usReferred to an independent third party or partner.

You already have an AI systemBuilt in-house, bought, or from another vendor.Line B · Independent AssuranceTest what others built, as a neutral third party.Findings reportpoint-in-time, with the residual risk stated.PermittedOur independent verdictHonest findings, never a “certified secure” stamp.

Before we take anything on

Four questions route every request.

They are always asked in the same order, so the independence rule and the authorisation check cannot be skipped under deadline pressure.

Question 1Can we do it well?The skills, the capacity, and no conflict of interest.
NoWe refer it out or bring in a partner.
YesNext question.
Question 2Is there an AI system already?Built in-house, bought, or from another vendor.
NoAI Build. Internal QA before handover is included.
YesNext question.
Question 3Did we build it?Including any part of it we designed or wrote.
YesNo independent verdict from us. We can re-test it as internal QA; independent sign-off goes elsewhere.
NoNext question.
Question 4Has every counterparty signed?Authorisation and rules of engagement, including provider terms.
NoScoping can continue. Testing cannot start.
YesIndependent testing begins, at the agreed depth.

Shared responsibility

You own your environment. We own the design we build.

Every build states in writing which security layers we own and which you own, signed before work starts. A problem in one layer is never allowed to become an argument about blame in another.

Security layer	Frontier 7	Model / platform	Client
Agent logic and secure design	Owns
Guardrails on input and output	Owns
Data-loss and access controls we implement	Owns		Approves
Pre-delivery security testing	Owns
Base-model behaviour		Owns
Infrastructure and tenant isolation		Owns	Configures
Which data sources are connected	Advises		Owns
Access permissions and identity			Owns
Data classification			Owns
Human oversight of outputs	Documents		Owns
Monitoring after handover	Support option		Owns

Owns: accountable for the layer. Lighter cells: a supporting role written into the statement of work. The matrix assigns accountability; the contract assigns liability.

After handover

The layer decides who fixes a problem, not who found it.

When something breaks, we find the layer first, then read who owns it. The route was fixed at signature.

Our design

We fix it

Agent logic, guardrails and the controls we built, on the terms the SOW sets for defects.

Your environment

You fix it

Connected data, access, configuration and monitoring. We can help, as an additional change or under a support agreement.

Model or platform

The provider fixes it

Base-model behaviour, hosting and tenant isolation. You raise it; we help document the evidence.

FAQ

Questions we are often asked.

Something else on your mind? Ask us directly.

Why not let the builder test its own work?

A builder marking its own work has a conflict of interest, however skilled it is. Keeping the verdict separate is what makes an assurance report worth relying on.

So who gives independent sign-off on your builds?

Another firm. We refer you to an independent tester and help them with access and documentation, but the verdict is theirs.

Does this mean your build testing is weaker?

No. The testing is the same discipline, run before every handover. The difference is the label: it is our quality check, so we call it internal QA rather than independent assurance.

Next step

Discuss your requirements.

Tell us what you want to build, or which AI system you need tested. We will tell you honestly whether we can do it well.

Talk to us

A scoping conversation first. Nothing starts until scope and limits are agreed in writing.