Security audit
Security checks across malware telemetry and agentic risk
The skill is transparent about local LLM governance, but it can change or delete local models and policy without a built-in read-only mode or approval gate.
Install only in an environment where the agent's account is allowed to manage the target local LLM runtime. For observe-only use, run it against a runtime/account that cannot modify the model store or expose only scan/observe tools. Treat ~/.ai-guardian as sensitive local state, and avoid long-lived master passwords in environment variables where shell history, child processes, CI logs, or process inspection may expose them.
## Authorization is not this tool's job — decide it where it belongs Whether a write should happen is your decision, or the account's. The tool does not gate it — there is no read-only switch and no approval prompt to configure. The two right places to control read vs write: - **The host and account you run under.** Point the tool at a runtime the account
Every tool call is audited to a local SQLite DB at ~/.ai-guardian/audit.db (relocatable via AI_GUARDIAN_AIOPS_HOME); the OBSERVED local-LLM usage log is a SEPARATE DB at ~/.ai-guardian/usage.db. Zero-config: ai-guardian defaults to the local Ollama at http://localhost:11434 with no token. Ollama endpoints usually run open on a trusted host, so a bearer token is OPTIONAL; when one is supplied it is stored ENCRYPTED in ~/.ai-guardian/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. The store is unlocked by a master password from AI_GUARDIAN_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var AI_GUARDIAN_<TARGET_NAME_UPPER>_TOKEN is still honoured as a fallback with a deprecation warning (migrate with 'ai-guardian secret migrate'). The prompt scanner is deterministic and offline (no I/O, no network); route-through guards (guarded_generate/observe_chat) call Ollama only if the prompt's risk band is below block_threshold AND the model is allowed. The raw prompt is never stored — only its length + redacted findings. State-changing operations: remove_model (high, dry-run + double confirm at the CLI, undo re-pull); pull/unload/allowlist/denylist/pin/guarded writes are medium. All write tools pass through the @governed_tool decorator (pre-check + budget guard + audit + risk-tier label). Webhooks: none — no outbound network calls beyond the configured Ollama REST API. Transitive dependencies: httpx (HTTP client) and the MCP SDK. No post-install scripts or background services. Validation status: the scanner/policy/risk-band are deterministic offline logic; the core Ollama route-through (real generation + policy deny + undo capture) was exercised against a live Ollama 0.24.0 on 2026-07-13, while the remaining runtime API paths and the OpenAI-compatible dialects are exercised against mocked responses (see docs/VERIFICATION.md). Content governance is opt-in route-through in v0.1 ...[truncated 24 chars]
## Governance & Safety The skill delivers reads and writes and records them; it does **not** decide whether a write is permitted. That is your agent's judgement, or the permission of the host and account you run it under (point it at a runtime the account cannot administer, or hand the agent only the scan/observe tools). There is no read-only switch, deny-rules file, or approval gate — content governance (the
## 5. Audit-annotation env vars (optional) The skill does not decide whether a write is permitted — that is the agent's judgement or the permission of the host/account you run it under. If you want the audit trail to record *who* ran a destructive op and *why*, set these; they are recorded on the row, never required, and gate nothing:
VirusTotal findings are pending for this skill version.
Detected: suspicious.prompt_injection_instructions
