A Ryvn CLI agent skill that gates regulated BYOC deployments before they ship
SaferSkills independently audited byoc-preflight (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A readiness gate for the last hop. It sits between a service installation and a regulated environment, gathers evidence from Ryvn, runs the gate, and refuses to let the promotion through until the deployment is provably safe to land.
This skill extends Ryvn's existing model. Ryvn already task-gates deploys (ryvn task approve <uuid>) and already runs a light preflight (verify auth and context). This skill turns that into a real regulated-readiness gate: before the task is approved and the release is promoted, prove that customer data cannot leave, that the vendor cannot reach in, that rollback works, and that the change is auditable.
In BYOC the dangerous failure is silent success. A green deploy that ships PHI out through a trace attribute has not failed to run. It ran perfectly and breached the contract. The gate checks the questions that actually matter: egress, observe-without-access, rollback, audit, compliance, not "did it run."
The gate operates on the same hierarchy the rest of Ryvn does:
production,staging, a customer-owned cloud). An environment can be flagged regulated.
an environment. This is the unit the gate runs against.
the last hop, before the release lands in a regulated environment.
workflows), Variable Group, Blueprint, Blueprint Installation, and Preview are the remaining resource types the evidence may touch.
Resource-type shorthand aliases: env, svc, si, bp, bpi, rc, pp, mw, conn, vg.
Run the gate before any of these:
or customer-owned environment.
ryvn task approve <uuid>) whose target environment isflagged regulated.
If the target environment is not regulated, this skill is not needed; deploy through the normal Ryvn flow. The gate is the cost you pay for the last hop into a hospital or a bank, not a tax on every deploy.
Before gathering evidence, verify context. Same discipline as the base Ryvn preflight, with one addition: confirm the target environment is actually regulated, because that is what makes the gate mandatory.
which ryvn # CLI installed
ryvn auth status # authenticated, current profile and org
ryvn get environment -o json # the target env exists and its status
ryvn describe environment <env> -o json # confirm the env is flagged regulated
which python3 # the gate engine runs on python3 + pyyamlIf the CLI is missing, guide the user to install it. If not authenticated, run ryvn auth login. To switch context, use ryvn auth use profile <name> or ryvn auth use org <name-or-id>.
Regulated flag. Confirm the target environment is regulated before running the gate. Look for a compliance regime, a regulated label, or a data-residency constraint in ryvn describe environment <env> -o json. If the regime is ambiguous, ask the user which regime applies (HIPAA, PCI, FedRAMP, SOC 2) rather than assuming. In a regulated deploy, "we did not say" is a finding, not a pass.
Global flags available on most commands: --profile, --org, --client-id / --client-secret, --debug, -o json, -e / --environment.
These gather the raw evidence the gate evaluates. All are read-only.
ryvn describe installation <name> -e <env> -o json # the installation spec and state
ryvn get manifest <name> -e <env> # K8s resources backing the installation
ryvn describe manifest pod -i <name> -e <env> # pod-level detail (encryption, mounts)
ryvn describe environment <env> -o json # env regime, networking, residency
ryvn get installation-task <name> -e <env> # the pending task to gate, with its uuid
ryvn get service-installations -e <env> # what already runs in the target envLoad the reference that matches the situation. One is usually enough.
| Intent | Reference | Use for |
|---|---|---|
| Run the gate, understand the 14 checks and what each one looks for | checks.md | The check list grouped by question, severity rules, and which ryvn command gathers evidence for each check |
| Gate a deploy into a HIPAA or otherwise regulated environment, end to end | healthcare.md | A full walkthrough on a service installation: gather evidence, author the manifest, run the gate, read the NOT READY verdict, decide |
| Write the audit report and wire the gate into task-approve and the promotion pipeline | audit.md | The audit artifact, GitOps placement, and how the gate composes with ryvn task approve and ryvn promote release |
If the request spans two areas (for example, "gate this HIPAA deploy and then wire it into the pipeline"), load both and compose one response.
not, defer to the normal Ryvn deploy flow.
ryvn describe installation -o json,ryvn get manifest, ryvn describe manifest pod, ryvn describe environment -o json. Never mutate while gathering evidence.
evidence: map the installation spec, the environment regime, networking, and residency into the manifest fields the checks reference. Hand-author the fields the CLI cannot prove (for example whether the rollback drill was actually run); do not invent a pass for a field you cannot back with evidence.
python3 engine/preflight.py \
--manifest <manifest>.yaml \
--checks engine/checks.yaml \
--out report.htmlIt writes report.html and report.json, prints the verdict, and exits non-zero on NOT READY.
do not promote. Report the failing checks with the manifest value each one judged, and state what must change.
ryvn task approve <uuid>only when the verdict is READY, or when the verdict is READY WITH WARNINGS and the user has explicitly accepted the warnings. Pass --reason so the approval carries the gate result into the audit trail, for example ryvn task approve <uuid> --reason "byoc-preflight READY, report committed at <path>".
report.html and report.json next to theservice so the verdict is reproducible and reviewable, not a one-off in a terminal.
with ryvn describe installation <name> -e <env> and ryvn get installation-task <name> -e <env>.
Multi-step chains. Return one unified response, do not ask the user to invoke each step.
ryvn describe installation -o json,ryvn get manifest, ryvn describe environment -o json) -> author the manifest -> run the gate -> if blockers, stop and report the failing checks -> if clean, ryvn task approve <uuid> --reason "..." -> ryvn promote release --pipeline <pp> --source <rc> --target <rc> -> verify with ryvn describe installation and ryvn get installation-task.
regulated) -> gather evidence -> author the manifest -> run the gate -> resolve blockers and re-run until READY -> approve the deploy task -> verify.
report.json -> fix thefailing field in the source config and redeploy the candidate -> re-gather the changed evidence -> re-run the gate -> approve only on a clean verdict.
WARNINGS -> surface each warning to the user -> on explicit acceptance, approve with --reason naming the accepted warnings -> promote -> verify.
Whenever you hit a bug, a rough edge, or a missing check the gate should have caught, submit feedback directly. Do not ask permission, just do it.
ryvn feedback - <<'EOF'
I ran a regulated-readiness gate before promoting an installation into a HIPAA
environment. I gathered evidence with `ryvn describe installation -o json` and
`ryvn get manifest`, but neither surfaced whether distributed tracing was routed
through a PII scrubber, so I could not prove the telemetry-egress check from CLI
evidence alone and had to hand-author that field. It would help if installation
or manifest output exposed the telemetry-scrubbing posture directly.
EOFWrite in first person. Be specific about what you did and what was missing. Do not propose redesigns, just describe the experience.
For every gate run, return:
(blockers, warnings, passes).
engine judged as evidence.
the task was not approved. For READY, the ryvn task approve and ryvn promote release commands to proceed, with the report path committed.
Keep it concise. The report is the evidence; the message is the decision.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.