Controls and how they are checked

The gate evaluates policy/rego/*.rego against one document, gate-input.json, which has three kinds of input:

config (from mapping.yaml → gate), waivers[] and now are also recorded in the input, so replaying a decision later gives the same answer. artifacts.trivy_db records which vulnerability DB (its update time) the findings came from.

Which controls apply to which event

Semgrep rules

• No live fetching: the gate never downloads rules at scan time. Registry rulesets are copied into policy/semgrep/registry/ by scripts/vendor-semgrep-rules.sh, and each copy's SHA-256 is written to policy/semgrep-registry.lock.json.
• Evidence: because the rules sit in the policy repo, they are covered by the policy content digest recorded in every bundle and used for replay.
• Updating: refreshing the rules is a policy change reviewed by risk. Rule IDs keep their registry names, so fingerprints and waivers survive a refresh unless the upstream rule itself changed.
• Live configs: anything listed in mapping.yaml → scanners.semgrep.configs is fetched live and isn't reproducible, so keep that list empty.

Severity routing: the first matching rule in mapping.yaml → rules sets each finding's control and, optionally, overrides its severity. A finding that matches no rule fails EV-01, so an unmapped scanner rule can't slip through unseen.

OSFI anchors: these are suggestions at the section level. Second-line risk owns and confirms them.

AI and model usage (MR-02 to MR-04)

What is detected. policy/semgrep/ai/ holds the osfi-mr02-<provider>-<language> rules: hosted APIs (OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, Foundry, Gemini, Cohere, Mistral, Groq, Together, Replicate, Hugging Face), frameworks (LangChain, LlamaIndex), and self-hosted inference (transformers, ONNX Runtime, llama.cpp, vLLM, sentence-transformers, torch.load, joblib.load, Ollama). AI/ML packages in the SBOM are recorded alongside as artifacts.ai.dependencies.

The risk reading encoded in mapping.yaml. Detect every provider; approve Canadian-region cloud (Bedrock, Vertex, Azure OpenAI, Foundry) and self-hosted inference; treat a direct call to a provider outside that set as a risk acceptance that needs a waiver. Correct gate.ai if that is not the intent.

Provider resolution. A call goes to the provider its client implies: AnthropicBedrock(...).messages.create(...) is bedrock, not anthropic. The gate applies a cloud client found anywhere in the same file. A file mixing a cloud client and a direct call would be attributed to the cloud provider, so keep them in separate modules.

New versus pre-existing. enforce: new-usage blocks only what a change introduces. The same rules run against the change's base commit (exported with git archive, so fingerprints line up) and anything already present warns instead. Scheduled and manual runs have no base commit, so nothing counts as new. Set enforce: all once a repository is clean.

Waiving a call site. MR-02, MR-03 and MR-04 are raised about a call site rather than by a scanner finding, but the call site carries the fingerprint of the rule that detected it, so they are waived exactly like a finding: a waivers/*.yaml naming that fingerprint and that control, owned, justified, inside the maximum term and approved by risk. A waiver covers the one control it names — accepting a US-hosted provider under MR-03 does not excuse leaving the model out of the inventory under MR-02. Because the fingerprint comes from the rule and the path, it survives the code moving down the file.

Model versions. There is no positive "pinned" pattern: claude-opus-5 is a complete published ID, while gpt-4o is an alias for whatever OpenAI points it at. So MR-04 checks a risk-maintained deny list (floating_model_patterns, where a pattern may start or end with *) and requires the model in the code to equal the model the inventory says was validated. Where the model can't be read from the call site, the gate warns and takes the inventory entry on trust.

Registering usage (model-inventory.yaml in the application repo):

ai_usage:
  - path: ai/summarize.py          # exact path or glob
    provider: bedrock
    model: anthropic.claude-sonnet-4-5-20250929-v1:0
    region: ca-central-1
    inventory_id: MRM-0101
    validation_record: https://grc.bank.example/model-validation/MRM-0101/2026-08
    purpose: Summarises inbound customer letters for the service desk.

E-23 model records (MR-05 to MR-07)

A call site says where a model is used. A model record says what it is, how material it is, and which controls are in place. Records live in model_records: in the same model-inventory.yaml, and call sites reference them by inventory_id.

The structure follows the OSFI E-23 AI Model Risk Alignment Tool: model profile, seven risk dimensions, a materiality tier, a governance control inventory, and the GenAI supplement. The difference is that here it is enforced — an assessment that lives only in a PDF cannot fail a build.

The tier is recorded on every run. MR-05 writes the computed tier into the evidence bundle as a warning carrying materiality, score and max_score, so "how material is this model" is answered by the evidence rather than by anything downstream recomputing it. The console's assessment report reads exactly those fields.

The tier is recomputed, never trusted. The gate scores the seven dimensions (low 1, medium 2, high 3) and derives the tier from gate.ai.e23.tier: any of high_if_any rated high makes the model high materiality outright, otherwise the total decides. A record that writes materiality: low while rating automation high is enforced as high, and the gate says so in a warning. The ratings are the claim; the tier is the consequence.

What each tier must hold is required_controls in the policy, plus genai_required_controls for generative model types. Only yes satisfies a requirement: partial, no and not-applicable do not. A record cannot exempt itself — an exemption is a waiver, which is owned, justified and expiring. Both the key and the value are checked against a vocabulary (control_vocabulary, control_states), so a typo fails rather than becoming a silent gap that looks like a decision.

A note on yes. YAML reads bare yes/no as booleans, so the gate normalises true/false and any casing to the same vocabulary. Both documentation: yes and documentation: "yes" work.

model_records:
  - inventory_id: MRM-0101
    name: Customer Letter Summariser v1
    model_type: llm                  # llm, rag, multi-agent get the GenAI control set
    business_domain: member-services
    owner: Jane Doe, Head of Member Services Technology
    lifecycle_stage: production
    risk_dimensions:                 # each rated low / medium / high
      financial: low
      breadth: medium
      complexity: high
      automation: low
      data_sensitivity: medium
      third_party: high
      criticality: low
    materiality: medium              # recorded, but the gate recomputes it
    assessed_on: 2026-08-14
    assessed_by: Priya Raman, Model Risk
    governance_controls: {documentation: yes, monitoring: yes, ...}
    genai_controls: {hallucination_testing: yes, prompt_change_control: yes, ...}
    validation:
      record: https://grc.bank.example/model-validation/MRM-0101/2026-08
      validated_on: 2026-08-01
      next_review: 2027-08-01
    limitations: English only; performance on French letters has not been validated.

Fingerprints

Waivers match on a 16-hex-character fingerprint that is stable across unrelated edits:

Semgrep rules from the policy repo are reduced to their bare osfi-* ID, so fingerprints are the same locally and in CI.

Adding a check

1. Add the rule to a scanner (for example a Semgrep rule in policy/semgrep/) or to osfi_gate/inspect.py.
2. Route it in mapping.yaml → rules.
3. If the control is new, add it to catalog/controls.yaml, run osfi-gate catalog, and add a deny rule plus a Rego unit test in rego/policy_test.rego.
4. Run conftest verify and pytest.