Security Systems

Security Practices

How WitnessOps protects its own operations, handles vulnerabilities, and manages trust.

This page explains the current security posture for WitnessOps operations: which controls are active, what evidence they emit, and where the limits still are.

1. Problem this page solves

Security claims become misleading when current controls, target-state goals, and trust assumptions are mixed together.

This page separates those layers so readers can judge the present posture without overstating maturity.

2. What you should understand after reading

After this page, you should understand:

  • which controls are currently enforced
  • what evidence those controls emit
  • which threat and failure classes remain outside protection
  • where current state differs from target state

3. Mechanism-first security posture

Active controls

ControlCurrent behaviorEvidence surface
Governed execution boundaryTools run only through an authorized runbook pathrunbook state + gate records
Artifact integrityOutputs are hashed at generation and bound to manifestsartifact hashes + manifest checks
Tier 1 receipt linkageM0 -> E0 -> P1 -> E2 -> R0 -> V0 binding is explicit and replayablereceipt chain + local recomputation
Append-only execution stateStep history appends over timestate continuity inspection

Current vs target capabilities

CapabilityCurrentTarget
Signing algorithmEd25519Ed25519
Key storagelocal filesystemHSM/secure enclave
Key rotationmanualautomated policy-driven
Key revocationnot supportedrevocation list + timestamp
Approval modelself-approval only when explicit workflow policy permits scoped low-risk actionsmulti-party separation of duties
Tool integrity checkingnot verifiedwrapper hash verification pre-run
Audit log posturelocal state filesindependent append-only witness log

4. Observed vs inferred

LayerWhat is observedWhat is inferred
Observeddocumented controls, explicit gaps, emitted evidence artifactsnone beyond stated controls
Inferredrisk reduction under current posturedepends on deployment discipline and outside policy context

5. Trust assumptions and limits

Current posture does not independently eliminate these risks:

  • compromised operator workstation or host
  • malicious or tampered tool wrappers
  • network-level data tampering before capture
  • collusion or weak separation of duties
  • key compromise or loss without revocation support

These are explicit boundary conditions, not hidden exceptions. These controls improve integrity and reviewability, but they do not make compromise, collusion, or tool deception impossible.

6. Disclosure path

Report vulnerabilities to security@witnessops.com.

Do not send passwords, private keys, API keys, recovery codes, session tokens, or other secrets.

security+witnessops@witnessops.com may be used as an optional alias when enabled, but it does not replace the canonical disclosure identity.

7. Next-page handoff

Next, read Governance to map this security posture into approval, authorization, and audit boundaries.

Security Practices | WitnessOps