Purpose-Bound AI Execution Profile (PBAE)

An organization approves a model to use fields A, B and C for hardship support. The runtime that carries out that approval may, in practice, send fields A, B, C and D, silently switch providers, call a tool nobody declared, or release an output nobody reviewed. The governance register still says the workflow was approved.

The Purpose-Bound AI Execution Profile (PBAE) is a proposal for closing that gap. It ties an approved purpose to what a specific execution did, in a form that a separate system can check.

In a controlled evaluation of 26 attack families, 69.2% succeeded silently against both a conventional and a hardened baseline. Against the PBAE runtime, 7.7% did, with a 0.0% false-positive rate. Two attack families still get through unnoticed, and this article explains why.

The work comes from the Compex Research Project, and all results so far are same-team. PBAE is an open specification proposal, not a standard, and it claims no compliance. Compex is one reference implementation, and the profile does not require it. These are drafts for external review, with results frozen at Gate 14b on 2026-08-14.

None of these technologies is deficient. Each one was built to answer its own question:

• Governance frameworks: what did the organization decide?
• Policy engines: should this request be allowed?
• Observability: what activity was observed?
• Provenance: how was this artifact built?
• Attestation: what environment executed this?
• Confidential computing: was execution protected?

None of them answers whether the executed workload stayed within its approved purpose, or whether another implementation can check that from portable evidence. PBAE sits around those layers and reuses them. Policy decisions stay with the policy engine, and attestation terms are carried rather than redefined.

PBAE has three parts. The execution contract states what one execution is authorized to do: its purpose, approval, data, the exact view of that data the model may see, model and provider route, tools, privacy settings and output policy. The runtime enforces the contract and records what it observed. The evidence bundle is the signed, integrity-protected record of that run.

The bundle holds digests (cryptographic fingerprints of the data), decisions and events. It never holds plaintext inputs, outputs, secrets, model weights or personal data, so the evidence does not have to contain the confidential material itself.

PBAE defines four assurance levels. PBAE-0 (Declared) means a valid machine-readable contract exists, with no runtime guarantees. PBAE-1 (Enforced) means the runtime enforces the registered controls and emits a bundle. PBAE-2 (Verified) means a separately implemented verifier validates the evidence. PBAE-3 (Attested) adds hardware-rooted attestation of runtime identity, and it has not been evaluated.

One boundary matters more than the others. Being able to verify that a bundle has not changed is different from proving the runtime honestly observed reality. PBAE-2 provides the first independently. At PBAE-1 and PBAE-2, the second still rests on trusting the system that produced the evidence.

What a stopped attack looks like

A contract for hardship routing allows claim_id, hardship_flag and amount_bucket, and prohibits market_signal. A request tries to widen the data view to include market_signal. The runtime rejects the widened field set while building the view and refuses to run. No model call takes place, yet the bundle still records the denied attempt with a reason code, and the verifier returns FAIL. The attempt stays visible even though nothing happened.

The attack benchmark covers 26 registered attack families across purpose and approval, data, workload and route, capabilities and network, output, privacy, and evidence itself. Each family ran 5 times. Those repeats test stability, so they are not 130 independent attacks.

Three systems faced the same attacks: S0, a conventional application with plain logs; S1, a hardened version with deterministic data views, pinned model and route, output validation and structured chained logs; and S2, the PBAE runtime. All of it ran on a single node with a deterministic controlled provider and a fixed clock.

The headline measure is the silent policy compromise rate: the share of attack families whose violation took effect without the record revealing it. Silence is the measure because detection triggers a response, and silence does not.

S0 prevented no families, detected 8 and failed silently on 18. Against the PBAE runtime, only 2 of the 26 succeeded silently. The other 24 were prevented or detected, and none of the benign executions was wrongly blocked.

Hardening alone did not move the number

