Threat Model and Trust Boundaries

WitnessOps is built to make governed security work easier to inspect. It is not built to remove every trust assumption.

1. Problem this page solves

Proof artifacts are easy to over-read. Teams need a clear statement of what is proven, what is still assumed, and what to do when a proof claim is challenged.

2. What you should understand after reading

This page makes four things explicit:

• what WitnessOps can prove
• what WitnessOps cannot prove
• which trust assumptions still sit outside the proof system
• how to handle verification failures or disputed proof claims

Three authority domains

The simplest way to read WitnessOps is to separate three authority domains:

These domains are related, but they are not the same thing. Execution does not make a claim true just because something ran. Issuance does not make a claim trustworthy just because it was signed. Verification does not make the underlying operational judgment correct just because the proof package is intact.

What WitnessOps can prove

When the runtime and the surrounding proof material behave as designed, WitnessOps can prove narrower things than a marketing page might imply, but stronger things than a normal dashboard can support.

WitnessOps can prove:

• a governed action, denial, or terminal result was recorded by the system
• the recorded statement was bound to a signed receipt or receipt-bearing artifact
• the receipt occupies a specific place in a continuity structure
• declared artifact hashes, signatures, and digest relationships verify when the verifier returns valid
• declared witness or trust-policy conditions passed when they are present and the verifier does not return indeterminate

That is a strong proof claim. It is not the same as proving that the underlying tool was correct or that the operator made the right decision.

What WitnessOps cannot prove

WitnessOps cannot, by itself, prove:

• that the workstation or host was uncompromised
• that the wrapped tools behaved correctly
• that the selected target or scope was appropriate
• that the caller-supplied operator identity was true in an absolute sense
• that a partial bundle represents the whole operational story
• that a valid receipt implies a valid security conclusion

The key distinction is simple: WitnessOps proves governed issuance, continuity, and proof integrity. It does not prove everything.

Explicit trust assumptions

The current trust model still depends on assumptions that sit outside the receipt itself.

If any of these assumptions fail, proof may still exist, but the meaning of that proof changes.

Runtime failures vs proof failures

The most useful way to read the system is to separate runtime control failures from proof-layer failures.

Runtime control failures

These happen during governed execution:

• Policy denial: the requested target or action is out of scope or disallowed
• Approval pending: an intrusive step is paused until an approver acts
• Tool failure: the wrapped tool exits unsuccessfully or returns unusable output
• Evidence capture failure: the runtime cannot produce the artifact set it expected to bind

These are operational failures. They do not mean the proof system is lying. They mean the governed operation did not complete cleanly.

Proof failures

These happen during verification of the resulting receipt, bundle, or receipt-bearing artifacts.

The public /verify API first classifies malformed or unsupported input:

• FAILURE_INPUT_MALFORMED
• FAILURE_INPUT_UNSUPPORTED

When a supported receipt is accepted for verification, proof-bearing checks expose breach codes such as:

• SCHEMA_MISSING_FIELD
• DIGEST_RECORD_NOT_IN_SET
• ATTESTATION_SIGNATURE_INVALID
• ANCHOR_RFC3161_IMPRINT_MISMATCH
• WITNESS_SUBJECT_MISMATCH
• WITNESS_UNTRUSTED

These are proof failures. They indicate malformed receipt structure, broken digest relationships, invalid signatures, or unsatisfied trust conditions. Report them by layer instead of collapsing them into one generic failure.

Indeterminate trust outcomes

Not every incomplete verification result is a hard failure. The verifier can return indeterminate when a package is structurally coherent but a declared outside trust dependency cannot be satisfied locally.

That distinction matters. Missing trust context is different from proven tampering.

What a bypass looks like

Suppose an operator wants to run a step against a target that is currently out of scope.

The runtime gate blocks it. The operator then changes the configured scope source before rerunning the step. The gate now passes.

WitnessOps did not make the scope source immutable. It was not designed to. What WitnessOps can still do is record:

• which governed action was run
• under which scope context it was evaluated
• when it happened
• how that action fits into the receipt chain

The control here is auditability and continuity, not magical prevention.

Partial bundle risk

A partial bundle can still produce a valid verification result for the artifacts it actually contains.

That does not mean it proves completeness of the operational record. A verifier may be able to confirm that a presented subset is internally intact while still being unable to conclude that the subset represents the whole engagement, chain, or decision path.

This is why continuity inspection and honest packaging matter alongside cryptographic validity.

What verification should mean

Verification should be read precisely.

• valid means the declared checks for the selected verification mode passed
• invalid means a proof-bearing check failed
• indeterminate means the package may be coherent, but a declared outside trust condition could not be completed locally

On the public /verify surface, valid is receipt-scoped. It does not prove bundle completeness, artifact-byte revalidation, or full operational truth.

These statuses are more useful than a generic green or red badge because they tell the reviewer what kind of dispute they are actually dealing with.

Verification and dispute handling

If a receipt, chain, or bundle is disputed, the right move is not to debate screenshots. Preserve the artifacts and work from the proof surface outward.

1. Preserve the original receipt or bundle bytes exactly as received.
2. Re-run Verification locally and record the exact status and failure class.
3. If the issue is continuity-related, inspect Execution Chains and manifest integrity before making broader claims.
4. If the issue suggests issuer compromise, receipt forgery, or tamper without an obvious packaging explanation, escalate through Security Practices and the public Support Policy.

The important point is to distinguish three dispute types:

• an operational disagreement about what should have been done
• a proof disagreement about what can be verified
• a security incident involving possible forgery, compromise, or manipulated trust material

Those are not the same kind of problem and should not be handled as if they were.

8. Next-page handoff

Next, read Authorization Model for the approval and authority boundaries that sit above this threat model.

Then use these as needed:

• Verification for the check procedure
• Receipt Specification for the technical receipt contract
• Security Practices for disclosure and operational security posture