]> AutoCyber AI Pty Ltd

contact@crprotocol.io

General AI safety safety policy context relay protocol hallucination detection content security policy grounding directive language This document specifies the CRP-Safety-Policy directive language — a declarative policy syntax for expressing AI safety requirements at the transport layer. The directive language is modelled after HTTP Content-Security-Policy (CSP) as defined in W3C CSP Level 3. It allows clients to declare what AI output characteristics are trusted, what risk levels trigger enforcement actions, and where violations should be reported. The CRP gateway enforces these policies on every AI response before delivery to the client. This document defines the complete directive grammar, enforcement semantics, violation reporting, and policy inheritance in multi-agent chains. Document Information Document: CRP-SPEC-006 Version: 3.0.0 Status: Draft — IETF Internet-Draft Candidate License: CC BY 4.0 (specification text) Prerequisites: CRP-SPEC-001 (Core), CRP-SPEC-002 (Headers), CRP-SPEC-005 (DPE)

Introduction

Design Inspiration: Content-Security-Policy CSP transformed browser security by moving enforcement from "check in JavaScript" to "declare at the transport layer and let the browser enforce." Before CSP, every web application implemented its own XSS protection. After CSP, a single header — Content-Security-Policy: default-src 'self' — enforced security across the entire page without application code changes. CRP-Safety-Policy applies the same principle to AI safety. Before CRP-Safety-Policy, every AI application implements its own hallucination checking. After CRP-Safety-Policy, a single header — CRP-Safety-Policy: default-src context; halt-on CRITICAL — enforces safety across every AI call without application code changes. The CRP gateway is the enforcer, just as the browser is the enforcer for CSP.

Scope This document defines:

• The complete ABNF grammar for CRP-Safety-Policy directives
• The enforcement semantics for each directive
• The interaction between directives
• Violation reporting (analogous to CSP report-uri)
• Policy inheritance and tightening in multi-agent chains
• The CRP-Safety-Policy-Report-Only header for monitoring without enforcement

Grammar

Complete ABNF group-name = 1*( ALPHA / DIGIT / "-" / "_" ) ; Quality -- response quality requirements (v3.0) quality-directive = "require-flow" SP threshold / "require-completeness" SP threshold / "max-repetition" SP repetition-level repetition-level = "NONE" / "MINOR" / "SIGNIFICANT" OWS = *( SP / HTAB ) SP = %x20 HTAB = %x09 ]]>

Header Syntax ; ; ... ]]> Example:

Directive Reference

default-src (Source Trust) Purpose: Declares which grounding sources are trusted for claims in the response. Enforcement: After DPE Stage 2 (Attribution Analysis), any claim attributed to a source type not listed in default-src is treated as a policy violation.

Source Value	Claims Allowed From
context	Claims grounded in the Context Envelope (CKF + current session facts)
parametric	Claims from the LLM's parametric memory (training data)
ckf	Claims specifically from CKF Tier 3 (cross-session knowledge graph)
cross-session	Claims referencing prior session data
'none'	No claims trusted — effectively blocks all AI output

Examples: Default (if default-src not specified): default-src context parametric

halt-on (Halt Enforcement) Purpose: Stop response delivery and return HTTP 451 when the DPE risk classification meets or exceeds the specified level. Enforcement:

1. DPE runs fully (all 13 stages)
2. If CRP-Safety-Hallucination-Risk is greater than or equal to the specified level, HTTP 451 is returned
3. Response body contains halt reason, audit trail URI, and retry condition
4. Webhook fired to report-uri (if configured)
5. CRP-Safety-Retry-After: oversight-required is set on the 451 response

Behaviour by level: Note: halt-on and warn-on can coexist for different levels:

warn-on (Warning Without Halt) Purpose: Pass the response but emit risk-level headers when the threshold is met. Enforcement: The response passes through to the client. The following headers are guaranteed to be present:

• CRP-Safety-Hallucination-Risk: <level>
• CRP-Safety-Hallucination-Score: <score>
• Violation report POSTed to report-uri (if configured)

require-grounding (Minimum Grounding Floor) Purpose: Reject responses where the grounding percentage falls below the threshold. Enforcement: If CRP-Safety-Grounding-Pct is below the threshold, the response is rejected. Rejection behaviour: If upgrade-on-risk is set, the gateway re-dispatches with context-strict grounding mode. If re-dispatch also fails, HTTP 451 is returned. Examples:

require-entailment (Minimum Entailment Floor) Purpose: Reject responses where the NLI entailment score falls below the threshold. Enforcement: If CRP-Safety-Entailment-Score is below the threshold, the response is rejected using the same flow as require-grounding.

require-quality (Minimum Quality Tier) Purpose: Reject responses from envelopes below the specified quality tier. Enforcement: If CRP-Context-Quality-Tier is not in the specified list, HTTP 503 is returned. Example:

require-flow (Minimum Flow Score) This directive is new in version 3.0. Purpose: Ensure multi-window responses maintain coherent flow. Enforcement: If CRP-Quality-Flow is below the threshold, the gateway re-dispatches with a flow augmentation prompt (see CRP-SPEC-005 Section 11.5). Example:

require-completeness (Minimum Completeness) This directive is new in version 3.0. Purpose: Ensure the response addresses all constituent information needs of the query. Enforcement: If CRP-Quality-Completeness score is below the threshold, an auto-continuation window is dispatched to cover uncovered sub-queries. Example:

