Preview: Quoderat is in early access. This site shows the concept and direction — onboarding is manual for now.
Quoderat

Policies

Policies control what data is visible and how sensitive content is handled. They define the boundary between internal evidence and public-safe exports.

The Core Principle: Deny-by-Default

Quoderat operates on a deny-by-default visibility model. Policies determine how raw execution data is transformed into a shareable record. Every field is treated as internal unless explicitly allowlisted.

Two Views of the Evidence

Internal Envelope

The authoritative, full-fidelity record. It retains all audit details, raw logs, and unmasked observations for internal compliance and forensic review.

Public Pack

A filtered derivative of the Internal Envelope. Generated by applying visibility gates and redaction rules, making it safer for external stakeholders or public verification.

Note: A public pack can carry its own integrity metadata as a derived record. It may include a reference to the parent evidence_id. The internal envelope remains the authoritative source.

Redaction Receipts

Quoderat does not simply “erase” data; it records the act of redaction. When a policy rule masks a string or a file path, a receipt is generated in the envelope.

Mechanical Proof

The redactions[] array serves as a log of which rules were applied and where.

No Absolute Claims

A redaction log is proof of intervention, not a guarantee that no other secrets exist.

Example: Redaction Entry

{
  "redactions": [
    {
      "rule_id": "mask-api-keys",
      "path": "execution.steps[2].stdout",
      "match_type": "regex",
      "match_count": 1,
      "masked_len": 32,
      "timestamp": "2026-01-27T10:05:00Z"
    }
  ]
}

Illustrative only. The entry records where a rule was applied, not the secret itself.

Visibility Gates: Fields and Artifacts

  • public_allowlist_fields: A strict list of JSON paths allowed in the public view.
  • Artifact Filtering: Rules based on kind or filename patterns determine if a raw file is included or stripped.
  • Path-based Filtering: Advanced rules allow/deny data based on repo structure or toolchain origin.

Observation Publishing: Verifiable vs. Informational

Require Basis Links

If enabled, an observation can only be published to a Public Pack if its basis_artifact_ids are also present.

Hard Rule

If an observation has no basis_artifact_ids in the public pack, treat it as informational only—not verifiable evidence.

Recommended defaults

Pilot Default

  • • Allow: subject.id, execution.steps[*].status, observations[*].summary
  • • Redact: tokens, API keys, passwords
  • • Artifact filter: allow junit_xml, sarif_json
  • • Observation policy: basis links optional

Enterprise Default

  • • Allow: minimal fields only (subject.id, integrity.hash_chain)
  • • Redact: all secret categories + env var values + DSNs
  • • Artifact filter: deny *.env, config.json
  • • Observation policy: require_basis_links: true

Policy Configuration (Illustrative)

Example Policy Snippet (YAML)

id: enterprise-default-v2
public_allowlist_fields:
  - subject.id
  - execution.steps[*].status
  - observations[*].summary
redaction_rules:
  - id: mask-tokens
    type: regex
    pattern: "ey[A-Za-z0-9-_=]+\.[A-Za-z0-9-_=]+\.?[A-Za-z0-9-_.+/=]*"
artifact_filters:
  allow_kinds: ["junit_xml", "sarif_json"]
  deny_filenames: ["*.env", "config.json"]
observation_policy:
  require_basis_links: true

Adapt to your organization's requirements. Field names and structure may vary by implementation.

Operational Workflow

  • Version Management: Policies are managed like code. Changes should be reviewed and dated.
  • Effective Dating: A run is governed by the policy active at the start of the execution.
  • Snapshotting: The policy_hash can be embedded in the integrity block to record which policy version was applied.

Common Pitfalls

Broad Allowlists

Exposing too many fields defeats deny-by-default. Start minimal, expand cautiously.

Marketing Exports

Sharing “passing” receipts externally without reviewing artifact content can leak internal details.

Redaction Misinterpretation

A redaction log is proof of intervention, not proof that no secrets remain. Unknown patterns can slip through.

External Sharing Checklist

  • Review public_allowlist_fields: only intended fields are exposed.
  • Confirm artifact_filters deny sensitive file types by default.
  • Ensure redaction_rules cover known secret patterns.
  • Verify redactions[] receipts appear for expected matches.
  • No observations without basis_artifact_ids in the public pack (or treat as informational/strip).
  • Prefer commit_sha as immutable anchor; MR IID is metadata, not identity.
  • Test the public pack in a staging environment before external distribution.

What you can claim (and what to avoid)

✓
Allowed Claims (Recorded)

  • • “This receipt records Policy ID X.”
  • • “These fields were redacted by Rule Y.”
  • • “These evidence types are present/missing.”
  • • “The public pack is a derived record with its own integrity metadata.”

✗
Claims to Avoid (Absolute)

  • • “No secrets existed or leaked during this run.”
  • • “Policy enforcement guarantees security.”
  • • “The public pack is cryptographically checkable against the original seal.”
  • • “Sandbox/network isolation is guaranteed.”

Next steps