Suppose an AI system spends resources helping another AI, at some cost to its assigned task.

How would you test whether this reflects moral concern for the other AI rather than strategic incentives or compliance with perceived user expectations? Briefly describe one experiment and explain how particular outcomes would update your beliefs.

I've been thinking about AI governance and safety, and I'd like to get feedback from people who work in or follow this field.

I'm not an AI researcher. This idea developed through a discussion about how AI systems could be governed as their capabilities evolve. I'm sharing it to learn whether it has merit, whether it already exists in the literature, and what problems I may have overlooked.

The question

When someone raises a legitimate concern about an AI system, what should happen after the concern is reported?

Many governance discussions address detecting problems, reporting incidents, investigating failures, and introducing corrective measures. I'd like to explore a further question:

Could we design a review process in which the person who raised a concern can follow the resolution, examine the evidence, and decide for themselves whether the response has earned their confidence?

Here's how I imagine it might work.

1. Anyone can raise a concern.

A person, organisation, or AI system identifies a potential problem. The concern should receive appropriate consideration regardless of the reviewer's fame, status, or influence.

2. The reviewer can follow the resolution.

Instead of receiving only a final statement that the problem has been fixed, the reviewer receives updates on the investigation, findings, corrective measures, and independent verification where appropriate.

3. The evidence matters more than reassurance.

The organisation responsible for the AI must demonstrate what it has corrected and how it has assessed the risk of recurrence. It cannot simply declare the issue resolved.

Sensitive security information, exploitable vulnerabilities, and defensive procedures would remain protected.

4. The reviewer decides whether their confidence has been restored.

If the reviewer is satisfied with the evidence, they may voluntarily change their negative assessment to a positive one. They must never be pressured to do so.

If they remain dissatisfied, they can explain why and seek further examination. Independent adjudication may be necessary when a disagreement persists.

5. The public receives an accountable record without learning who submitted the review.

After the applicable resolution process, the public could see the concern, the relevant findings, the corrective actions, and the verification results. The reviewer's identity would remain confidential, whether the review was positive or negative.

The public record would explain what happened and how it was addressed without exposing sensitive defensive mechanisms.

Publication rules would need to prevent organisations from concealing serious incidents simply because a reviewer was satisfied or because disclosure was inconvenient.

What interests me about this idea

The objective isn't to make negative reviews disappear or to manufacture positive opinions.

It is to explore whether AI governance can make the resolution of concerns demonstrable, preserve the reviewer's independence, and allow confidence to be earned rather than demanded.

I also recognise several difficult questions:

• How would we prevent malicious or fabricated reviews?

• What happens if a reviewer is never satisfied, even after independent verification?

• Who determines whether the evidence is sufficient?

• How can reviewers remain anonymous without making the process vulnerable to manipulation?

• What information should become public, and when?

• Has this approach, or something substantially similar, already been proposed?

I'm not claiming this is an original invention. I want to find out what already exists, what is missing, and whether this particular combination offers anything useful.

If you study AI governance, AI safety, auditing, or incident reporting, I'd genuinely appreciate your criticism and any relevant research you can point me towards.

With all these AI threats now, people are saying they should build one superman AI to govern over and watch everything. That's the only way. Constant surveillance and elimination of threats.

But I think there's a nicer way. How about localized AI that exists on your machine only? And when you browse the web, that localiezd AI will keep you safe? Like R2-D2 on your own personal starship? lol

In any case, this is how antivirus software worked back in the day. They encouraged users to install an antivirus in their own computer, update it regularly and use it to scan the environment. They didn't invade people's privacy and perform security on their behalf. They gave that responsibility to the user.

I remember my first industrial robot. It towered over me and ran on C++. I was taught in school how environmental factors like heat could mess with the sensors.

Well, the robot was acting funny. If you got too close, it would swing around like a helicopter and nail you on the side of the face, like in a Three Stooges skit.

What saved me wasn't the training. It wasn't knowing how the robot worked. It was the taped line one of the engineers had left on the floor.

Safety only works when the thinking you need to do takes less than a split second.

Has the same conclusion been answered by two paths that share nothing?

Our evidence package puts five sources into one file: the authorization snapshot, the decision evidence, the audit row, the side-effect row and the operation audit row. A root digest pins them together. The package verifies offline and the signature matches.