block-ungrounded Purpose: Block the response if any factual claim is ungrounded (PARAMETRIC or UNVERIFIABLE attribution with no source in the envelope). Enforcement: Equivalent to default-src context but applied per-claim rather than as a default. Individual ungrounded claims cause rejection; default-src context parametric combined with block-ungrounded means parametric claims are allowed in the source trust model but individually ungrounded specific claims are still blocked.

block-pii Purpose: Block the response if PII is detected by DPE Stage 11. Enforcement: If CRP-Compliance-GDPR-PII: true, the response is rejected. Especially important for public-facing AI systems where PII exposure constitutes a GDPR Art. 5(1)(f) violation.

block-fabrication Purpose: Block the response if any fabricated entity is detected by DPE Stage 3a. Enforcement: If CRP-Safety-Fabrications is greater than 0, the response is rejected. This is the strictest fabrication policy and is recommended for medical, legal, and financial domains.

block-repetition This directive is new in version 3.0. Purpose: Block the response if SEVERE repetition is detected by DPE Stage 7. Enforcement: If CRP-Quality-Repetition level is SEVERE, the gateway re-dispatches with an anti-repetition prompt. If re-dispatch also produces SEVERE repetition, the response is halted.

max-repetition This directive is new in version 3.0. Purpose: Set the maximum tolerable repetition level. Enforcement:

upgrade-on-risk (Strategy Auto-Upgrade) Purpose: When risk exceeds the warn-on level, automatically upgrade the dispatch strategy. Enforcement:

1. Initial dispatch proceeds with the current strategy (e.g., push)
2. DPE detects HIGH risk
3. Gateway re-dispatches with the specified strategy (e.g., reflexive)
4. Reflexive dispatch includes a verification pass, expected to yield lower risk
5. If re-dispatch still exceeds the threshold, the gateway halts (if halt-on is set) or passes with a HIGH warning

Example:

oversight (Human Oversight Mode) Purpose: Set the human oversight level for the session. Enforcement: See CRP-SPEC-002 Section 5.10 (CRP-Safety-Oversight-Mode).

report-uri (Violation Reporting) Purpose: Specify the endpoint to which violation reports are POSTed. Report payload (JSON): Note: report-uri for CRP-Safety-Policy naturally integrates with CRP Comply — the audit_trail_uri in the report links directly to the Comply evidence record.

Policy Interaction Rules

Directive Precedence When multiple directives interact, the most restrictive wins: CRITICAL = halt, HIGH = warn, MEDIUM/LOW = pass halt-on HIGH + warn-on MEDIUM -> HIGH/CRITICAL = halt, MEDIUM = warn, LOW = pass halt-on CRITICAL + upgrade-on-risk reflexive -> HIGH = upgrade to reflexive and retry CRITICAL = halt (even after upgrade) ]]>

CRP-Safety-Mode Override CRP-Safety-Mode (see CRP-SPEC-002 Section 5.11) is a shorthand for common policy combinations:

Mode	Equivalent Policy
strict	halt-on CRITICAL; warn-on HIGH; block-ungrounded; require-grounding 0.75
warn	warn-on CRITICAL; warn-on HIGH
permissive	(no enforcement directives)

When both CRP-Safety-Mode and CRP-Safety-Policy are set, the more restrictive value wins on a per-directive basis.

Report-Only Mode The CRP-Safety-Policy-Report-Only header evaluates the policy but does NOT enforce it: All violations are computed and reported to report-uri but responses are never halted. This enables gradual policy rollout — observe violations before enforcing.

Policy Inheritance in Multi-Agent Chains

Tightening Rule In multi-agent chains, a child agent's Safety Policy MUST be equal to or more restrictive than the parent's: Gateways MUST reject child agent requests that attempt to relax the parent's policy.

Enforcement When a child agent request is received:

1. Gateway reads CRP-Agent-Session-Parent to identify the parent session
2. Gateway retrieves the parent's Safety Policy
3. Gateway compares each directive in the child's policy against the parent's
4. Any directive that is less restrictive results in rejection with HTTP 403 and CRP-Safety-Policy-Violation: inheritance

Policy Propagation Header When the gateway enforces policy inheritance, it emits: This indicates the effective policy after inheritance resolution, which may differ from the client's requested policy.

Industry-Specific Policy Profiles

Pre-Defined Profiles CRP defines named policy profiles for common industry use cases: Profiles can be extended with additional directives:

Security Considerations

Policy Injection An attacker who can inject or modify the CRP-Safety-Policy header can relax safety enforcement. Mitigations include:

• CRP-Safety-Nonce (see CRP-SPEC-002 Section 5.16) binds the policy to a session nonce
• Gateways MUST validate policy syntax before accepting — malformed policies are rejected
• In multi-agent chains, the tightening rule (Section 5.1) prevents child agents from relaxing parent policies

Report-URI as Exfiltration Vector Violation reports contain session IDs, risk scores, and audit trail URIs. The report-uri destination MUST be trusted. Gateways SHOULD validate that report-uri is under the same domain as the CRP API key's registered organisation.

References Normative References AutoCyber AI Pty Ltd AutoCyber AI Pty Ltd AutoCyber AI Pty Ltd W3C

Copyright Notice Copyright © 2025–2026 AutoCyber AI Pty Ltd. Licensed under CC BY 4.0 (specification text). CRP™ is a trademark of AutoCyber AI Pty Ltd.