Superagent: one guard call between a user message and your agent

Guard is a single call you put in front of every user message

The smallest useful thing in this SDK is one method. You create a client, pass it the incoming message, and inspect a classification field. There is no agent wrapper, no framework to adopt, and no configuration object to assemble before the first call.

import { createClient } from "safety-agent";

const client = createClient();

const result = await client.guard({
  input: userMessage
});

if (result.classification === "block") {
  console.log("Blocked:", result.violation_types);
}

The return shape is small and deliberate. A classification string is the decision, and violation_types carries the reason, so a blocked request tells you which rule fired rather than just that something did. The scope claim covers prompt injections, malicious instructions and unsafe tool calls, which is the third being the interesting one for agents that can act rather than only answer.

Redact runs a model over the text and returns angle-bracket placeholders

Redaction is the second method, and it is the one that costs you a model choice. You pass the text and pick the model that will do the detection, then read the redacted string back.

const result = await client.redact({
  input: "My email is [email protected] and SSN is 123-45-6789",
  model: "openai/gpt-4o-mini"
});

console.log(result.redacted);
// "My email is <EMAIL_REDACTED> and SSN is <SSN_REDACTED>"

Three things follow from that signature. Redact covers PII, PHI and secrets in one pass rather than in separate calls. The model is passed as an argument, so detection quality and cost are your decision. And the output format is fixed placeholders like EMAIL_REDACTED and SSN_REDACTED, which is worth thinking about before you render them into a user-facing template, because the label is generic rather than shaped to your data.

Scan targets the repository, and it reports its own cost back to you

The third method looks at a repository rather than a message. You pass a repo URL and get back a security report, plus a usage object carrying a cost figure you can print to four decimal places.

const result = await client.scan({
  repo: "https://github.com/user/repo"
});

console.log(result.result);  // Security report
console.log(`Cost: $${result.usage.cost.toFixed(4)}`);

The stated targets are AI agent-targeted attacks specifically: repo poisoning and malicious instructions planted in files. That is a different threat model from scanning your dependencies for known CVEs, and it is the one that matters when an agent will read files from a repository it did not write. Exposing the cost on the response object tells you this is a metered remote call rather than a local check.

The Python SDK exposes the same three methods with the same argument names, so the only real difference between the two surfaces is language.

The fourth method is documented, complete, and marked coming soon

The SDK advertises four capabilities and the fourth is not finished. Test is described as running red team scenarios against your production agent, with a call that takes an endpoint and a list of scenario names such as prompt_injection and data_exfiltration, and a response carrying findings.

const result = await client.test({
  endpoint: "https://your-agent.com/chat",
  scenarios: ["prompt_injection", "data_exfiltration"]
});

console.log(result.findings);  // Vulnerabilities discovered

The method signature and an example are there, but the heading carries an explicit coming soon note. Treat it as a roadmap item. Anyone building a compliance story around continuous red teaming against a live endpoint should know that the piece they want is the piece that is not shipped, and that the other three methods are the ones to plan around.

The package name is safety-agent, which will cost you an afternoon

The distribution names do not match the product name. The README and the repository are both called Superagent, but the import is from safety-agent and the install line installs safety-agent. The GitHub organisation is superagent-ai, so the naming is at least consistent about which brand it is and inconsistent about which one reaches your dependency list.

Installation is one command per language, and both assume a hosted service.

npm install safety-agent

uv add safety-agent

Then a single environment variable, SUPERAGENT_API_KEY, which you obtain by signing up on the website. That variable is the whole of the authentication story the README shows, though it also says the open-weight Guard models can run on your own infrastructure. If your platform policy forbids sending user input to a third-party endpoint, this SDK as configured does not fit without more work.

Four integration surfaces: two SDKs, a CLI and an MCP server

The repository is split into four surfaces, each with its own README: a TypeScript SDK under sdk/typescript, a Python SDK under sdk/python, a command line tool under cli/ described as being for testing and automation, and an MCP server under mcp/ intended for use with Claude Code and Claude Desktop.

The MCP server is the most interesting for adoption, because it is meant for use with Claude Code and Claude Desktop rather than code you write and deploy. The CLI is the most useful for pipeline work, where you want to invoke a check as a step rather than as a dependency.

The repository root is otherwise spare: CHANGELOG.md, LICENSE, README.md, SECURITY.md, a logo, and the four directories above plus docs/. There is no tests directory and no configuration file at the root, so the surface area you can audit before installing is small, and so is what an audit would cover.

Releases stopped in September 2025 while the repository kept moving

The release history is worth reading before you plan around the project. The three most recent tags are node-v0.0.9 on 2025-09-14, rust-v0.0.9 on 2025-09-14 and rust-v0.0.8 on 2025-09-11. Every one of them is a 0.0.x tag.

The repository itself is not archived and the last push was on 2026-08-25, so work has continued since those tags without a new public release from this repository. If your procurement process needs to see version numbers moving, get them from the package registries rather than from this repository's tag list.

On the licence, MIT applies to the SDK code, and the open-weight Guard models are hosted separately on HuggingFace under the same organisation.

Editorial conclusion

Superagent fits a team shipping an agent that reads untrusted text and wants one synchronous check in front of it, plus a redaction helper for outbound payloads. It does not fit a plan that needs red team automation today, since the test method is marked as coming soon, and it does not fit an offline deployment unless you are willing to host the open-weight Guard model yourself. Before adopting it, confirm three things: what your data residency rules say about sending user input to a hosted API, whether the redaction labels in your output survive your template rendering, and what you will do when the guard itself is unavailable, since the README does not describe a fallback path.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. superagent-ai/superagent on GitHub