Skip to content

Safety and security compliance (SEC)

Safety and security telemetry detects harmful output, policy failure, privacy or classified-data leakage, unauthorised tool use, privilege changes, credential misuse, and incomplete incident evidence.

Requirement map

Tier ORF items Capability
2 ORF-SEC-02, ORF-SEC-03, ORF-SEC-05–ORF-SEC-13 policy/refusal, privacy, leakage, access, identity, credential, and audit evidence
3 ORF-SEC-01, ORF-SEC-04 harmful-output and sensitive-topic trend analysis

Record control decisions

For each guardrail or policy decision capture:

  • policy and rule version;
  • decision category and enforcement point;
  • allow, block, redact, transform, escalate, or monitor action;
  • model/tool/agent context;
  • timestamp and trace reference; and
  • approved confidence or reason metadata where meaningful.

Avoid storing the harmful or sensitive content in the general security event. Link to restricted evidence when investigation requires it.

Measure violations and refusals correctly

ORF-SEC-02 compares detected policy violations with the refused subset. Track total detected, refused, allowed by exception, transformed/redacted, escalated, and control error. A refusal can be correct or incorrect; pair security rates with experience and performance review.

Privacy and classified-data incidents

Define detection sources, validation, severity, and case workflow. Counts should represent triaged incidents or clearly labelled detections; do not mix raw detector matches with confirmed exposure.

Incident records should link to the affected trace, data classification, exposure channel, containment, notification decision, root cause, and remediation without duplicating sensitive content.

Tool authorisation and identity

Record the difference between:

  • the end user;
  • the service or agent identity;
  • the delegated credential;
  • the tool and requested operation;
  • the authorised scope; and
  • the actual resource/action.

Never record raw credentials. Use a non-secret credential/key identifier and audit token issuance, scope, rotation, revocation, and use.

Protect the audit trail

For ORF-SEC-12 and ORF-SEC-13:

  • use append-only, write-once, cryptographic integrity, or equivalent approved controls;
  • maintain stable event order and trusted time;
  • detect missing sequence/coverage where possible;
  • audit access and export;
  • separate administrators who operate the product from those who can alter evidence controls; and
  • test restoration and legal/incident retention procedures.

Detection and response views

  • policy violation → action outcome;
  • harmful output by control/review source and version;
  • privacy/classified leakage detections and confirmed incidents;
  • sensitive memory/KB access;
  • privileged-tool attempts and failures;
  • permission/token changes and agent credential use;
  • audit-trail coverage/integrity; and
  • active cases with linked traces and containment status.

Alerts

  • confirmed or high-confidence sensitive-data exposure;
  • unauthorised privileged tool attempt;
  • anomalous agent credential scope or tool use;
  • audit pipeline loss, integrity failure, or access anomaly;
  • repeated guardrail bypass pattern; and
  • harmful-output rate change after release.

Acceptance scenarios

Use synthetic PII/classified markers, a blocked privileged action, an expired credential, an approved permission change, a guardrail refusal, and an audit exporter failure. Verify detection, evidence restrictions, case linkage, containment, and access audit.

Done when: responders can investigate safety and security events without exposing restricted evidence to ordinary operators, and the evidence itself has demonstrable integrity.

Next: Lifecycle and governance