One image, five models: what an auditor would ask about image-blaster
image-blaster is a free, open-source tool that turns a single photo into a 3D scene in minutes. It’s well made, and someone on your team could be running it this afternoon. That’s what makes it a useful test of your AI governance.
What the tool does
You put an image in a folder and ask Claude to “blast it”. It chains five generative models behind two API keys, one for World Labs and one for FAL:
- 01
Clean up the source
The image is edited to remove objects and produce clean plates and reference images for each object.
nano-banana (default) · gpt-image-2 (alternate) - 02
Build the environment
The cleaned image becomes an explorable Gaussian splat of the static scene.
World Labs marble-1.1 → .spz - 03
Model the objects
Each moving object becomes a textured 3D mesh.
hunyuan-3d via FAL → .glb / .obj - 04
Add sound
An ambient loop plus sound effects for each object.
elevenlabs-sfx → .mp3
The README suggests use cases like game levels, architectural renders, location scouting and “your childhood bedroom”. All reasonable. None of them say anything about what the image contains.
Seven questions an auditor would ask
None of these are about whether the tool is good. They’re about whether you can show you’re in control of it. Each maps to a part of ISO/IEC 42001.
Where does the image go?
Annex A.7 · A.10One photo leaves your machine for at least two providers, and through them to the companies behind each model. If it shows a client site, a floor plan or a person, that is data processing you need to be able to describe.
What is hidden in the file?
Annex A.7 · Clause 6.1.4A phone photo carries EXIF metadata: often GPS coordinates to a few metres, the date and time, and the device. I checked the code: image-blaster sends every image to the external APIs as the original file bytes, unchanged. Whatever metadata is in the file goes with it. A picture of a child in their bedroom then becomes a picture of a child with their home address attached, sent to several third parties. That is the case to plan for, not the edge case. Strip metadata before any image leaves the building, and record that you do.
Who are your AI suppliers?
Annex A.10Two API keys hide five models from at least four developers. Your supplier register should list who actually processes the data, not just who sends the invoice.
What are you allowed to do with the output?
Clause 6.1 · A.10The MIT licence covers the code. It says nothing about the meshes, scenes and audio it produces. Rights in those come from each provider’s terms, and they can differ.
Who signs off each step?
Annex A.9The README suggests asking Claude to “confirm each step with me”. That is good practice, but it is an instruction, not a control. An auditor will want to see who approved what, and where that is recorded.
What if the image shows a person?
Clause 6.1.4 · A.5Turning a real room or a real face into a reusable 3D asset has consequences for the people in it. That calls for an impact assessment before use, not after.
Who holds the keys and the spend?
Annex A.4API keys stored in a local config file on someone’s laptop are a resource you’re responsible for. Who can use them, what they cost each month, and how you’d revoke them when that person leaves.
Bringing it inside your management system
If your team finds the tool useful, the answer isn’t to ban it. It’s to give it the same four steps as any other AI system you rely on.
Name the tool, an owner, the purpose and every model it calls.
Check each provider’s data and output terms. Decide which images are out of bounds.
A short acceptable-use note: allowed inputs, metadata stripped before upload, who approves, where outputs live.
Log approvals and keep the assessment on file. That’s what Stage 1 asks to see.
The tool isn’t the risk. Not knowing it’s in use is.
I’m not saying don’t use image-blaster. It’s a great piece of work and the author has been very open about how it’s built. I’m also not giving legal advice on output licensing; that sits with each provider’s terms and your own counsel. The point is narrower: a tool this easy to adopt is exactly the kind your AI register should already know about. The thing is, powerful, desirable tools are now so easy to adopt and use.
Try it on your own tools
Pick one AI tool your team used last month and run the seven questions against it. If you can answer all seven with a document rather than a shrug, you’re further along than most. If you can’t, we can fix that before an auditor asks.
