Agentic-AI Govt-Guidance Coverage Audit¶
This page maps the joint government guidance "Careful Adoption of Agentic AI Services" onto the VisiTrans toolkit's actual security posture. It is a traceable index — every recommendation is classified against what the toolkit enforces by default, not what merely exists in the repo. It is the external foundation the KI-Richtlinie (SPEC-147) cites; it does not author policy itself.
Source pin (machine-checked by tests/spec-131/test_coverage_staleness.bats):
- Source: Careful Adoption of Agentic AI Services — CISA / NSA / NCSC-UK / NCSC-NZ / Canadian Cyber Centre / ASD-ACSC
- Source-URL: https://www.ncsc.govt.nz/protect-your-organisation/careful-adoption-of-agentic-ai-services/
- Source-Version/Date: 2026 (published), captured 2026-05-04
- Last-Audited: 2026-07-05
- Re-audit-After: 12 months
- License: CC BY 4.0 © Commonwealth of Australia 2026
How to read this audit¶
The audit runs in two passes, reflected in the Audience and Status columns:
Pass 1 — audience triage. The guidance targets organisations that design, develop, deploy and operate agentic AI systems, and labels each best-practice block with its own audience. VisiTrans is a consumer of a third-party agentic tool (Claude Code) with humans in the loop — it does not build or run an agentic service. Each row is therefore tagged:
in-audience— the control is meaningful for a tool-user/operator.N/A (builder-scoped)— the control lives inside the agent/LLM platform (model training, in-context composition, per-agent cryptographic identity). Out of scope.N/A (operator-scoped)— the control only applies to an org running an agentic service for others (managed identity registries, runtime policy-decision-points, fleet trust-scoring). VisiTrans runs none, so these default to N/A unless that changes.
Only in-audience rows proceed to Pass 2.
Pass 2 — coverage classification. For in-audience rows:
covered— enforced by default by one of: a wired hook, an installed pre-commit check, or git-versioning; or — for documentation/process controls that cannot be hook-enforced (a threat model, incident runbooks) — a maintained, present-and-current artifact. Present and active either way.partial— the control exists but is not enforced by default: authored-but-not-deployed (e.g. the 157-rule deny baseline is a comparison template — deployed settings carry zero deny rules), doc-only guidance, or a manual--verifystep.gap— no toolkit control exists.
Conditional applicability. Usage is mixed (human-in-the-loop plus some unattended
runs). Controls that only bite under unattended operation carry Condition: unattended,
so SPEC-147 sees which controls become load-bearing if unattended usage grows.
Gap discipline. A gap becomes a new spec-proposal only if it passes a
proportionality test — "does this threat realistically exist for a 4-dev internal
tool-user?" At most two proposals were raised this round
(see Gap Register); every other gap is deferred: with a rationale.
Column glossary: Recommendation (the actionable lever) · Govt-Section (source
anchor for SPEC-147 citation) · Risk-Class — the four classes named in
spec.md §Risk-Classes (Privilege / Behaviour / Structural / Accountability) plus
Design-Config for context- and prompt-architecture levers surfaced during the
audit · Audience (Pass 1) · Toolkit-Implementation
(enforcing artifact, backticked path — dereferenced by the structure test) · Status
(Pass 2) · Condition · Note · Spec-Reference.
Cross-references, not duplication: coverage classifications lean on Security Overview §4 (Controls Matrix) / §5 (Residual Risks) and AI & Agent Security rather than restating them.
Group A — Designing secure agents¶
Guidance audience: "most relevant to agentic AI developers." Predominantly builder-scoped for a tool-user; the oversight, defence-in-depth and sub-agent handoff levers are the exceptions that apply to VisiTrans.
| Recommendation | Govt-Section | Risk-Class | Audience | Toolkit-Implementation | Status | Condition | Note | Spec-Reference |
|---|---|---|---|---|---|---|---|---|
| Structure prompt context with a clear instruction hierarchy | Designing › Controlled context | Design-Config | N/A (builder-scoped) | — | N/A | — | How the LLM composes and prioritises its context window is internal to Claude Code / Anthropic; VisiTrans supplies task content, not model architecture. | — |
| Ground responses via RAG to mitigate hallucination | Designing › Controlled context | Behaviour | N/A (builder-scoped) | — | N/A | — | Model-internal grounding is the agent platform's responsibility. | — |
| Human control and oversight points (live monitoring, approval, reversibility) | Designing › Oversight mechanisms | Accountability | in-audience | configs/user-global/CLAUDE.defaults.md, plugins/core-standards/skills/workflow-4-review/SKILL.md |
partial | unattended | auto-mode classifier (CLAUDE.defaults §10b) plus pre-merge .review-gate.md give approval and reversibility at the workflow layer; no per-action interruption for unattended runs. |
deferred: per-action HITL only load-bearing if unattended usage grows |
| Construct each agent as a distinct cryptographic principal (own keys/certs) | Designing › Identity management | Privilege | N/A (builder-scoped) | — | N/A | — | Per-agent identity primitives belong to the agent platform; VisiTrans operates one trusted Claude Code principal. | — |
| Authenticate inter-agent and agent-to-service calls with mutual TLS | Designing › Identity management | Structural | N/A (builder-scoped) | — | N/A | — | VisiTrans runs no inter-agent network; MCP transport auth is provider-managed. | — |
| Maintain a trusted registry of agent identities; deny non-registry agents | Designing › Identity management | Privilege | N/A (operator-scoped) | — | N/A | — | A managed agent-identity registry applies to an org running an agentic service, not a tool-user (AD-1a). | — |
| Defence in depth — overlapping controls at every input/output boundary | Designing › Defence in depth | Structural | in-audience | plugins/core-standards/hooks/hooks.json, docs/security/security-overview.md |
covered | — | Layered hooks (PreToolUse secret-scan + supply-chain, PostToolUse lint) plus Constitution plus review plus audit enforce multi-layer defence by default (Security Overview §3). | — |
| Enforce boundaries on agent-to-agent handoffs (sub-agent privilege) | Designing › Defence in depth | Structural | in-audience | docs/security/ai-agent-security.md, docs/security/security-overview.md |
partial | — | Read-only agents are bounded by the allowed-tools / max_subagent_tools convention only; the runtime does not enforce a parent's restrictions on children (Residual Risk 5.2). |
deferred: runtime sub-agent sandbox not available upstream |
Group B — Developing secure agents¶
Guidance audience: "most relevant to agentic AI developers and vendors." Training/evaluation levers are builder-scoped; input-handling, resilience, third-party management and consensus are the operator-relevant rows.
| Recommendation | Govt-Section | Risk-Class | Audience | Toolkit-Implementation | Status | Condition | Note | Spec-Reference |
|---|---|---|---|---|---|---|---|---|
| Reward modelling and adversarial training to detect specification gaming | Developing › Comprehensive testing | Behaviour | N/A (builder-scoped) | — | N/A | — | Training-time control owned by the model developer. | — |
| Train and evaluate agents in simulated environments (synthetic adversarial data, active learning) | Developing › Comprehensive testing | Behaviour | N/A (builder-scoped) | — | N/A | — | Simulated-environment training is a model-development activity. | — |
| Capability evaluation across autonomy levels (Best-of-N, inference-time scaling) | Developing › Appropriate evaluation | Behaviour | N/A (builder-scoped) | — | N/A | — | Model-capability evaluation is the vendor's; VisiTrans evaluates outputs, not model capability. | — |
| Robust input validation and sanitisation for all agent inputs | Developing › Input management | Design-Config | in-audience | docs/security/ai-agent-security.md, plugins/core-standards/skills/defense-in-depth/SKILL.md |
partial | — | The intake pipeline validates YAML and sanitises slugs at the intake/ boundary; free-form prompt/tool inputs in general sessions are not validated. |
— |
| Prompt-injection filters and semantic analysis on inputs | Developing › Input management | Behaviour | in-audience | docs/security/ai-agent-security.md |
partial | — | Structured-frontmatter parsing, context: fork isolation and system-prompt flagging are convention/heuristic; no dedicated injection classifier (named gap, ai-agent-security Quick Reference). |
deferred: content-based injection heuristics deferred |
| Fail-safe defaults and containment to limit blast radius | Developing › Resilience | Structural | in-audience | plugins/core-standards/scripts/supply-chain-guard.sh, plugins/core-standards/scripts/pre-commit |
partial | — | supply-chain-guard (deny-JSON) and pre-commit Check C are fail-closed; partition/venv guards are continueOnError:true (warn-only) and there is no global blast-radius container. |
— |
| Versioning and rollback to known-good behaviour | Developing › Resilience | Structural | in-audience | configs/security/config-snapshot.yaml, plugins/core-standards/skills/repo-audit/SKILL.md |
covered | — | All skills, agents and config are git-versioned; /repo-audit snapshots config; rollback is a git revert. |
— |
| Comprehensive artefact and audit logging by default | Developing › Accountability | Accountability | in-audience | configs/monitoring/cc-metrics.py, docs/operations/monitoring.md |
partial | unattended | SPEC-129 metrics readout exists (opt-in, numeric usage + tool/skill names only); no always-on unified log of agent tool calls / reasoning. | deferred: always-on audit log is SPEC-129 §6 upgrade path |
| Manage third-party components — trusted source, up-to-date, SBOM, allow-list | Developing › Manage third-party components | Structural | in-audience | plugins/core-standards/scripts/supply-chain-guard.sh, configs/security/mcp-package-hashes.yaml, scripts/setup.sh |
covered | — | MCP packages are version-pinned and integrity-hash verified; supply-chain-guard blocks unpinned installs; npm ci --ignore-scripts + npm audit per SPEC-103. |
— |
| Consensus / separation-of-duties (Orchestrator/Reader/Actuator; multi-agent approval for moderate-stakes) | Developing › Manage third-party components | Accountability | in-audience | plugins/core-standards/skills/workflow-4-review/SKILL.md |
partial | — | /vt-c-4-review runs 6 parallel reviewers plus hard gates but has no explicit quorum/consensus primitive — review is aggregation, not voting. |
deferred: explicit consensus marginal for a 4-dev tool-user (proportionality) |
Group C — Deploying agents securely¶
Guidance audience: "most relevant to agentic AI vendors and operators." Predominantly in-audience for VisiTrans.
| Recommendation | Govt-Section | Risk-Class | Audience | Toolkit-Implementation | Status | Condition | Note | Spec-Reference |
|---|---|---|---|---|---|---|---|---|
| Threat modelling with agentic risk taxonomies (OWASP GenAI, MITRE ATLAS) | Deploying › Threat modelling | Accountability | in-audience | docs/security/security-overview.md, docs/security/ai-agent-security.md |
covered | — | A documented threat model (supply chain, prompt injection, exfiltration, privilege escalation) is mapped to controls; this audit adds the agentic-taxonomy cross-walk. | — |
| Develop and test incident-response procedures for agent compromise | Deploying › Threat modelling | Accountability | in-audience | docs/security/incident-response.md |
covered | — | Five incident-type runbooks, including injected-proposal and hook-mismatch. | — |
| Governance policy for autonomous agents; define legal accountability | Deploying › Governance | Accountability | in-audience | .specify/memory/constitution.md, configs/user-global/CLAUDE.defaults.md |
partial | — | Constitution Principle I and CLAUDE.defaults set binding rules, but a dedicated org-level KI-Richtlinie is not yet authored. | SPEC-147 |
| Progressive / phased deployment with graduated autonomy | Deploying › Progressive deployment | Design-Config | in-audience | docs/security/hardening-guide.md |
partial | unattended | Hardening guide plus permission modes support staged rollout, but no formal graduated-autonomy ladder is documented. | deferred: formal autonomy ladder low-value at current scale |
| Secure-by-default — fail-safe, escalate to human on uncertainty | Deploying › Secure by default | Design-Config | in-audience | plugins/core-standards/scripts/pre-commit, plugins/core-standards/scripts/supply-chain-guard.sh |
partial | — | Critical paths fail closed; most guards warn-only (continueOnError:true) and the default permission mode is not fail-closed. |
— |
| Guardrails and hard constraints (deny lists, API-level safety, declarative contracts) | Deploying › Guardrails and constraints | Privilege | in-audience | configs/security/baseline-settings.json, configs/user-global/settings.json |
partial | — | A 157-rule deny baseline exists as a comparison template, but the deployed settings carry zero deny rules (allow-list of 4). Deploying the baseline is an ops decision with workflow-friction trade-offs, not a new spec. | deferred: deploy baseline deny-rules is an operational toggle |
| Deploy a secondary agent to validate new tasks against policy before execution | Deploying › Guardrails and constraints | Behaviour | in-audience | — | gap | unattended | No pre-execution policy-validation agent; /vt-c-4-review runs post-hoc, not pre-action. Same lever as goal-drift detection (Group D). |
PROP: goal-drift-spec-precheck |
| Isolation and segmentation to limit blast radius; enclaves | Deploying › Isolation | Structural | in-audience | plugins/core-standards/scripts/partition-guard.sh |
partial | — | partition-guard enforces repo-partition boundaries (warn-only, continueOnError:true); no process or network sandbox exists (Residual Risk 5.1). |
— |
Group D — Operating agents securely¶
Guidance audience: "most relevant to agentic AI vendors and operators." Houses the JIT-credential, goal-drift and cryptographic-attestation gap candidates.
| Recommendation | Govt-Section | Risk-Class | Audience | Toolkit-Implementation | Status | Condition | Note | Spec-Reference |
|---|---|---|---|---|---|---|---|---|
| Monitor all agent operations, including internal processes | Operating › Monitoring and auditing | Accountability | in-audience | configs/monitoring/cc-metrics.py, docs/operations/monitoring.md |
partial | unattended | Opt-in numeric usage metrics only; the internal reasoning / tool-call stream is not monitored by default. | deferred: deep monitoring is SPEC-129 §6 upgrade path |
| Monitor and audit identity/privilege changes for drift | Operating › Monitoring and auditing | Privilege | in-audience | plugins/core-standards/skills/repo-audit/SKILL.md, configs/security/config-snapshot.yaml |
partial | — | /repo-audit detects config and hook drift, but it is a manual trigger, not continuous. |
deferred: continuous drift monitoring deferred |
| Runtime anomaly detection with behavioural baselines and auto-pause | Operating › Monitoring and auditing | Behaviour | N/A (operator-scoped) | — | N/A | — | A runtime behavioural-baseline engine belongs to an org running the agent service (AD-1a). | — |
| Goal-drift detection — compare active objective vs approved baseline before execution | Operating › Monitoring and auditing | Behaviour | in-audience | — | gap | unattended | No mechanism compares a run's active objective against the spec's acceptance criteria before execution. Overlaps SPEC-132 (cross-project overlap/contradiction) — coordinate to avoid duplication. | PROP: goal-drift-spec-precheck |
| Validate agent outputs against multiple sources / redundant cross-check | Operating › Validate outputs | Accountability | in-audience | plugins/core-standards/skills/verification-before-completion/SKILL.md, docs/security/ai-agent-security.md |
partial | — | verification-before-completion plus the 6-reviewer cross-check reduce hallucination, but there is no automated multi-source output validation. Detection, not prevention. | — |
| Validate tool responses / MCP output schema validation | Operating › Validate outputs | Structural | in-audience | — | gap | — | MCP tool outputs are not schema-validated before the agent consumes them (named gap, ai-agent-security §5). | deferred: PostToolUse schema hook — low likelihood at current MCP set |
| Human-in-the-loop for high-impact / irreversible actions (deletes, egress, resets) | Operating › Human in the loop | Accountability | in-audience | plugins/core-standards/scripts/pre-commit, configs/user-global/CLAUDE.defaults.md |
partial | unattended | Main-branch commit block plus auto-mode classifier gate some high-impact actions; no general irreversible-action approval gate. Quarantine pattern (incident-response) covers suspicious intake but is not wired for log/audit deletion. | deferred: general HITL gate load-bearing only if unattended usage grows |
| Least privilege — minimum scope per task | Operating › Privileges and authentication | Privilege | in-audience | configs/security/baseline-settings.json, configs/user-global/settings.json |
partial | — | Least privilege is the design intent (deny baseline plus allow-list) but the deny baseline is undeployed; effective posture is allow-list-only. See Guardrails row (Group C). | — |
| Just-in-time credentials for high-impact / privileged actions | Operating › Privileges and authentication (also Appendix A › Design — ephemeral credentials) | Privilege | in-audience | — | gap | — | Privileged operations use static .env / long-lived GitHub tokens; no ephemeral or just-in-time credential issuance that expires when the job completes. |
PROP: jit-credentials-privileged-ops |
| Agent reputation and trust scoring; reduce trust on anomaly | Operating › Privileges and authentication | Privilege | N/A (operator-scoped) | — | N/A | — | Trust-scoring a fleet of running agents belongs to a service operator (AD-1a). | — |
| Cryptographic attestation — agent proves it runs expected/unmodified code | Operating › Privileges and authentication | Privilege | in-audience | configs/security/trusted-hooks.yaml, plugins/core-standards/skills/repo-audit/SKILL.md |
partial | — | Hook checksums plus symlink verify detect tampering via /repo-audit (manual); no cryptographic attestation of skills/agents at load. Attestation over git-versioned skills used by 4 trusted devs is the clearest over-engineering mismatch. |
deferred: disproportionate for a 4-dev trusted-team tool-user |
| Continuously verify identity/authorisation at runtime via a central policy-decision-point per request | Operating › Privileges and authentication | Privilege | N/A (operator-scoped) | — | N/A | — | A per-request PDP is a running-service control (AD-1a). | — |
Gap Register¶
Two gaps passed the proportionality test and were raised as intake proposals
(not activated specs — promotion is /vt-c-spec-from-requirements's job). This is
how US-2 acceptance is satisfied: per Constitution II and the
always-use-spec-from-requirements rule, a surviving gap becomes an intake proposal
with a rationale here, then is promoted to a SPEC-NNN through
/vt-c-spec-from-requirements — the audit does not activate specs directly.
A note on terminology, because the deferred set below mixes two statuses: most
deferred rows are partial (the control exists but is not enforced by default),
not gap (no control exists at all). Of the four gap rows, three feed the two
proposals (per-execution policy check + JIT credentials) and one is deferred:
(MCP output schema validation). So "deferred" ≠ "uncovered gap" — a SPEC-147 author
reading the list below should treat deferred partial controls as present-but-not-
enforced, not as missing.
| Gap | Why it survives proportionality | Proposal |
|---|---|---|
| Just-in-time credentials for privileged operations | A 4-dev tool-user genuinely holds static, long-lived secrets (.env, GitHub tokens) that privileged operations reuse; ephemeral credentials are a realistic, proportionate hardening. |
intake/pending/from-research/2026-07-05-jit-credentials-privileged-ops.md |
| Goal-drift / pre-execution spec-precheck | Unattended runs can pursue an objective that has drifted from the spec's acceptance criteria; a pre-execution objective-vs-AC check is proportionate and overlaps SPEC-132. | intake/pending/from-research/2026-07-05-goal-drift-spec-precheck.md |
Deferred controls (partial or gap, no proposal this round) — all 12 inline
deferred: rows above, each with its rationale: per-action HITL oversight,
sub-agent runtime sandbox, content-based injection heuristics, always-on audit
log, explicit review consensus, formal graduated-autonomy ladder,
deploy-the-deny-baseline, deep operation monitoring, continuous drift monitoring,
MCP output schema validation, general HITL irreversible-action gate, and
cryptographic skill attestation. (The human-oversight and monitoring levers each
appear in both a per-action and a general / always-on form — counted
separately here to match the table's rows.)
Consuming this audit (SPEC-147)¶
The KI-Richtlinie (SPEC-147, specified, not yet built) is the intended consumer.
This page is built to be citable: every Govt-Section cell is a stable prose
anchor into the source guidance (section titles, not durable IDs — they are
revalidated on re-audit if the guidance is revised), and every row carries a
Spec-Reference. When SPEC-147 is activated, the
forward-reference from its policy sections back into this table — and the
consistency check "KI-Richtlinie widerspricht nicht Govt-Empfehlungen" — are
applied then (tracked follow-up; this spec does not edit SPEC-147's files).
Re-audit trigger¶
Re-audit when Re-audit-After elapses, when the source guidance is revised, or
when VisiTrans usage shifts materially toward unattended operation (which promotes
several Condition: unattended rows). The staleness test surfaces calendar decay
as a non-gating WARN; it does not block unrelated work.
Related documents¶
- Security Overview — threat model, controls matrix (§4), residual risks (§5)
- AI & Agent Security — prompt-injection defence, tool-misuse, hallucination, MCP output gap
- Hardening Guide — deployment hardening checklist
- Incident Response — response procedures per incident type
- Source guidance (captured):
intake/knowledge/workflows/2026-05-04-careful-adoption-agentic-ai-services.md