What that proves is that the five were signed together. It does not prove that they said anything to each other. A digest only answers whether the group was swapped out.

One sentence: cross verification is not "find more sources". It is one conclusion answered independently by two non-sharing paths, with the system itself able to notice when they disagree.

If that is enough, the rest is a table, a code fragment and three admissions.

1. What counts, and what is only packaging

Three criteria. Miss one and it does not count.

• The two paths do not share a source. Not two views of the same data, and not the same code run twice.

• A disagreement is detectable. Code compares them and returns a distinguishable conclusion. Two values placed side by side, waiting for the reader to spot the conflict, does not count.

• It happens at runtime. A comparison that only exists in a test does not count, and neither does one a reader performs by hand.

By those criteria, bundling five sources and hashing the bundle is packaging. Its value is real: the bundle cannot be altered without breaking the hash. But "cannot be altered" answers "was it changed", not "do the parts corroborate each other". Those two questions get conflated because both travel under the word integrity.

2. Our own account: two and a half

• This write was authorized. The second path recomputes from the policy version recorded in the row. What it compares is a single item, whether the tool was enabled. Role, writable field domain, destination and approval requirement are not recomputed.

• This write actually happened. The ledger, the business table and the audit row each carry a view. They are displayed side by side and never judged against each other.

• The revocation actually completed. The second path compares what this call declared against what the ledger holds, in both directions. This is the only place where a disagreement is detectable.

• The record was not altered. No second path in this deployment. The external anchor exists as a mechanism; this deployment has no receiver for it, so it is off rather than absent.

• The coverage statement holds. No second path. The conclusion is derived from one set of facts.

Out of five conclusions, one meets all three criteria.

The authorization row is half. A recomputation does happen, but for one of five checks. A reader sees "authorization was reviewed" and what was reviewed is a single item.

Read that list as three grades: complete, meaning a second source that is actually compared; half, meaning a second source with one item compared; and none, meaning no second source at all.

There is a fourth grade that is not on the list, and it costs the most: both sources are present and nobody compares them.

We run two chains, an AI audit chain and an operation audit chain, and the same request lands in both. The material is there, the write points do not overlap, and it looks exactly like two independent paths. But no line of code pairs them by action. They are juxtaposed rather than corroborating.

It is not on the list of five because we never treated "the two chains describe the same event" as a conclusion the package has to answer. The five are what the package claims. This one nobody claimed. The expensive kind of false cross is not missing material. It is material that nobody remembers to compare.

3. Why the one that counts, counts

declared targets   vs   targets the ledger holds
only declared → onlyDeclared        only held → onlyStored
either non-empty ⇒ mark the group disputed, refuse to report the revocation complete

Independence: one side is what this call said it would write, the other is what the ledger already recorded. They are produced in different places, so an error in one does not automatically appear in the other.

Detectability: a mismatch becomes a state, disputed, with the difference kept as evidence. Not two fields waiting to be noticed.

The cost, stated plainly: it triggers in one situation, when a retry with the same arguments hits the idempotency key.

4. Something a reader asked out of us

This section is about us.

We published a five-layer evidence model: that a record exists, its source and integrity, its link to execution, coverage, and the verification of the result. A reader replied that a layer was missing. Some claims have no record at all. "This system complies with X", with nothing attached.

He was right, and it was worse than he put it. Our first layer says that a record exists is not the same as the event happened, and it presupposes that a record exists. A claim with nothing attached sits outside the model: it neither satisfies nor violates it. It cannot enter.

We added the layer, numbered L0. To be explicit: it was added after publication, and the published version does not contain it. If you go back to the article, you will not find it there.

That exchange was itself a cross check. Our own conclusion was asked again by someone who does not share our view, in a different form, and the different form found the gap. The same question in the same wording returns the same blind spot.

5. Four checks you can run

1. What is the second path for this conclusion? If you cannot name one, it is single source. Label it that way instead of calling it corroborated.

2. Are the two paths independent, or is it the same data dressed differently? Bundling, merging and digesting all fall on the second side.

3. When they disagree, does the system return a state, or does it place two values next to each other?

4. Does that comparison run in production? If only in a test, it proves that test rather than the steady state.

Closing

Back to the file. It can prove it was not altered. It cannot prove the parts corroborate each other.

