Security audit
Security checks for vulnerabilities and agentic risk
The skill explains local account balances through read-only queries, with explicit limits preventing its shared examples from authorizing ledger changes.
The agent will read sensitive financial records to explain the selected account and period. Confirm the intended ledger when discovery is ambiguous. Shared import and editing examples do not authorize changes during this workflow; any ledger modification belongs in a separately requested task.
The command uses add transaction and supplies transaction fields plus --into "$target". This is a ledger-modifying operation, not a read-only account-movement query, and directly contradicts the declared scope.
The command uses add balance with --date, --account, --amount, and --into, indicating a ledger-writing operation rather than a query. This directly contradicts the read-only declaration. The supplied chunk does not establish that it plugs a discrepancy, but its entry-recording behavior alone is a clear mismatch.
The command uses add transaction with --posting and --into, which creates a ledger entry. This directly contradicts the declared strictly read-only purpose and explicit exclusion of recording entries.
The command uses the mutating add close operation rather than a query. Its --date, --account, and --into arguments configure an account-closing entry. This directly contradicts the read-only promise and the exclusion of recording entries. The --json and --no-input flags do not make the operation read-only.
The command uses add note with --into "$target", which records ledger content rather than querying or explaining balances. This directly conflicts with the declared read-only constraint and exclusion of recording entries.
The command uses the mutating add open operation, not a balance or movement query. Its --into argument specifies a destination for the new directive. This directly contradicts the declared strictly read-only behavior and exclusion of recording entries; --json and --no-input do not make the operation read-only.
The command bea --file "$ledger" --json --no-input add transactions --from "$batch" --into "$target" requests transaction insertion rather than read-only balance analysis. The JSON and noninteractive flags do not change the operation's write-oriented purpose. This directly contradicts both the read-only restriction and the exclusion of recording entries.
The command uses the mutating add price operation with date, commodity, amount, and destination arguments. This directly conflicts with the declared read-only behavior. The --json and --no-input flags affect output and interaction, not whether the operation writes data.
The command invokes add open, a ledger-modifying operation, rather than a read-only query. Its --into argument specifies the write target. This directly conflicts with the declared prohibition on recording entries and the strictly read-only scope.
The command's import operation and explicit --apply flag perform a write-oriented workflow that directly conflicts with the declared read-only purpose and exclusion of recording entries. This is a substantive capability mismatch, not a supporting implementation detail.
The supplied command performs an import operation with a destination target. This is materially different from the declared read-only analysis and introduces data-ingestion or output-writing behavior not disclosed by the description. The --no-input and --json flags do not make the import read-only.
The supplied command invokes price refresh, not a read-only balance or transaction query. Refreshing price data goes beyond the declared account-movement explanation workflow and conflicts with its read-only guarantee. The JSON and no-input flags control output and interaction; they do not make the refresh operation read-only. The snippet does not establish exactly where refreshed data is persisted.
The reference instructs the agent to apply CSV imports with --apply and provides a fallback that adds transaction batches, contradicting the skill's strictly read-only scope and explicit exclusion of recording entries. If followed during a roll-forward analysis, this workflow could alter the financial ledger and undermine the integrity of the balances being explained. Approval, duplicate review, and validation requirements reduce accidental-write risk but do not resolve the authorization boundary violation.
This reference contains operational instructions for importing, categorizing, approving, and writing transactions, which conflict with the enclosing skill's strictly read-only roll-forward scope. If an agent treats these instructions as applicable, it could expand an explanation request into a ledger-modification workflow, potentially duplicating or altering financial records. Approval and duplicate-review safeguards reduce the risk, but do not resolve the scope conflict; the content appears to be misplaced shared documentation rather than a deliberate attack.
No suspicious patterns detected.
