DigiBridge Labs: testing the systems that protect human creation

An AI verification agent can help connect observations and explain why activity needs attention. A confident explanation is still not a substitute for the observations themselves. Our direction is to make each finding traceable to permitted evidence, the relevant rule and the limits of what was recorded.

NIST’s Generative AI Profile warns that testing under laboratory conditions or narrow benchmarks may not reflect real use. For creative verification, the implication is practical: evaluate the actual workflow. An editing session, a long render and a collaboration handover need different expectations, even within the same production.

The research agenda includes attempts to misrepresent recorded activity, reuse an old record, attach evidence to the wrong version or influence an AI reviewer. These are different failure cases. Testing should identify which control is expected to stop each one and what remains uncertain if that control cannot decide.

MITRE ATLAS provides a public knowledge base of attacks involving AI systems. OWASP identifies prompt injection as a risk when supplied information changes a model’s behaviour. These resources inform useful questions for DigiBridge: can review material be mistaken for an instruction, can a model exceed its role, and can an explanation conceal missing evidence?

The design principle is straightforward. A model should analyse only its permitted evidence and return a bounded finding. It should not change the source record, grant itself access or impose a programme penalty. Independent access and publication rules must hold even when an AI response is wrong.

Finding attempted abuse is only part of the task. We also need to understand when ordinary work is flagged incorrectly. The Labs agenda prioritises comparison between permitted creative actions, prohibited software control and activity for which the evidence is incomplete.

Useful evaluation should report the tool, workflow and conditions tested. It should count incorrect warnings and missed cases, explain coverage gaps, and test whether a result still holds when the software or operating system changes. One headline accuracy figure cannot describe every creator’s working day.

Production specialists can explain why a workflow looks unusual. Security researchers can challenge the controls. Data scientists can test whether a pattern holds beyond the examples used to design it. Bringing those perspectives together is the collaboration we want Labs to support.

DigiBridge’s evidence boundary excludes source footage, creative project files and typed content. The research direction starts with isolated test projects and controlled examples, with a clear purpose for any additional data. Permission to record a session does not automatically give permission to train a model or reuse private evidence for research.

The same care applies to vulnerability testing. Tests should have an agreed scope and a route for responsible reporting, using accounts and records created for that purpose. CISA’s vulnerability disclosure guidance illustrates why clear reporting and coordination matter. A useful research programme gives specialists a defined way to contribute while protecting the people and systems outside the agreed test.

Our goal is to give creators evidence they can stand behind and reviewers a defensible basis for their decisions. Under the human creation programme, the first confirmed incident holds the affected recording or version. Three distinct confirmed incidents make the project ineligible for directory publication. A warning, gap or uncertain AI result alone is not an incident.

Labs sets the direction for improving the methods behind that standard. It is an invitation to discuss research, production knowledge and carefully scoped testing. Findings deserve published methods and clear limits before they become broad claims about what a system can detect.