Trace Policy Provenance
Every sandbox APF admits carries the identity of the policy it was admitted under. This page follows that identity from the sandbox back to the signed bundle, verifying each link, so you can answer which policy governs a sandbox and who authorized it.
The Chain of Evidence
Read the Sandbox Annotations
Note the values of apf.nvidia.com/correlation-id, apf.nvidia.com/document-digest, apf.nvidia.com/policy-version, apf.nvidia.com/bundle-id, apf.nvidia.com/signer-identity, and apf.nvidia.com/provenance-token.
Verify the Provenance Token
The token is a compact JWT signed with EdDSA by the policy service’s document signing key. The key is published at /.well-known/jwks.json on the policy service’s HTTP surface, under the token’s kid. This script verifies the signature and prints the claims. It uses the Python cryptography package.
The script raises InvalidSignature if the token was altered. On success, check that the claims match the annotations:
Before OpenShell admits the sandbox, the interceptor verifies the token’s signature and expiry, checks the jti and apf/document-digest claims against the annotations, and recomputes the sandbox policy spec digest. It does not compare sub, apf/version, or apf/bundle-id, so those checks are yours. apf/bundle-id names the bundle the policy service loaded at startup, even after a later refresh.
Find the Admission Records
The token’s jti is the correlation ID of the admission:
The policy_injection record lists the spec paths APF patched, and the admission_validation record’s reason code shows whether the spec digest check ran.
Find the Bundle Verification
Search the policy service’s audit file for the bundle and revision named in the token:
A record with "outcome":"success" shows the policy service verified that revision. Its bundle_digest is the SHA-256 of the signed bundle file. If the policy service loaded a bundle with a different id after it started, the token still carries the startup id, so filter on the revision alone.
What Provenance Does Not Prove
- The provenance token attests to the policy, not to the caller. The sandbox ID and caller subject come from OpenShell’s request.
- The token’s signer is the policy service’s document key, not the bundle signing authority. The bundle signature links the two.
- Without a document TTL, tokens do not expire. A token proves which policy a sandbox was admitted under, not that the policy is still current. Compare
apf.nvidia.com/policy-versionwith the active revision to find sandboxes running older policy.
Next Steps
- To trace a decision rather than an admission, refer to Investigate a Denied Request.
- To review the keys involved, refer to Signing Keys and Trust Roots.