Part VI — Trust and Troubleshooting

This part covers Chapters 26–28: the security and privacy boundary, troubleshooting and FAQ, and a set of proven best practices.

26. Security and privacy

AVL Code treats user data as sensitive by design.

26.1 Where data lives

• Sessions are stored locally and never uploaded to a third party.
• Only when you explicitly invoke a model does the corresponding message content go to the chosen provider over their protocol.
• Decompilation, on demand, sends relevant disassembly to the decompilation model; only fires when you explicitly call it.

26.2 Credential management

• Sign-in credentials, model API keys, external-service credentials are all stored protected on disk.
• Provider API keys and external-service credentials are never sent to the model alongside conversation content; only attached to the relevant tool call's HTTP headers.

26.3 Special protection of the samples directory

samples/ is hard-isolated; execution-type tool calls in it are unconditionally rejected — this policy can't be loosened.

26.4 Audit

Every tool call, every approval decision and every plan edit is recorded as its own card — usable as a complete audit trail.

26.5 Network access

• AVL Code talks to the account service to fetch login state and shared quota.
• It talks to the model provider you've selected per your model config.
• Only when you use SBOM online audit / sync does it reach the OSV vulnerability database (api.osv.dev, the OSV dump bucket) and the CISA KEV catalog; air-gapped sites can point these at an internal mirror or use offline import, with no network access at all.
• It doesn't actively phone home for analytics.

26.6 Upgrade safety

Upgrade packages are signature-verified; failure auto-rollbacks, defeating man-in-the-middle replacement.