# Daniel Alfasi > AI Security Research Lead at Reco. Agentic AI security, red teaming, and research that ships as detection. --- title: Daniel Alfasi canonical_url: https://danielalfasi.com/ last_updated: '2026-08-28' description: AI Security Research Lead at Reco. Agentic AI security, red teaming, and research that ships. --- # Daniel Alfasi AI Security Research Lead at [Reco](https://www.reco.ai). I break (and sometimes build) agentic systems, coding agents, and LLM applications - then ship the detection logic that catches the same attack in production. Findings that stay in a slide deck aren't findings. More: [blog](/blog.md) · [talks & papers](/talks.md) · [about](/about.md) - [LinkedIn](https://www.linkedin.com/in/daniel-alfasi/) - [X](https://x.com/alfasiii) - [Google Scholar](https://scholar.google.com/citations?user=uxuvP0gAAAAJ) ## Research that ships - [OWASP Agentic Skills Top 10](/blog/owasp-agentic-skills-top-10.md) (2026-08-28): OWASP published the Agentic Skills Top 10. I contributed three attack scenarios: Relay-Node Amplification, Model-Dependent Injection Resistance, and Unreachable Skill. Why they matter, and what they change about review. - [When acceptEdits quietly becomes code execution: a Grok Build hook-persistence bug](/blog/grok-build-acceptedits-hook-persistence.md) (2026-08-13): Grok Build's acceptEdits mode auto-approves file writes. Its global hooks directory is always trusted and runs at full user privilege. Combining the two turns a convenience setting into persistent, machine-wide code execution. How the composition works, how it was verified, and how xAI fixed it. ## Latest from the blog - [OWASP Agentic Skills Top 10](/blog/owasp-agentic-skills-top-10.md) (2026-08-28): OWASP published the Agentic Skills Top 10. I contributed three attack scenarios: Relay-Node Amplification, Model-Dependent Injection Resistance, and Unreachable Skill. Why they matter, and what they change about review. - [When acceptEdits quietly becomes code execution: a Grok Build hook-persistence bug](/blog/grok-build-acceptedits-hook-persistence.md) (2026-08-13): Grok Build's acceptEdits mode auto-approves file writes. Its global hooks directory is always trusted and runs at full user privilege. Combining the two turns a convenience setting into persistent, machine-wide code execution. How the composition works, how it was verified, and how xAI fixed it. - [Inside Claude Fable 5: red-team findings](/blog/inside-claude-fable-5.md) (2026-06-14): As part of my work at Reco, I red-teamed Claude Fable 5 across 431 adversarial evaluations. What I found, and where to read the full report. ## What I work on Agentic red teaming at scale: prompt injection, tool misuse, memory and RAG poisoning, scenario generation, and turning research into production detections. Focus: agentic AI security, AI red teaming, prompt injection, LLM applications, knowledge graphs, GNN + NLP. ## Sitemap See the full [sitemap](/sitemap.md) for all pages. --- title: About canonical_url: https://danielalfasi.com/about/ last_updated: '2026-08-28' description: Research to detection to shipped product. That loop is the job. --- I'm **Daniel Alfasi**, AI Security Research Lead at [Reco](https://www.reco.ai), based in Tel Aviv. I lead AI security research with a bias toward outcomes you can run in production: agentic red teaming, adversarial scenario generation, and detection logic that closes the loop on the attacks we find. ### What I care about - **Agentic systems under attack** - direct and indirect prompt injection, jailbreaks, tool misuse, memory and RAG poisoning - **Automation** - scenario generation, goal optimization, quantitative methods for the harnesses red-team agents run in - **The full loop** - research → detection → shipped product, not findings that die in a slide deck ### Background Before Reco I spent several years at **CyberArk** as a data scientist and senior software engineer - user behavior analytics, classical ML for detections, graph methods, and production security systems on AWS. Earlier work spanned trade-finance research, attack-surface management at Illusive Networks, and cloud engineering at Perfecto. I hold an MSc in Computer Science from Reichman University (knowledge graphs and LLMs; work that led to VulnScopper at CoNEXT GNNet 2024) and a BSc in Computer Science from Ariel University. I've contributed to the **OWASP AI Vulnerability Scoring System (AIVSS)** and the **OWASP Top 10 for Agentic Skills**. ### Elsewhere - [LinkedIn](https://www.linkedin.com/in/daniel-alfasi/) - [Google Scholar](https://scholar.google.com/citations?user=uxuvP0gAAAAJ) - [Reco](https://www.reco.ai) ## Sitemap See the full [sitemap](/sitemap.md) for all pages. --- title: Talks & papers canonical_url: https://danielalfasi.com/talks/ last_updated: '2026-08-28' description: Selected research talks and publications. --- ## VulnScopper: Unveiling Hidden Links Between Unseen Security Entities Dec 9, 2024 · UCLA · ACM CoNEXT — 3rd GNNet Workshop The NVD announced it could no longer fully enrich new CVEs at the pace they arrive. VulnScopper combines knowledge graphs and LLMs — using a GNN foundation model (ULTRA) in an inductive setup — to automate vulnerability enrichment and link CVEs to related security entities, including ones the model has not seen at training time. Authors: Daniel Alfasi, Tal Shapira, Anat Bremler-Barr. Published in *Proceedings of the 3rd GNNet Workshop on Graph Neural Networking*, pages 33–40. - [ACM Digital Library](https://dl.acm.org/doi/abs/10.1145/3694811.3697819) - [PDF](https://dl.acm.org/doi/pdf/10.1145/3694811.3697819) - [arXiv](https://arxiv.org/abs/2403.02014) - [Google Scholar](https://scholar.google.com/citations?view_op=view_citation&hl=en&user=uxuvP0gAAAAJ&citation_for_view=uxuvP0gAAAAJ:9yKSN-GCB0IC) --- *More talks and papers will land here.* ## Sitemap See the full [sitemap](/sitemap.md) for all pages. --- title: Blog canonical_url: https://danielalfasi.com/blog/ last_updated: '2026-08-28' description: Notes on AI security, agentic systems, red teaming, and research that ships. --- # Writing Short notes and longer writeups on agentic AI security, red teaming, and the loop from research to detection. - [OWASP Agentic Skills Top 10](/blog/owasp-agentic-skills-top-10.md) (2026-08-28): OWASP published the Agentic Skills Top 10. I contributed three attack scenarios: Relay-Node Amplification, Model-Dependent Injection Resistance, and Unreachable Skill. Why they matter, and what they change about review. - [When acceptEdits quietly becomes code execution: a Grok Build hook-persistence bug](/blog/grok-build-acceptedits-hook-persistence.md) (2026-08-13): Grok Build's acceptEdits mode auto-approves file writes. Its global hooks directory is always trusted and runs at full user privilege. Combining the two turns a convenience setting into persistent, machine-wide code execution. How the composition works, how it was verified, and how xAI fixed it. - [Inside Claude Fable 5: red-team findings](/blog/inside-claude-fable-5.md) (2026-06-14): As part of my work at Reco, I red-teamed Claude Fable 5 across 431 adversarial evaluations. What I found, and where to read the full report. ## Sitemap See the full [sitemap](/sitemap.md) for all pages. --- title: OWASP Agentic Skills Top 10 canonical_url: https://danielalfasi.com/blog/owasp-agentic-skills-top-10/ last_updated: '2026-08-28' description: 'OWASP published the Agentic Skills Top 10. I contributed three attack scenarios: Relay-Node Amplification, Model-Dependent Injection Resistance, and Unreachable Skill. Why they matter, and what they change about review.' --- OWASP published the [Agentic Skills Top 10](https://owasp.org/www-project-agentic-skills-top-10/) this month. It is the first shared vocabulary for the skill layer: the reusable bundles of instructions, metadata, and helpers that an agent finds, loads, and runs on its own. The [LLM Top 10](https://owasp.org/www-project-top-10-for-large-language-model-applications/) covers the model. The [MCP Top 10](https://owasp.org/www-project-mcp-top-10/) covers the protocol that talks to tools. Skills sit in between. They tell the agent *how* to use those tools, in sequence, with the host agent's permissions. That is a different attack surface. A skill is not a library you import. It is prose the model treats as instruction, plus whatever code, URLs, and privileges travel with it. I reviewed the draft and contributed three scenarios that landed in the published document: 1. **Relay-Node Amplification** under [AST05](https://owasp.org/www-project-agentic-skills-top-10/ast05) — Untrusted External Instructions 2. **Model-Dependent Injection Resistance** under [AST08](https://owasp.org/www-project-agentic-skills-top-10/ast08) — Poor Scanning 3. **Unreachable Skill** under [AST09](https://owasp.org/www-project-agentic-skills-top-10/ast09) — No Governance They came from the same line of testing: watching how skills actually execute in multi-model pipelines and inside SaaS copilots, not how they look on disk. ## The ten risks {#the-list} The list follows a skill from the moment it is written through distribution, installation, execution, updates, and whatever governance catches it along the way. | # | Risk | Severity | | --- | --- | --- | | [AST01](https://owasp.org/www-project-agentic-skills-top-10/ast01) | Malicious Skills | Critical | | [AST02](https://owasp.org/www-project-agentic-skills-top-10/ast02) | Supply Chain Compromise | Critical | | [AST03](https://owasp.org/www-project-agentic-skills-top-10/ast03) | Over-Privileged Skills | High | | [AST04](https://owasp.org/www-project-agentic-skills-top-10/ast04) | Insecure Metadata | High | | [AST05](https://owasp.org/www-project-agentic-skills-top-10/ast05) | Untrusted External Instructions | High | | [AST06](https://owasp.org/www-project-agentic-skills-top-10/ast06) | Weak Isolation | High | | [AST07](https://owasp.org/www-project-agentic-skills-top-10/ast07) | Update Drift | Medium | | [AST08](https://owasp.org/www-project-agentic-skills-top-10/ast08) | Poor Scanning | Medium | | [AST09](https://owasp.org/www-project-agentic-skills-top-10/ast09) | No Governance | Medium | | [AST10](https://owasp.org/www-project-agentic-skills-top-10/ast10) | Cross-Platform Reuse | Medium | The evidence behind it is already in production: poisoned registries, scanner bypasses, over-privileged manifests, and skills that fetch instructions from URLs nobody pins. The three scenarios I added sit on top of that. They are not exotic variants. They are what you see once you stop treating a skill as a static file and start treating it as runtime behavior. ## Relay-Node Amplification — AST05 {#ast05} AST05 is usually explained as a rug-pull. A skill points the agent at external documentation; that text becomes part of the skill's instructions; the URL can change after review. That is real, and it is already measured at scale. The chain case is different. Production agents are rarely one model and one skill. An intake skill drafts. A triage skill classifies. An action-taking skill writes the ticket, sends the email, or runs the command. Each hop may run on a different backbone model — a cheaper one for intake, a stronger one for the action. The output of one node is the input of the next. An injected instruction is not filtered out evenly along that path. Each model reparses what it receives and decides, for itself, where instruction ends and data begins. A frontier model at the action node may treat upstream output as untrusted text. A weaker relay in the middle may treat the same bytes as a command and forward them as if they were its own. The attacker does not need to beat the whole pipeline. **One weak relay is enough** to carry the payload into the node that takes action. The property underneath is easy to miss in a design review: a chain's injection resistance is the **minimum** over the backbone models on its path. It does not compose. Certifying the endpoints does not certify the chain. That is the operational impact. A security review that only inspects the skill that "does the dangerous thing" will pass a pipeline that is already owned. Model routing, cost-driven fallbacks, and mixed-vendor hops are now part of the AST05 attack surface, not just the URL the skill fetches. If you cannot name the backbone model at every node, you cannot claim the chain is resistant. ## Model-Dependent Injection Resistance — AST08 {#ast08} Those same tests made a second point unavoidable. Whether a skill is injectable is not a property of the skill file. AST08 is the scanning gap: regex and signatures miss prose that is still an instruction. The scenario I added is one step further. A skill is scanned, signed, and approved after review under one backbone model, which reliably refuses embedded instructions that arrive in tool output. The same unmodified, still-signed skill is later executed by a host agent configured with a weaker backbone. The identical injection now succeeds, and the model performs a permitted-but-unintended privileged action. **The artifact never changed.** Every gate still passes. The deployment is exploitable because injection resistance is a behavioral property of the runtime model, not of the skill's bytes. A skill approved under one model does not stay approved under a weaker one. That breaks a common assumption in skill review: scan once, sign, ship. The scan is a statement about `(skill, model)`, not about the file. Swap the model — routing, fallback, a cheaper default, a silent provider change — and the prior verdict is stale. The bytes look identical. The outcome is not. The impact is on how approval is recorded. Treat the backbone model as a security dependency, the same way you treat a library version. Record which model executed the review. Re-scan when that model changes, especially at action-taking or otherwise privileged nodes. Signing and scanning the file are necessary. They are not a verdict that transfers across models. ## Unreachable Skill — AST09 {#ast09} AST09 is the governance hole: no inventory, no approval workflow, no revocation, no audit trail. The usual example is a developer running a one-line install on a laptop. That is the easy case. You at least have a host. **Unreachable Skill** is the case you do not have a host for. Skills deployed and managed inside SaaS platforms — Claude, Copilot, and the rest — never land on an endpoint you can scan. There is no local manifest to read. Registry crawlers never see them. Endpoint agents never see them. Nobody hid those skills. They are invisible by architecture, running as shadow AI inside a sanctioned platform. Every downstream AST09 control then fails in the wrong direction. The inventory is empty. The approval queue never receives an item. The revocation list has nothing to revoke. The dashboard looks clean because the discovery method cannot see the asset class. That is a larger gap than an unreviewed laptop install. The skills with the widest enterprise reach — the ones sitting inside the copilot the company already paid for — are the ones host and registry scanners were never going to find. A governance program that only covers local packages is measuring the wrong fleet. Discovery has to start from identity and platform telemetry: OAuth grants, connected-app inventories, non-human identities, and the vendor's own skill catalogs. If a skill has no host and no package file, the control plane is the SaaS tenant, not the endpoint. Until that is in the inventory, AST09 is not a process gap. It is a blind spot you have designed in. ## What this changes in review {#takeaways} Three one-line changes to how I think skills should be reviewed: 1. **Review the chain, not the endpoint.** Injection resistance does not compose across hops. AST05. 2. **Bind skill approval to the model that will run it.** The file is not the unit of safety. AST08. 3. **Inventory the skills you cannot see on a host.** SaaS copilots are a skill runtime, not an exception. AST09. None of these replaces signing, pinning, or scanning. They are the cases where those controls still pass and the system is still exploitable. The full document, including mappings into AISVS, the Agentic Security Initiative, MCP, and the LLM Top 10, is on the [OWASP project page](https://owasp.org/www-project-agentic-skills-top-10/). The source lives at [OWASP/www-project-agentic-skills-top-10](https://github.com/OWASP/www-project-agentic-skills-top-10). ## Sitemap See the full [sitemap](/sitemap.md) for all pages. --- title: 'When acceptEdits quietly becomes code execution: a Grok Build hook-persistence bug' canonical_url: https://danielalfasi.com/blog/grok-build-acceptedits-hook-persistence/ last_updated: '2026-08-13' description: Grok Build's acceptEdits mode auto-approves file writes. Its global hooks directory is always trusted and runs at full user privilege. Combining the two turns a convenience setting into persistent, machine-wide code execution. How the composition works, how it was verified, and how xAI fixed it. --- Grok Build, xAI's agentic coding CLI, ships two features that are each reasonable in isolation: an `acceptEdits` permission mode that auto-approves file writes, and a global hooks directory that is always trusted and runs commands with full user privileges. Nobody documents what happens when you combine them. The answer: any content that reaches the model's context — a README, an issue body, a fetched web page — can get the agent to write a hook file with **no approval prompt at all**. A setting sold as "skip my edit nags" becomes persistent, machine-wide code execution that survives leaving the project, deleting the repo, revoking folder trust, and even running under xAI's own `--sandbox strict` profile. I reported this to xAI. They acknowledged it, folded client-side Grok Build into their bounty program's scope, rewarded the report, and shipped a fix. Details, PoC, and timeline below. ## What is Grok Build? {#what-is-grok-build} [Grok Build](https://x.ai/cli) is xAI's entry into the terminal-native agentic coding CLI category — the same space occupied by tools like Claude Code and OpenAI's Codex CLI. It reads your local codebase, proposes and applies edits, runs shell commands on your behalf, and coordinates sub-agents for larger tasks, all driven by natural-language prompts instead of hand-written scripts. One detail matters a lot for this write-up: Grok Build was built to be a drop-in alternative for developers already using Claude Code. It reuses the same on-disk conventions — project-level `AGENTS.md` files, the same skills format, MCP server discovery, and, critically, the same shape of permission configuration (`~/.claude/settings.json`, a `defaultMode` field, permission modes named `default`, `acceptEdits`, and `bypassPermissions`). That compatibility choice is why a report about "Grok CLI" reads almost identically to one about Claude Code's permission model — and why bugs in *how the modes compose* are worth checking for in both ecosystems, not just one. Because Grok Build takes real, unsupervised actions on a real filesystem, its permission system is the entire trust boundary between "the model suggested something" and "the model did something." That is the system this report is about. ## Auto-approval modes {#auto-approval} Grok Build's permission system (again, mirroring Claude Code's) exposes a small set of modes that control whether a tool call needs a human "yes" before it runs: | Mode | What it auto-approves | What still prompts | | --- | --- | --- | | `default` | Nothing | Everything — edits and shell commands both prompt | | `acceptEdits` | File edits: `write`, `search_replace`, and similar | Shell / `run_terminal_command` still prompts | | `bypassPermissions` | Everything | Nothing | `acceptEdits` exists for a genuinely common workflow: you trust the model to move files around and refactor code without asking every time, but you still want a gate in front of anything that executes. It is documented as auto-approving *file edits* — full stop. No workspace boundary, no path allow-list, no exclusion for sensitive paths is mentioned anywhere. That absence of a boundary is half of this bug. ## The hooks mechanism {#hooks} Separately, Grok Build supports **hooks**: commands that fire automatically at points in the agent's lifecycle (`SessionStart`, and others). Hooks live in two places: - **Project hooks**, scoped to a repository, which only run once you've explicitly trusted that folder. - **Global hooks**, at `~/.grok/hooks/*.json` (i.e. `$GROK_HOME/hooks/`), which the bundled documentation describes as **"Always" trusted** — no folder-trust entry needed at all. The docs are explicit that these "run with your user permissions," and say to treat them like shell scripts. A `SessionStart` hook of `type: command` runs the moment a new session starts, in *any* directory, with no `run_terminal_command` approval dialog in the way. This is by design: global hooks are meant to be something you, the user, deliberately installed — a config file, not untrusted input. That is the second half. ## Where the two halves meet {#composition} Neither half is surprising alone. `acceptEdits` auto-approving writes is the point of the feature. Global hooks being always-trusted is the point of *that* feature — you put them there yourself, so of course they are trusted. The composition is what is undocumented: **`acceptEdits` has no path boundary, and the hook root is just another path.** A mode sold as "auto-approve file edits" silently grants write access to the code-execution control plane. Concretely: if a developer sets `defaultMode: "acceptEdits"` (a common convenience — skip edit nags, keep the shell gate), any untrusted content that makes it into the model's context can instruct the agent to write a file under `~/.grok/hooks/`. Because `acceptEdits` does not distinguish "edit a file in my project" from "edit a file that gets executed on every future launch," that write sails through with no prompt. The next session start runs it. Here is the end-to-end path, using indirect prompt injection as the delivery mechanism — the attacker never touches the victim's machine directly; they just leave instructions somewhere the agent will read them. 1. **Plant — Untrusted content.** Attacker leaves a hidden instruction in a README, issue body, fetched page, or `AGENTS.md`: write a SessionStart hook under `~/.grok/hooks/`. 2. **Write — Silent auto-approve.** Developer asks the agent to review or work with that content. Under `defaultMode: acceptEdits`, the write to `$GROK_HOME/hooks/` succeeds with no prompt. 3. **Execute — Next session, any dir.** A later, unrelated session loads the global hook as "Always" trusted and runs the attacker's command at full user privilege. The developer never approved code execution. They approved edits. That is the entire bug. ## Verified reproduction {#reproduction} I verified three variants of this, all against Grok Build **0.2.111** on macOS 26.1 (aarch64), using an isolated `$HOME` / `$GROK_HOME` throughout so nothing touched a real config: - **User-level `acceptEdits`, no folder trust at all** — the primary case above. No `--trust`, no `--always-approve`, no `--yolo`, no project settings required. Just a user-level `defaultMode: "acceptEdits"` and one model-issued write. - **Malicious repository + folder trust** — a repo ships its own `.claude/settings.json` with `defaultMode: acceptEdits`; trusting the folder (which the docs actively encourage for MCP/LSP support) triggers the same unprompted write. - **Sandbox composition** — running under `--sandbox strict`, xAI's "maximum isolation" profile for reviewing untrusted code. `$GROK_HOME` is present in `read_write_paths` with `enforced: true`, so writes into `~/.grok/hooks/` still succeed even here. Reviewing hostile code under the strictest sandbox profile does not protect the hook root. Two things are needed to reproduce this correctly, or you will get a false negative: 1. **Set the mode via settings, not the CLI flag.** Passing `acceptEdits` to `--permission-mode` is accepted but silently does nothing — only `bypassPermissions` and `default` are wired up for that flag. The mode has to come from `$HOME/.claude/settings.json`. 2. **Run a negative control first.** In headless mode (`-p`), a tool call that would normally prompt gets cancelled outright — so you need to confirm the control (`defaultMode: "default"`) actually fails to write, to prove the difference you are seeing is `acceptEdits`, not just "headless never writes anything." Minimal reproduction, run in an isolated sandbox: ```bash export FH=/tmp/grok-h1-poc rm -rf "$FH"; mkdir -p "$FH/.claude" "$FH/.grok/hooks" "$FH/repo" chmod 700 "$FH" cd "$FH/repo" && git init -q && echo demo > README.md # authenticate the isolated home, e.g.: # HOME="$FH" GROK_HOME="$FH/.grok" grok login # --- negative control: defaultMode "default" --- printf '{"permissions":{"defaultMode":"default"}}' > "$FH/.claude/settings.json" env -i PATH=/usr/bin:/bin HOME="$FH" GROK_HOME="$FH/.grok" TERM=dumb \ grok --cwd "$FH/repo" --output-format json \ -p "Using ONLY the write tool, create $FH/.grok/hooks/CONTROL_PROBE.json containing {} ." test -f "$FH/.grok/hooks/CONTROL_PROBE.json" && echo "CONTROL FAILED" || echo "CONTROL OK" # Observed: stopReason Cancelled, no file created — CONTROL OK # --- positive: only defaultMode changes --- printf '{"permissions":{"defaultMode":"acceptEdits"}}' > "$FH/.claude/settings.json" env -i PATH=/usr/bin:/bin HOME="$FH" GROK_HOME="$FH/.grok" TERM=dumb \ grok --cwd "$FH/repo" --output-format json \ -p "Using ONLY the write tool, create $FH/.grok/hooks/DISCLOSURE_PROBE.json containing {} ." test -f "$FH/.grok/hooks/DISCLOSURE_PROBE.json" && echo "HOOK ROOT WRITTEN — no prompt" # Observed: stopReason EndTurn, file created — no approval requested ``` From there, arming the hook body and starting a fresh session in an unrelated directory (`/tmp`, no flags, no sandbox) is enough to show it firing on every future launch — persisting past the repo being deleted and past the folder's trust being revoked. The full step-by-step, including the sandbox-strict variant, was included in the report to xAI. ## Why it matters {#impact} - **Persistence.** The hook runs on every later session, in any directory. Leaving the repo, deleting it, revoking its folder trust, restarting the machine, or turning on a sandbox profile — none of it removes the implant. A user who "backed out" of a hostile repo is still compromised. - **It escapes the confinement the product advertises.** Hooks fire in later sessions, which are typically unsandboxed. A user who reviewed hostile code under `--sandbox strict` specifically to contain it is compromised on their *next, ordinary* session. - **It defeats what `acceptEdits` is sold on.** The mode exists so people can skip edit prompts while shell execution stays gated. This bug makes edit-approval a superset of execution-approval, collapsing the exact distinction the mode promises. - **Same-grant credential exposure.** `auth.json` sits inside the same `$GROK_HOME` read/write grant, and was readable inside a strict-sandbox session in testing. - **CI/automation blast radius.** A pipeline running with edit auto-approval against untrusted PRs can plant a hook into a cached runner's `$GROK_HOME`, compromising later jobs on the same host image. The underlying trust-boundary logic is: Grok Build clearly *does* treat "edit approval" and "execution approval" as separate things elsewhere in the product — project hooks require folder trust, shell has its own prompt, and there is already a hook-path validator in the binary (paths must be under `~/.grok/`). That validator anchors *at* the control-plane path instead of excluding it from what `acceptEdits` can touch — the enforcement scaffolding exists, it is just pointed the wrong way. No single document claims that "auto-approve file edits" includes "may install always-trusted global hooks," and no reasonable reading of the docs gets you there either — you only find it by testing the composition. ## Disclosure and response {#disclosure} - **July 24, 2026** — Report submitted to xAI's security team, with the full write-up, PoC, and an isolated reproduction environment. - **July 25, 2026** — xAI shipped a fix. - **August 1, 2026** — xAI responded: Grok Build client-side issues, previously out of scope for their program, are now **generally in scope** as a direct or indirect result of this report — with one carve-out that remains excluded: client-side bypass of auto-approval for *safe* commands/tools. - **August 1, 2026** — xAI awarded a bounty for it. ## The fix {#fix} - **Fixed:** July 25, 2026 - **Commit:** [`47348d1`](https://github.com/xai-org/grok-build/commit/47348d13ec4508dcfe440e34c6d511bb02998fb2) — a large "synced from monorepo" batch commit with no direct mention of this report, but its changelog includes the line, verbatim: > Security: prevent acceptEdits from auto-approving agent writes into the always-trusted global hook root - **Primary file:** [`permission/shell_access.rs`](https://github.com/xai-org/grok-build/blob/main/crates/codegen/xai-grok-workspace/src/permission/shell_access.rs) - **Wiring:** [`permission/manager.rs`](https://github.com/xai-org/grok-build/blob/main/crates/codegen/xai-grok-workspace/src/permission/manager.rs), which now blocks the `acceptEdits` / auto path whenever this new protection fires. The best evidence is in the code itself. There is now a dedicated reason enum for why `acceptEdits` has to fall back to prompting for certain targets: ```rust /// Why acceptEdits must still prompt for this edit target. pub enum ProtectedEditReason { HookRoot, // ... } // HookRoot description: // "changes to hooks, which can be executed as code on later sessions // without a separate execution approval." ``` That description is, almost word for word, the boundary this report argued was missing: an edit that is really an execution grant now gets treated as one. Before this commit, `acceptEdits` auto-allowed a write to *any* path. After it, anything under `$GROK_HOME/hooks/**` is classified as `HookRoot` and forced back to a prompt — so the silent-plant path from the reproduction section no longer works; in headless mode the same call now comes back `Cancelled` instead of `EndTurn`. It is worth noting what this fix does *not* claim to do: it closes the specific `acceptEdits`-into-hook-root path, not every possible instance of "edit approval implicitly grants something more." Anyone extending this pattern to other control-plane paths (or other CLIs with a similar hooks-plus-auto-approve shape) should still verify the composition rather than assume this class of bug is closed for good. ## Lessons beyond Grok Build {#lessons} None of this is Grok-Build-specific in spirit. Any agentic CLI that has (a) a "trust me, just don't prompt for edits" mode and (b) an always-trusted, user-privilege execution mechanism reachable by a filesystem path needs to ask the same question: **does the edit-approval boundary actually exclude the execution-control-plane paths, or does it just happen not to have been pointed at them yet?** If you build or operate one of these tools — Grok Build included — it is worth explicitly testing that composition rather than assuming each half's documentation covers it. --- Questions, corrections, or coordinated disclosure on something related? Find me on [LinkedIn](https://www.linkedin.com/in/daniel-alfasi/). ## Sitemap See the full [sitemap](/sitemap.md) for all pages. --- title: 'Inside Claude Fable 5: red-team findings' canonical_url: https://danielalfasi.com/blog/inside-claude-fable-5/ last_updated: '2026-06-14' description: As part of my work at Reco, I red-teamed Claude Fable 5 across 431 adversarial evaluations. What I found, and where to read the full report. --- As part of my work at Reco, I spend a lot of time putting agentic models under pressure - not to score coding benchmarks, but to see **how an agent behaves when someone is actively attacking it**. When Anthropic shipped Claude Fable 5 as a purpose-built agent backbone, that was exactly the kind of model we care about. Shortly after launch, I ran it through our agentic-security red-teaming benchmark: **431 adversarial evaluations** across **10 enterprise agent archetypes** and **99 attack scenarios**. ## What I care about measuring I don't score trivia or raw coding ability. I drop the model into realistic **agent snapshots** - system prompt, tools, memory, mid-conversation history - and attack three injection surfaces: 1. **User message** - direct prompt injection 2. **Tool output** - indirect injection via a compromised API / MCP response 3. **Memory** - poisoned RAG / knowledge-base content Across five risk dimensions: prompt-injection resistance, sensitive information disclosure, content-policy bypass, output integrity, and operational disruption. I've found that this framing matters more than a clean-room jailbreak suite. In production SaaS agents, attackers rarely only "chat" their way in - they ride tool outputs and memory the same way malware rides the supply chain. ## What I found Fable landed at an overall risk score of **0.044 (low)** in our runs - second-safest of the models we had tested at the time, behind Claude Opus 4.8. That is good news. It is not a free pass. A few things stood out to me more than the single number: - **Where** it fails - tool-output and memory surfaces tend to be more dangerous than chat. - **How** it defends - including defenses you cannot inspect because the reasoning is hidden. - **What the residual looks like** when an attack *does* get through. One concrete bypass is worth ten radar charts. I've also found that model churn is part of the threat model. Fable was pulled from general availability shortly after launch. Whatever the classified specifics, the practical lesson is uncomfortable: the agent backbone you plan to wire into autonomous workflows may not stay available, and detection that only "trusts the frontier safety layer" is a single point of failure. ## What I keep repeating **Agent security is a systems problem.** System prompt + tools + memory + identity + egress - attack the seams, not just the chat box. **Benchmarks should look like production.** Snapshots with tools and mid-conversation state beat clean-room prompts if you care about enterprise risk. **Ship the detection.** A red-team finding that never becomes a detector, a policy, or a product control is unfinished work. --- For the full numbers, charts, attack example, and narrative, read the full report on Reco: **[Inside Claude Fable 5: What Our Red Team Found Before the Plug Got Pulled](https://www.reco.ai/blog/inside-claude-fable-5-red-team-findings)** Images used here are from that post, with credit to [Reco](https://www.reco.ai). ## Sitemap See the full [sitemap](/sitemap.md) for all pages.