Design VBA execution support for Excel add-in agent
Session from pi-for-excel-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Explore whether the agent could execute VBA macros in Excel, how it would fit alongside existing Python/tmux bridges, and what security posture that implies.
- +0Prompt · +0Can the agent use VBA? Could we allow it to?
- +0mAgent did · +0mExplored the tool registry, capability docs, and Office.js execution tool; concluded VBA isn't supported today but could be added via a local bridge with a run_vba_macro tool and safety gates.
- +2mPrompt · +2mWe have a bridge for running Python (and maybe JS?) - can we check?
- +2mAgent did · +2mRead python-run.ts, python-transform-range.ts, tool gate wrappers and package.json; confirmed a Python bridge and a tmux bridge exist, with no separate JS bridge.
- +4mPrompt · +4mShould we bundle VBA support into the Python bridge?
- +4mAgent did · +4mRecommended sharing the bridge process/binary but giving VBA its own endpoint and tool (vba_run) with separate approval gates, kept Windows-only initially.
- +11mPrompt · +11mIs our security posture more strict for VBA (macro allowlist) than for Python? Seems inconsistent.
- +11mAgent did · +11mReviewed pyodide runtime, security threat model doc, execution mode settings, and gate tests; concluded an allowlist-only VBA approach would be stricter than Python's one-time bridge approval.
- +13mIntervention · +13mPushed back that a macro allowlist isn't actually 'cheap' since it implies writing and maintaining first-party macros.Why: I wanted the agent to recognize that maintaining an allowlist of our own macros is real engineering cost, not a free security control.
- +15mIntervention · +15mClarified the real goal: the agent should write and run its own VBA scripts on the fly, like it does with Python, not call pre-approved macros.Why: The agent's allowlist-of-macros framing missed the point - I wanted VBA to behave like the Python code-exec tool, not a fixed macro catalog.
- +17mOutcome · +17mSession ended with agreement that native Python bridge execution and VBA exec are equivalent risk, implying a single 'native_code_execution' policy bucket with per-call approval and no YOLO bypass across both.
Next time I'd open with the real requirement up front: 'agent writes and runs arbitrary VBA like it does Python' instead of letting the conversation drift into macro-allowlist framing first. My interventions calling out that a macro allowlist isn't cheap, and that VBA should behave like a code-exec tool rather than a fixed macro catalog, are what steered this from a narrow allowlist design into the right unified risk-tier conclusion. No code was written this session - it was pure design exploration, but it converged on a clear, consistent security model.