Superagent SDK: Runtime Guardrails for AI Agents, With a Hosted API Behind Them
Superagent protects your AI applications against prompt injections, data leaks, and harmful outputs. Embed safety directly into your app and prove compliance to your customers.
At a glance
- What is it?
- Superagent ships TypeScript and Python clients for guarding, redacting and scanning agent traffic, plus a Rust release line. The SDK is MIT, but every call in the README routes through an API key from superagent.sh, which is the detail that decides whether you can use it.
- Who is it for?
- Adopt Superagent if you are building an agent that handles untrusted input and you want a guard call in the request path without training or hosting your own classifier, and if sending that input to a hosted endpoint is acceptable. Do not adopt it if your prompts cannot leave your network, or if you need the red team Test feature today, since the README marks it as coming soon.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Superagent targets: untrusted text reaching an agent with tools
An agent that reads a user message, a fetched web page or a repository file is executing instructions it did not write. The README frames the failure modes directly: prompt injections, malicious instructions and unsafe tool calls at runtime, plus PII, PHI and secrets leaving in text, plus repositories that have been poisoned specifically to attack an agent reading them. Those are three different surfaces with three different response shapes, and Superagent exposes them as three separate client calls rather than one policy engine. That is the right decomposition. A guard decision is a classification on a single string. A redaction is a transformation on a single string. A repository scan is a long-running job over a tree of files that returns a report and a cost figure. The audience is narrow but real: teams shipping an agent that calls tools, where a successful injection means an action was taken, not just a bad answer returned. If your application only summarizes static documents and never acts on the output, the guard call buys you less than you are paying for it.
How guard, redact and scan differ in mechanism and in cost model
The guard call takes an input string and returns a result with a classification field and a violation_types array. The README example branches on result.classification === "block" and logs result.violation_types, so the contract is a label plus a list of reasons, not a numeric score. That matters for how you wire it: you get a decision to branch on rather than a threshold to tune, which is simpler to integrate and harder to soften when you disagree with a borderline verdict. The redact call takes an input and a model parameter, shown as "openai/gpt-4o-mini", and returns a redacted string with placeholders in angle brackets, for example <EMAIL_REDACTED> and <SSN_REDACTED>. The presence of a model argument on redact and its absence on guard is worth noticing: redaction is being routed through a model you name, while guard is not. The scan call takes a repo URL and returns result.result as a security report plus result.usage.cost, which the README formats to four decimal places. Only scan exposes a cost field in the examples. Whether guard and redact are billed, and how, is not stated in the material provided.
Getting it running: two installs, one environment variable
The README gives npm install safety-agent for TypeScript and uv add safety-agent for Python. Note the package name on both registries is safety-agent, not superagent, while the repository is superagent-ai/superagent. That mismatch is the first thing that will confuse someone searching a registry. Authentication is a single environment variable, exported as SUPERAGENT_API_KEY, and the README points you to superagent.sh to sign up for the key. Client construction is createClient() with no arguments in both languages, which means the client reads that variable from the environment rather than taking credentials explicitly. Four integration surfaces are listed: a TypeScript SDK, a Python SDK, a CLI, and an MCP server for Claude Code and Claude Desktop, each with its own README under sdk/typescript, sdk/python, cli and mcp. The MCP option is the lowest-effort path if you are already working inside Claude Code, since it avoids writing any client code. The CLI is the one to reach for if you want to run a scan from a pipeline without embedding the SDK.
The hosted API key is the constraint the feature list does not advertise
The features section reads like a local library. The get started section says otherwise: you sign up, you get a key, you export it, and every guard, redact and scan call in the examples goes to a service. For a tool whose stated purpose is catching data leaks, sending the raw input to a third party is a decision that needs to be made deliberately, and the README does not address it. There is a partial escape hatch. One bullet claims open-weight models that let you run Guard on your infrastructure with 50-100ms latency, and the project links to a HuggingFace organization. That is a claim about capability, not a documented deployment path in this README, and the latency figure is the project's own. If self-hosting Guard is the reason you are evaluating Superagent, treat the hosted SDK as a separate product and go read the model card and the self-hosting docs before you design around it. The same bullet also lists OpenAI, Anthropic, Google, Groq and Bedrock as supported, which is about which models your application uses, not about where the guard runs.
Test is not shipped, and the release lines are split by language
The Test feature, which runs red team scenarios such as prompt_injection and data_exfiltration against a live endpoint and returns findings, is marked coming soon in the README and the code block is illustrative. Do not plan around it. The release history shows a second wrinkle: the tagged releases are rust-v0.0.9 and node-v0.0.9 on the same day, with rust-v0.0.8 three days earlier. So there are at least two independently versioned artifacts, a Rust one and a Node one, and the README's install instructions cover the TypeScript and Python packages. The relationship between the Rust releases and the npm or PyPI packages is not explained in the material available, and neither is whether the Python client is a wrapper over the same core. If you need to pin versions or track a security fix across both, that ambiguity is a real cost. The last push date is 2026-08-25, so the repository is active, but activity on the repository is not the same as a documented upgrade path for the SDKs.
Where a self-hosted classifier is the better answer
The obvious alternative is a local classifier such as a fine-tuned injection detector running in your own process, or a general moderation endpoint from the model provider you already use. The difference is not accuracy, it is the data path. A local classifier sees the text and keeps it; Superagent's documented flow sends it to a hosted API and returns a label. That single difference decides most deployments. If your inputs are internal tickets, medical text or anything under a data processing agreement that names your infrastructure, the hosted guard call is the wrong tool regardless of how good its detection is, and the open-weight bullet is the only part of this project that could change that answer. The reverse case is equally clear: if you have no ML team, no labelled injection data and no appetite for maintaining a model, a hosted call that returns block or allow is far less work than building one, and the redact call saves you writing and maintaining your own PII patterns for every format you encounter.
Licence, maintenance and what an upgrade actually costs
The repository is MIT, and the README repeats that. MIT covers the code in the repository; it does not by itself tell you the terms of the hosted API, the pricing of guard and redact calls, or the licence of the HuggingFace model weights, which are separate artifacts with their own terms. Read those separately. On maintenance, the split release lines are the main ongoing cost: rust-v0.0.9 and node-v0.0.9 landed the same day, so a fix may need to be tracked in two places, and the version numbers are still in the 0.0.x range, which in practice means the API surface can move. The README's own examples are the contract you should test against, since there is no stated stability guarantee. This is not a project where you write the integration once and forget it. Budget for re-reading the per-SDK README files under sdk/typescript, sdk/python, cli and mcp when you upgrade, and pin the versions you install rather than tracking a floating range.
Editorial conclusion
Adopt Superagent if you are building an agent that handles untrusted input and you want a guard call in the request path without training or hosting your own classifier, and if sending that input to a hosted endpoint is acceptable. Do not adopt it if your prompts cannot leave your network, or if you need the red team Test feature today, since the README marks it as coming soon. Before committing, verify three things against the current docs: whether Guard can actually run on your own infrastructure as the open-weight bullet implies, what the per-call pricing is for guard and redact rather than only for scan, and whether a Python client exists for the Rust release line or only for the Node one.
Community notes