S1 and S0 scored the same 69.2%, which looks suspicious, so the paper gives the full account. S1 is no strawman: it prevented 5 families outright. But three other families moved the wrong way, from detected to silent. S1 silently drops an injected field and does not log tool or network calls, so those attempts left no trace, where S0’s plain logs had happened to expose them. The silent count stayed at 18.

Hardening a system can reduce what it reveals after the fact. That is the argument for treating evidence as its own design goal.

Decision-content modification and event reordering both remain silent when the attacker can re-sign with a valid key. An attacker edits a recorded decision or reorders events, signs the result, and the bundle stays internally valid. The cause is specific: the current verifier trusts the digests declared in the evidence chain instead of recomputing the binding from the recorded decisions.

A fix is registered for v0.3. It was deliberately not applied to the frozen evaluation, and no v0.3 results are reported, so the gap should be read as open.

An automated checker tried to reconstruct 10 governance facts from each record, such as purpose, model, route, approval and release decision. Logs gave 0.40 coverage, for S0 and S1 alike. Bundles gave 0.70.

Bundles fell short of 1.00 for reasons built into the study: the privacy fact needs a run with privacy accounting, and this one had none, while violations and tampering do not appear in a benign run. Those two are covered by the attack study instead.

After-the-fact tampering told a similar story. Logs caught 0 of 4 cases. Bundles caught 2 of 4, event deletion and signature mutation. The two they missed are the decision modification and reordering gap described above.

A specification only matters if different implementations read it the same way. Three separately implemented producers, including a Python runtime built from the specification alone, each created signed bundles. Two verifiers sharing no code, one in TypeScript and one in Python, accepted all of them (6 of 6) and agreed on all 56 conformance fixtures.

Getting there exposed three real defects: whether a number is rendered as 1.0 or 1, how Unicode characters are escaped, and how absent fields are handled. Any of these can make two valid implementations disagree. Each was fixed in the specification. The same contract semantics also ran through both OPA (10 of 10 decisions) and Cedar (6 of 6 decisions) adapters, so PBAE does not depend on one policy language. The same team built all of these, so this is cross-implementation verification and not external replication.

Governance-path processing took a median of 2.45 ms (p95 4.61 ms) on the reference runtime, with a 500-row dataset and 200 runs per stage. A bundle came to 5288 bytes. Model inference is excluded by design.

This is a processing measurement, not overhead. Incremental overhead needs a same-benchmark baseline, which is future work, and no production-scale claim is made.

PBAE is meant to be implemented by others, including competitors. That is what makes it an interoperability profile, and it is also what has not been shown yet. The next steps are external review, external implementations, and published conformance results.

• All results are same-team. External implementations are future work, and there has been no independent security audit.
• Two of 26 attack families still succeed silently: decision-content modification and event reordering under valid re-signing.
• At PBAE-1 and PBAE-2, the bundle is only as truthful as the system that observed the run.
• PBAE-3 was not evaluated, and the TEE backend exists at specification level only.
• The attack suite is bounded and ran on a single node with a deterministic controlled provider. The 5 repetitions test stability; they are not 130 independent attacks. Evidence reconstruction was automated, not human.
• It cannot show that a declared purpose was truthful or that an approver acted in good faith.
• It records what was transmitted. It does not defeat statistical correlation between a prohibited field and an allowed one.
• No universal runtime security, resistance to arbitrary host compromise, legal compliance or model correctness is claimed, and no superiority over every modern runtime-governance stack.

• Executive brief (Draft 0.2), for decision-makers, 4 pages
• White paper (Discussion Draft 0.3), for practitioners, 18 pages
• Systems paper (Revision 0.1), for implementers, reviewers, 10 pages

Copies are available on request from [email protected].

Compex Research Project. Purpose-Bound Runtime Conformity for AI: Contracts, Execution Evidence, and Verifiable Enforcement. External-review draft, Revision 0.1, 2026. https://getcompex.com/research/pbae

This is a draft for external review. Send corrections and comments to [email protected].