How can a script reliably identify an encrypted disk image and its mounted volume?

This mounted volume actually belongs to the intended disk image.

If these are your own images, you can create your own hidden files with reliable, unique identifiers.

What supported macOS API or command should a script use to establish this relationship reliably?

There are a number of APIs that may prove useful:

1. Disk Arbitrarion
2. URL resource values
3. statfs
4. Maybe IOKit

From what you're describing, #1 and #2 should be sufficient.

Can we rely on specific fields from hdiutil info -plist and diskutil info -plist <device>? If so, where are their meanings and limitations documented?

hdiutil is deprecated, so there's that. While diskutil does have a machine-readable "-plist" option, the details of what those values mean is often not well documented. Plus it's an external tool you'd have to run. Disk Arbitration would be preferable. I sometimes use these tools, and "system_profiler", but normally that's to poke around in Apple's business. If these are disk images that your software is creating, you have much more liberty to just create your own metadata for them.

One important limitation is that a mount path, volume name, or BSD device name should not be treated as a durable identity. Device names can be reused after detach, and the path can be remounted. If you create the sparsebundle, put a random identifier in metadata inside it and compare that after the user mounts it. For an image you do not control, use Disk Arbitration to inspect the current disk and volume descriptions, correlate the mounted volume with the attached image, and treat missing or conflicting fields as unknown. I would not make a safety decision from a parsed display name alone.

For the read-only checks, collect the mounted volume URL and its volume UUID, read-only state, and ownership state, then verify those values again immediately before copying. A check followed by a later path-based copy still has a race. Where possible, open the destination directory once, retain its file descriptor, and perform traversal relative to that descriptor with no-follow checks, verifying the volume identity again if the mount can change. If the identity or ownership state cannot be established, fail closed and do not copy. The exact fields available vary by filesystem and OS version, so I would validate the behavior on the macOS versions and image types you support rather than assuming hdiutil or diskutil output is a stable API contract.

What sort of script are we talking about here?

This matters because some scripting languages give you ready access to native APIs and some don’t, and the best answer for at least some of question question involves native APIs.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello Quinn,
Thank you for taking the time to help and for asking for clarification. I appreciate your support.
The automation is written in Python. So far, the approach has been to call macOS command-line tools and interpret their output. However, I would prefer to use supported native APIs where these provide a more reliable answer.
Would a small Swift command-line helper, called by Python, be an appropriate approach? The helper could use Disk Arbitration and Foundation URL resource values, then return a small structured result to Python.
For example, after the user manually unlocks an encrypted sparsebundle, the helper would check:

• Whether the mounted destination belongs to the intended disk image.
• Whether it is mounted read/write and ownership is enforced.
• Whether its identity is still consistent immediately before copying.
  The checks should be read-only. They should not unlock or mount images, change permissions, or alter security settings. Missing or conflicting information should produce an “unknown” result, and Python would stop rather than copy.
  Would you recommend this Python-plus-Swift arrangement? If so, which APIs would you suggest for establishing the image-to-volume relationship and reducing the risk of the destination changing between checking and copying?
  Thank you again for your guidance.

The automation is written in Python

You asked for an API, in the Apple Developer forum. So I answered.

However, those APIs really aren't suitable for Python. Maybe Python can call native methods. I really don't know. But that's a side issue.

My question to you is how would you implement this Python solution on a Linux system? What parts of that do you find missing on macOS? So far, you haven't given any indication of any blocker. I don't see any reason why you couldn't write the script on Linux, with minor changes for macOS to create and mount Mac disk images. I don't see any requirement for any kind of low-level, APFS/macOS-specific access to filesystem, device, or disk image details. Just create some hidden directories with some UUIDs and off you go.

If you've got a malicious user somehow making byte-for-byte copies to confuse your app, tell your users not to do that.