Sage: an Agent Detection and Response layer for AI coding assistants

What Sage actually guards, and who it is built for

Sage sits between an AI coding assistant and the tools that assistant wants to call. The README describes it as intercepting "tool calls, shell commands, URL fetches, file writes" and checking them against multiple detection layers before they run. That is the whole product in one sentence, and it is narrower than the phrase "Agent Detection & Response" might suggest. Sage does not run the agent in a container, does not restrict filesystem permissions at the OS level, and does not sandbox the process. It makes a decision at the point where a tool call is proposed and lets the host application act on that decision.

The audience follows from the integration list. Sage ships as a Claude Code plugin, a Cursor extension, a VS Code extension, an OpenClaw plugin and an OpenCode plugin. If you use one of those five and nothing else, the install path is documented. If you use a different agent framework, the README does not offer a generic SDK route, so you would be reading packages/ and the Developer Guide to see whether a custom host is feasible. That is a real constraint for anyone running an in-house agent loop.

The threat model is worth stating plainly. The primary adversary is not a remote attacker with network access to your machine. It is the agent itself: an assistant that has been talked into running a destructive command by content it fetched, or that proposes `chmod` on a path it should not touch. The repository's own demo asset is named `block-cc-chmod.gif`, which tells you what the maintainers consider the canonical case.

The decision pipeline: local rules first, model and cloud second

The repository documents the mechanism across three files: docs/decision-pipeline.md covers "signal sources, policy model, evaluation order", docs/prompt-injection.md covers the two-tier injection defence, and docs/audit-log.md covers the on-disk JSONL schema. From those descriptions the shape is a layered evaluator. A tool call arrives, a set of signal sources produce opinions, and a policy model combines them into a decision.

The signal sources named in the README are distinct in kind, which matters for latency and for offline behaviour. Local heuristics are 300+ YAML threat patterns stored in the `threats/` directory, covering dangerous commands, suspicious URLs, credential exposure and obfuscation. These run in-process with no network round trip. URL reputation is explicitly "cloud-based detection of malware, phishing, and scam URLs", so that layer requires connectivity and sends the URL somewhere. Prompt injection detection is described as two-tier: heuristics plus a fine-tuned ML model, which the repository's `package.json` corroborates through an `onnxruntime-node` build dependency and an `eval:pi` script that runs `packages/core/scripts/eval-pi-accuracy.mjs`. Package supply-chain checks look at registry existence, file reputation and package age for npm and PyPI.

The layering is a sensible design and also the main thing to interrogate. Because rules live in YAML under `threats/`, you can read exactly what will be blocked and you can add your own. Because the ML model runs through ONNX Runtime, the injection classifier is local. But the URL reputation layer is not, and the README does not describe a fallback policy when that lookup fails. A network failure and a clean verdict are not the same thing, and the documentation as given does not say how the pipeline distinguishes them.

Installing Sage in Claude Code and running a first blocked command

The README points at ai.gendigital.com/sage for the latest instructions and gives platform-specific guides. For Claude Code it requires Node.js >= 18 and uses the plugin marketplace. Two slash commands do the work, run from inside Claude Code:

/plugin marketplace add https://github.com/gendigitalinc/sage.git
/plugin install sage@sage

After the second command completes, Sage is registered as a plugin for the session. The README states that plugin scanning runs at session start, so the first observable behaviour is a scan of installed plugins rather than a prompt.

To see the guard in action, ask the agent to run something the `threats/` rules should catch. The repository's own demo shows a `chmod` command being blocked in Claude Code. If you want to inspect what fired, docs/audit-log.md documents an on-disk JSONL schema with entries, signals and content, so the log is the place to look after a block rather than the terminal output.

For OpenClaw the install is an npm-based plugin command:

openclaw plugins install @gendigital/sage-openclaw

OpenCode takes a different route: add the package to the plugin array in `~/.config/opencode/opencode.json`.

{
  "plugin": ["@gendigital/sage-opencode"]
}

Cursor and VS Code both install from their marketplaces as the "Gen Sage" extension. One caveat before you start: the README notes that Sage "may appear under a different product name (e.g., Norton Sage, Avast Sage) depending on how it was installed", and points at docs/branding.md. If you are auditing an installed extension and the name does not match, that document is the explanation.

Where Sage stops being the right tool

