Add bounded pre-commit enforcement example to OntoGuard Decision Authorization

[MMM777-ai]

Summary

Updates the existing Verified OntoGuard Decision Authorization integration
with the bounded pre-commit enforcement example discussed with Imran.

The example demonstrates:

• the same permitted capability with different proposed actions producing
  ALLOW, BLOCK, or ESCALATE;
• exact-action binding of the signed OntoGuard decision;
• rejection of a materially changed action;
• fail-closed bypass cases, including missing authorization, digest-only
  input, invalid/tampered authorization, BLOCK, ESCALATE, and an ALLOW
  issued for a different action;
• no protected commit for denied or bypass cases.

The existing TRACE adapter semantics remain unchanged. OntoGuard core
decision logic is not included.

Reproduction

From:

integrations/ontoguard-decision-authorization/

Run:

python -m pip install -e ".[test]"
python -m pytest -q

[MMM777-ai]

Hi Imran — I’ve submitted the bounded update we discussed.

It stays within the existing Verified OntoGuard integration and keeps OpenShell/TRACE changes and NVIDIA positioning outside the contribution.

The PR now demonstrates:

• same permitted capability with ALLOW / BLOCK / ESCALATE driven by the proposed action;
• exact signed decision-to-action binding;
• changed-action rejection;
• explicit bypass/fail-closed cases with no protected commit;
• documented proof boundaries and limitations.

The current suite is 33/33 passing, and the controlled-execution proof returns PASS.

Would appreciate your review when you have a chance.

Thanks,

Mark

[carloshvp]

Reviewed exact head cb50ed3 against released agentrust-trace 0.11.0. The 33 integration tests pass, as do manifest validation (41 integrations, zero failures), compatibility, generated index/catalog checks, diff checks and a clean merge simulation.

Independent boundary probes found that malformed cross_border values are accepted as the signed Boolean true action and reach EXECUTED/commit_count=1. A separate direct ControlledExecutor.attempt() call also commits with only a caller-computed digest and no signed authorization. The inline comments distinguish the action-validation defect from the overbroad bounded non-bypassability claim. Please validate the action before binding/execution and either enforce authorization at the commit boundary or narrow the wrapper's proof claims and document the trusted routing assumption. Requesting changes.

[carloshvp]

[P2] Validate action field types before relying on this digest

partner_action_binding_digest() canonicalizes cross_border with bool(value), but this gate forwards the original proposed_action to the executor. With a valid signed ALLOW for ACTION_ALLOW_250K (cross_border=True), replacing just cross_border with the string "false" still produces the authorized digest, and attempt_protected() returns EXECUTED with commit_count=1. The same occurs for 1, ['false'], and a nonempty object. The malformed raw action is therefore accepted despite the exact-action claim. Validate the partner action schema at this boundary, including requiring an actual Boolean for cross_border, and pass the same validated representation through binding and execution. Add negative cases for these malformed values that assert no protected commit.

[carloshvp]

[P2] Bound the single-entry-point and digest-only claims to what is enforced

The wrapper rejects minted=None and a digest-only minted object, but the same bounded harness still exposes ControlledExecutor.attempt(proposed, authorized_digest), which forms the protected effect without verifying any authorization. After the wrapper refuses ACTION_BLOCK_260K with no authorization, calling executor.attempt(ACTION_BLOCK_260K, partner_action_binding_digest(ACTION_BLOCK_260K)) returns EXECUTED and sets commit_count=1. The existing test exercises only the wrapper, so it does not establish the stated single protected entry point or bounded harness non-bypassability. Either place the verification requirement at the harness commit boundary and test this direct bypass, or explicitly narrow the docstring/README to wrapper behavior and state that a trusted runtime must prevent access to the raw digest-only executor. This is about the public harness's bounded claim, not a request to prove production network topology.

[MMM777-ai]

Thanks Carlos — both findings were valid and are addressed in the latest commit.
The bounded example now strictly validates the proposed action before binding or execution, including requiring cross_border to be an actual Boolean and using the same validated representation through the commit path.
Signed authorization verification is now enforced at the controlled executor’s commit boundary, so a caller-computed digest alone cannot form the protected effect.
I added regression coverage for the malformed cross_border cases you identified and for the direct digest-only bypass. Current result: 36 tests passing, controlled proof PASS, and all boundary probes refuse execution with commit_count == 0.
The limitation remains explicit: this proves the bounded software harness, not production-wide network non-bypassability.
Thanks for catching both issues.

[imran-siddique]

@MMM777-ai #240 changed files in controlled-execution-proof-2026-09-17/ on main, so checksums.sha256 now conflicts. Merge main in and regenerate that file from the merged tree rather than hand-merging the two versions. @carloshvp e941cca reports both of your findings addressed (strict Boolean validation of cross_border before binding, signed authorization checked at the commit boundary); please re-review once the merge is pushed.

[MMM777-ai]

Done - I merged the latest main into #236 and regenerated checksums.sha256 from the merged proof tree rather than hand-merging the manifests. The OntoGuard suite passes 36/36, the controlled proof passes, and the repo Ruff gate passes locally. Ready for re-review.