On this page
RNX code library · 5 controls
RNX-320Governance, Security & Guardrails
Read what these checks mean, why they matter and which evidence they concern. Each ID below keeps its canonical place in the RNX hierarchy.
These are free learning summaries, not full technical tests or an industry certification. Specialized checks apply only to the relevant feature. Experimental labels are preserved from the canonical source.
RNX-321 · NIST-Aligned Action Boundaries
RNX-321.T001
Owned agent risk mapping
Experimental — not an established ranking requirement
For an owned agent, assign responsibility and safeguards for major risks.
Why it matters. A risk list without an owner cannot guide a reliable response.
Illustration — fictional. Nobody is assigned to handle the risk of an automated tool charging a customer twice.
When it applies. Inspected target: risk entry. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-322 · Human-in-the-Loop Interventions
RNX-322.T001
Consequential-action approval
Experimental — not an established ranking requirement
Require authorized approval of exact terms before a consequential automated action.
Why it matters. A vague prior conversation is not consent to a specific transaction.
Illustration — fictional. Approval for a ten-dollar purchase is reused for a hundred-dollar purchase.
When it applies. Inspected target: approval-negative fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-324 · Policy Enforcement Runtime
RNX-324.T001
Server-side policy denial
core readiness
Enforce policy at the service, before an action takes effect.
Why it matters. Hiding a button alone does not stop a direct request.
Illustration — fictional. A forbidden action is hidden in the menu but still works when requested directly.
When it applies. Inspected target: direct denied action. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-326 · Continuous Session Verification
RNX-326.T001
Revoked-session denial
Experimental — not an established ranking requirement
Honor revoked sessions within the declared policy.
Why it matters. Former access should not silently remain usable forever.
Illustration — fictional. A revoked session can still change records after the promised revocation period.
When it applies. Inspected target: revocation fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-327 · Semantic Compatibility Validation
RNX-327.T001
Versioned contract regression
Experimental — not an established ranking requirement
Preserve promised behavior or clearly version a breaking change.
Why it matters. Connected clients need to know when a contract has changed.
Illustration — fictional. A service silently changes the meaning of a task status without changing its contract version.
When it applies. Inspected target: contract regression. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.