The clearest limitation is architectural. Sage decides whether a tool call should proceed; it does not prevent the process from doing the thing anyway. If an agent has a path to execute code that does not route through an intercepted tool call, or if the host application chooses to ignore the verdict, the guard does not apply. Anyone who needs containment rather than screening should be looking at process isolation, not at a plugin.

The second limitation is platform coverage in the AMSI integration. The README states that Windows Antimalware Scan Interface support works on Windows and on WSL via PowerShell interop, and is a "no-op on macOS and non-WSL Linux". If your fleet is macOS or native Linux, that entire detection layer contributes nothing, and you should evaluate the remaining layers on their own merits.

The third is the cloud dependency. URL reputation is cloud-based by definition. In an air-gapped build environment or a restricted network, that layer is unavailable, and the README as given does not document a degraded-mode policy. The privacy section is deferred to docs/user-guide.md#privacy, which is the document to read before deploying into an environment with data-handling obligations.

Finally, there is the rule corpus licensing split. The repository root carries Apache-2.0, but `threats/` is separately licensed under Detection Rule License 1.1. Two licences in one repository is not unusual for a detection product, but it means a fork that wants to redistribute the rules needs to read the second licence, not the first.

How Sage differs from a general-purpose agent sandbox

The obvious alternative is to skip detection entirely and run the agent inside a container or a VM with a read-only mount of anything you care about, dropping network access to a proxy you control. That approach is strictly stronger for containment: a command that never reaches the host cannot damage the host, regardless of what any classifier decides. The cost is friction. Every legitimate write needs a mount, every legitimate fetch needs a proxy rule, and the agent's usefulness drops in proportion to how tightly you close the environment.

Sage inverts that trade-off. It leaves the agent with full access and inserts a check at the tool-call boundary, so normal work stays fast and only flagged calls are stopped. The price is that correctness depends on the classifier and on the host honouring the verdict.

A second alternative is to write your own hook. Claude Code and the other hosts expose interception points, and a team with a small set of internal rules could implement a blocklist in a few hundred lines. What Sage adds over that is the 300+ pattern corpus, the injection model, the package age and registry checks, and the audit log schema. What you give up is control over the rule set's evolution and the ability to reason about every line of it. For a team whose threat model is one specific destructive command, a hand-written hook is cheaper. For a team that wants npm and PyPI age checks on every install the agent proposes, writing that yourself is a project, not an afternoon.

Maintenance, release cadence and licence obligations

The repository is not archived, and the last push was on 2026-09-10. The release history shows v0.13.0 on 2026-09-10, v0.12.0 on 2026-08-13 and v0.11.0 on 2026-06-18, so the project has shipped three releases in roughly three months. The version numbers are still in the 0.x range, which is worth noting for anyone who needs API stability guarantees: a 0.x line can change shape between minor versions, and the repository uses Changesets (`.changeset/`, `@changesets/cli`) plus a `version` script that runs `changeset version && node scripts/sync-manifests.mjs`, so version bumps are automated and the changelog is the artefact to read before upgrading.

Upgrade cost depends on which surface you installed. The Claude Code plugin, the Cursor extension and the VS Code extension update through their host mechanisms. The OpenClaw and OpenCode packages update through npm. If you have added custom rules to `threats/`, a release that changes the rule format is your upgrade risk, and the Developer Guide is where the threat rule format is documented.

On licensing, the split is the thing to flag. Source code is Apache License 2.0, copyright 2026 Gen Digital Inc. The detection rules under `threats/` fall under Detection Rule License 1.1, and there is a `NOTICE` file at the repository root. Apache-2.0 is permissive for the code, but the rule corpus is governed separately, so a product that embeds Sage's rules rather than consuming them at runtime should have that second licence reviewed. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt Sage if your team already runs Claude Code, Cursor, VS Code, OpenClaw or OpenCode and you want a pre-execution check on shell commands, URL fetches and file writes without building one yourself. Skip it if you need kernel-level containment, if your agents run in an air-gapped environment where the URL reputation lookup cannot reach a cloud service, or if the Apache-2.0 code licence and the separate Detection Rule License 1.1 for threats/ create a redistribution problem your legal team has not reviewed. Before rolling it out, read docs/decision-pipeline.md to see the evaluation order, then read docs/user-guide.md#privacy to see exactly what leaves the machine, because those two documents decide whether Sage fits your environment.

Frequently asked questions

Official sources

1. gendigitalinc/sage on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases