Security audit
Security checks for vulnerabilities and agentic risk
The reporting workflow explicitly protects your ledger from edits; shared editing examples do not authorize changes within this skill.
This skill reads sensitive financial records. Keep its access limited to the intended ledger and use separate skills for edits or imports. Its hosted-ledger wording is inconsistent, so enable connected-server reporting only if you want that route.
The command performs a transaction-add operation rather than a read-only query or report. This directly contradicts the declared read-only restriction and explicit exclusions of transaction recording and ledger edits.
The supplied command creates a transaction instead of querying or reporting on existing ledger data. This directly contradicts the read-only restriction and the explicit exclusions of transaction recording and ledger edits.
The command performs transaction addition rather than querying or reporting. This directly contradicts the declared read-only purpose and the explicit exclusions of transaction recording and ledger edits.
The add balance subcommand and --into "$target" specify a ledger-writing operation. This directly contradicts the declared strictly read-only purpose and explicit exclusions of reconciliation and ledger edits. The --json and --no-input flags do not make the operation read-only.
The command invokes bea import, not a query or report. Its mapping and transformation options support converting exported data into transaction records, and --into "$target" directs the import to a destination. This conflicts with the declared read-only scope and explicit exclusion of transaction recording and ledger edits.
The command uses add open and an --into target to write ledger content rather than query or report on existing data. This directly conflicts with the declared read-only restriction and explicit exclusion of ledger edits. The --json and --no-input flags do not make the operation read-only.
The command is a ledger-writing operation rather than a query or report. Its add open subcommand and --into target directly conflict with the description's strictly read-only requirement and explicit exclusion of ledger edits. The --no-input and --allow-errors flags do not make the operation read-only.
The command invokes bea import ... --into "$target" ... --apply, which performs a data-import operation with changes applied to the specified target. This is materially different from read-only ledger analysis and conflicts with the explicit exclusion of recording transactions and editing ledgers.
The command invokes add close, a ledger-writing operation rather than a query or report. This directly contradicts the declared strictly read-only scope. The --json and --no-input flags affect output and interaction, not whether the operation modifies the ledger.
The command uses the mutating add price operation with --into "$target", rather than a read-only query or report. The --json and --no-input flags control output and interaction; they do not make the operation read-only.
The command's add note operation and --into "$target" argument indicate a ledger-writing capability. Adding a note is a ledger edit even if it does not record a financial transaction, directly contradicting the declared read-only scope and exclusion of ledger edits.
The price refresh subcommand updates price data rather than merely inspecting existing ledger information. This conflicts with the explicit read-only restriction. The --json and --no-input flags control output and interaction; they do not make the refresh operation read-only.
These sections provide executable recipes for opening accounts and recording batches or individual transactions, including instructions to resume an interrupted write workflow. Those capabilities are unjustified for beancount-ask, whose manifest explicitly requires read-only operation and excludes transaction recording and ledger edits; user confirmation does not bring them within scope.
The reference explicitly instructs the agent to execute an import with --apply and describes an alternative transaction-writing batch workflow, contradicting the skill's strictly read-only scope and exclusion of recording transactions. If followed, these instructions could modify financial records through a skill users expect only to query them; approval and duplicate-review safeguards reduce accidental errors but do not resolve the scope violation.
The manifest explicitly excludes recording transactions and ledger edits, but this fallback workflow directs the agent to insert approved directives and account opens into ledger files. Requiring confirmation and preserving formatting do not make these mutations consistent with the skill's read-only purpose.
The manifest at L03 limits the skill to local ledgers and explicitly says to skip ledgers hosted on Beancount.io. L54 instead instructs the agent to use the connected hosted server's spending-report prompt and tools, extending the workflow to remote ledger access rather than stopping at the declared boundary.
The reference explicitly directs beancount-ask to use a connected Beancount.io server and its spending-report prompt, despite the skill's stated exclusion of hosted ledgers. This conflicting instruction can redirect the agent into out-of-scope access to sensitive financial information; however, the text does not establish unauthorized server access, credential theft, or exfiltration to an attacker.
The workflow directs creation of durable rules files in the ledger repository and account-opening entries, both of which exceed the declared read-only boundary. Although it requires confirmation, it can still lead an analysis-only agent to alter repository configuration and ledger structure, potentially affecting future imports.
The reference gives operational instructions for importing transactions and proposes adding metadata to existing entries, contradicting this skill's explicit read-only scope and exclusion of ledger edits. If the agent treats these reference instructions as authority, an analytical request could drift into financial-record modification or duplicate transaction creation. Explicit consent requirements reduce the risk of silent writes, but do not make these operations appropriate for this skill.
No suspicious patterns detected.