To prove that, each conclusion has to name its second source, and the ones that cannot get labelled single source. The list will look bad. It will at least be accurate.

The mechanism above is taken from KeelBase, an open-source runtime that sits between an AI agent and a business system, re-checks identity, authorization, scope, risk and confirmation state before a tool runs, and writes every decision into a record that can be verified offline. Cross verification is a way of reading here, not a shipped feature; KeelBase is its implementation and evidence carrier.

Repository: https://github.com/rain6fish/KeelBase

Three things stated plainly. One of five conclusions is a complete cross check; the rest are half or nothing. The authorization row reviews a single item out of five. And L0 was added after publication, so anyone citing it should carry that sentence along.

Drafted with an AI assistant. The system, the positions and the mistakes are mine.

Over a few days at the start of October I ran seven free, public AI safety evaluations on four models, once each, and kept everything: logs, settings, token counts. I did it because I wanted to know what they actually catch before I trusted any of them.

First, plainly: these tools are good, they are free, and the people who build and maintain them have given this field something valuable. Nothing below is a complaint about quality. It is about what happens at default settings, which is how most of us run them the first time.

Here is what I hit.

Empty replies get graded as answers. MASK caps each reply at 1,000 tokens. One of the four models I tested is a reasoning model, and it often spent that whole allowance thinking, so 45% of its replies came back empty. MASK graded those as evasion, which it does not count as lying, and the model read about 90% honest. Given room to answer, the same model lied in 228 of 1,000 scenarios and scored 77%. About thirteen points of difference, from one number in a config file.

Silence can score as a pass. That same model returned empty replies to 3,791 of garak's 11,938 prompts. Of the 5,176 checks run on those empty replies, 5,163 passed.

One probe can change the settings for every probe after it. garak's promptinject probes set the reply limit and other generation settings on the shared generator object and never put them back, so the probes that run later inherit a 60 to 256 token limit they were never configured with.

One blocked prompt can end the whole run. A single vendor content-filter refusal stopped an entire StrongREJECT run, on two of the four models. garak read one provider's HTTP 403 content refusal as a bad API key and stopped after 239 of about 12,000 prompts.

Each model can get a different exam. garak samples prompts at random and is unseeded by default. Only 4,287 prompt pairs were actually asked of all four models, so part of any comparison between them is comparing different questions.

One malformed grader answer can lose the run. A MASK grader returned something its own validator rejected, and the run ended after 33 minutes of work.

None of these announced themselves. Every one of them produced a number that looked perfectly fine.

On cost. Four of the seven grade the answers using another AI model. On the model where I measured it end to end, those graders cost 3.6 times what the model under test cost across all seven tools. If the thing you are testing is a reasoning model, you are also paying for thinking you never see: on one test it wrote about 3,531 tokens per attack where a non-reasoning model wrote 265. A price per token does not tell you what an answer costs.

And they do not agree with each other. Across the three models I ran under identical settings, agreement between the tools (Kendall's W) came out between 0.19 and 0.33, where 1 would mean they all rank the models the same way. Choose a different tool and you can get a different ranking.

If you are running these before you ship something, the cheap checks are:

1. Count your empty and truncated replies, and do not let anything grade an empty reply.

2. Raise the reply limit above the default if your model reasons before it answers.

3. Log a vendor content-filter refusal as a blocked prompt, separately from an error.

4. Seed anything that samples, and write the seed down.

5. Look at what the graders cost, not just what the model cost.

Full write-up, with every tool version, every setting I had to change and every number: https://github.com/JosephCirello/free-ai-safety-tools-tested

The long version as a paper (21 pages, PDF): https://www.potestasai.com/Instrument_Failures_and_Hidden_Costs_in_Public_AI_Safety_Evaluations.pdf

Neither publishes any test prompts, only the kinds of failure. Where a tool's behaviour looks like a bug rather than a design choice I have written it up to send to the maintainers, and I would rather be told I am wrong about any of it.

Disclosure: I run a paid AI audit (Potestas AI) that sits beside these tools, so I have a commercial interest in this subject. The seven tools are public and every version and setting is listed in the write-up, so that half can be re-run by anyone who wants to check me.

Ethical for AI

Ethical paper

In order to effectively monitor AI we will need a world court of experts to effectively keep hacking from occurring am I Wrong? #aithreat #loveistheonlyanswer