Hey Ruggy, Nick:
I’m not sure this helps, but if you’re into Claude with Coda MCP, here are some techniques I’ve had pretty good success with for creating added safety measures. My examples here are generic. Applying them in practice does require a little effort, but they each work pretty well. Based on my experimentation, we’ve been able to instrument hook strategies to provide additional safety and security.
The security issues raised by Nick center around the current “all-or-nothing” nature of the Coda MCP integration:
- No explicit separation of Read/Write permissions (the connection defaults to full read+write).
- No way to restrict MCP access to specific documents or folders.
- Lack of an audit trail to monitor what the AI is doing via MCP.
While we wait for Coda to implement server-side granular Role-Based Access Control (RBAC), we can use Claude Code Hooks to build a Client-Side Security Gateway.
Hooks act as deterministic middleware that intercepts the agent’s operations before they execute. By using them, you completely shift the security perimeter to the client—ensuring the LLM is physically blocked from performing unauthorized actions, regardless of what the underlying Coda API token permits.
This is a 3-part blueprint leveraging PreToolUse and PostToolUse hooks in Claude settings (settings.json) to solve these exact gaps:
1. Forcing Read-Only Access via Pattern Matching
Since the Coda MCP exposes specific internal tool names for different actions (e.g., mcp_Coda_page_read vs. mcp_Coda_page_update), we can use a PreToolUse hook with a regex matcher to intercept and block any tool indicative of a “Write” operation.
{
"hooks": [
{
"name": "Enforce Coda Read-Only",
"event": "PreToolUse",
"matcher": "^mcp_Coda_.*(create|update|delete|manage|add|modify|duplicate|upload)$",
"action": {
"type": "Command",
"command": "echo 'SECURITY GUARDRAIL: Write operations to Coda are restricted. Read-only actions allowed.' >&2 && exit 1"
}
}
]
}
How it solves the issue: If Claude tries to update a table row or add a comment, the hook catches it via the matcher, runs the bash exit command (status 1), and halts the execution, effectively sandboxing the agent in a read-only state.
2. Document/Folder Level Restrictions (Allow-listing)
To solve the issue of restricting MCP access to specific documents, we can route all Coda MCP tools through a localized validation script. The payload of a PreToolUse hook contains the exact arguments the tool is about to use—which almost always includes a uri containing the Coda docId.
{
"hooks": [
{
"name": "Coda Document Permission Check",
"event": "PreToolUse",
"matcher": "^mcp_Coda_.*",
"action": {
"type": "Command",
// The script receives the JSON payload of arguments, including the target docId
"command": "./scripts/validate-coda-access.sh \"$TOOL_ARGS\""
}
}
]
}
How it solves the issue: The bash (or Node/Python) script parses the requested uri (e.g., coda://docs/{docId}/...) and checks it against an approved vault of allowed docIds. If the agent tries to scrape a document not on the list, the script terminates the call before the MCP server even registers the request.
3. Auditing and Monitoring
Since workspace admins cannot currently see what MCP is doing on the Coda side, we can log the activity deterministically on the agent side using a PostToolUse hook.
{
"hooks": [
{
"name": "Coda Audit Logger",
"event": "PostToolUse",
"matcher": "^mcp_Coda_.*",
"action": {
"type": "Command",
"command": "echo \"$(date): Tool $TOOL_NAME executed with args: $TOOL_ARGS\" >> ~/.logs/coda_mcp_audit.log"
}
}
]
}
(Alternatively, you could use an HTTP hook action to fire a payload directly to a centralized logging server, or even isolated to a totally separate Coda doc used specifically for auditing! Use Code webhooks for this - it really works well.)
4. Locking Down Hooks
There are several methods of ensuring hooks are secure and tamper-resistant. Happy to share them if this is a useful pattern.
While Antigravity lacks built-in client-side Hooks to sandbox tool execution deterministically, the MCP protocol itself is client-agnostic . Building an MCP Proxy Wrapper is the ultimate way to enforce Coda security across both Claude Code and Antigravity simultaneously, ensuring that no AI agent can bypass the rules regardless of their local configuration.
Zero Trust
By relying on Hooks, you establish a Zero-Trust Executor. Hooks are deterministic and exist entirely outside the model’s “thinking” loop, meaning the model cannot decide to ignore or prompt-inject its way around them. Even if an overzealous user connects a Coda token holding full admin privileges, the Claude Hooks act as an impenetrable firewall, buffering the overly-permissive Coda MCP and enforcing the strict constraints you define natively within your CLI.
