Supported startup for a native metadata collector under restrictive sandboxing

I’m reviewing a macOS metadata collector using synthetic fixtures only. Before implementing a replacement, I need clarification on supported startup behaviour.

The intended boundary permits bounded metadata queries on explicitly approved objects while independently denying directory enumeration, file-content reads, writes and network access. These restrictions must apply during native runtime startup as well as collection.

In existing synthetic testing, a native metadata helper and a minimal control both failed before reaching their entry markers under restrictive sandbox profiles. The recorded termination description was:

failed to open root directory: /: 1

The exact open flags and calling frame were not established.

Is there a supported public launch or runtime mechanism that permits the necessary startup operation while independently denying root-directory enumeration and prohibited file access?

Specifically:

Can this be achieved without initializing the helper outside the required boundary or granting broader root-directory read access?

Which public APIs, runtime contracts and released macOS versions support it?

What entitlements or permission changes, if any, would be prerequisites?

How could the guarantee be verified using synthetic fixtures without enumerating the real root or reading protected contents?

I’m seeking a documented mechanism or clarification of the specific unsupported requirement. Successful startup alone, source-level avoidance of directory listing, and private loader interfaces would not establish the required boundary.

This is a documentation and architecture question. No real credentials, backups or customer data are involved. Any capability changes would require separate review.