Adrian: A Runtime Security Layer That Reads Agent Reasoning, Not Just Tool Calls
Open-source runtime AI agent security tool - monitors and controls AI agents, catching malicious tool use, prompt injection, and policy drift in real time, before the agent acts.
At a glance
- What is it?
- Adrian is an Apache-2.0 Python engine from Secure Agentics that inspects agent activity logs and reasoning traces, then optionally blocks or holds an action before it executes. It ships as an SDK for LangChain, Anthropic and TypeScript, plus a Claude Code plugin, and can run against a managed dashboard or self-hosted.
- Who is it for?
- Adopt Adrian if you already run a LangChain, LangGraph, Anthropic or TypeScript agent in production and you want a session-level check on actions rather than a static prompt filter. Do not adopt it if your agent stack is outside the supported SDK list, or if you cannot feed it a written remit, since the remit is the thing every judgement is measured against.
- Can I use it commercially?
- Yes. Apache-2.0 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 1 day ago.
- What is it written in?
- Mainly Python, 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 gap Adrian targets: static filters and network logs miss agent intent
Prompt-injection classifiers are trained on datasets of known attacks. The README makes this the core argument: a classifier recognises what it has seen, and an agent doing something it was never supposed to do may look entirely ordinary at the packet level. The example given is an e-commerce agent that starts resetting user passwords. No API call is malformed. No credential leaks over the wire. The action is simply outside the remit of that agent, and a behaviour-only monitor has no way to know what the remit was.
Adrian's answer is to hold a working model of what the agent is meant to do and score each action against it, correlated across a session rather than judged in isolation. The README frames the target audience narrowly enough to be useful: teams running agents that call tools, reach MCP servers, touch databases, and hold credentials. If your agent only answers questions from a fixed corpus and never invokes anything, the runtime control layer has little to attach to.
Reasoning traces as a second input channel
The mechanism described in the README has two inputs. The first is the activity log: tool calls, actions, outputs. That is the layer most monitoring tools stop at. The second is the reasoning trace, which the README describes as understanding why an action was taken, under what context, and what the agent plans next. The claim is that combining the two catches more than either alone, and the README cites an OpenAI and DeepMind paper (arxiv.org/pdf/2503.11926) for the finding, along with headline figures of +35% detection accuracy and 4x more nuanced attacks caught against behaviour-only monitoring.
Those numbers come from the cited research, not from an evaluation the project published. Treat them as an argument for the design, not as a measurement of Adrian itself. The design consequence is what matters: Adrian needs the reasoning trace to be available. If your agent framework does not expose intermediate reasoning, or if you strip it for cost or privacy reasons, you are back to behaviour-only monitoring and the stated advantage does not apply. The README does not spell out what happens in that case, which is a gap worth resolving before you plan a rollout.
Getting it running: SDK, plugin, and the two-line bracket
The fastest documented path is the managed dashboard at app.adrian.secureagentics.ai. Sign up, generate an API key, configure the agent's remit, choose audit versus block mode, set alerting channels, and mark accepted behaviours against known risks. Then install the SDK and wrap the agent.
pip install adrian-sdk pip install langchain langchain-openai
The integration is deliberately small. adrian.init(api_key="adr_live_...") brackets your normal LangChain or LangGraph code, and adrian.shutdown() closes it out. The SDK auto-instruments LangChain and LangGraph, so create_agent and create_react_agent are covered without touching the graph definition. The README pins a verified combination: langchain==1.3.9, langgraph==1.2.5, langchain-core==1.4.7, langchain-openai==1.3.2, last verified 2026-06-24, with a supported range of >=1.0,<2.0 for the first three and langchain-core >=1.2.19,<2.0.
There are two other entry points. The TypeScript SDK lives under sdk/typescript, and the Anthropic path is documented in sdk/python/ANTHROPIC.md. The Claude Code plugin installs without code changes: /plugin marketplace add secureagentics/Adrian followed by /adrian-init. The README claims every tool call is classified in real time from the terminal, with risky actions blocked or held for approval. The repository also points at GET_STARTED_AI_GUIDE.md, a file you hand to a coding agent to walk the install, and the README itself says to review those instructions manually.
Audit mode first, block mode later, and what the remit actually controls
The configuration step is where the product's real behaviour is decided, and the README is thinner here than anywhere else. Three settings carry the weight: the agent's remit, audit versus block mode, and the split between accepted behaviours and known risks.
The remit is the reference point. Adrian judges each action against a working understanding of what the agent is meant to do, so a vague remit produces vague judgements, and an over-tight remit produces holds on legitimate work. Audit mode lets the engine classify and alert without intervening, which is the sensible way to learn where your agent's real boundary sits before you let anything stop a tool call. Block mode is the in-flight intervention the product is named for. The README does not document the latency cost of that in-flight decision, nor what the SDK does when the classification service is unreachable. Both matter for a control that sits between your agent and its tools. Until you have measured them on your own traffic, treat block mode as untested in your environment.
Where the approach breaks down
Reasoning-trace analysis depends on reasoning being visible and honest. An agent that produces a plausible rationale for an action it was manipulated into taking gives the second channel something to read that does not match the action's real cause. The README presents reasoning as an additional signal; it does not claim the signal is unfalsifiable, and it should not be read that way.
There is a second constraint. The README states that Adrian holds an understanding of what the agent is meant to do. That understanding has to be supplied and maintained. An agent whose responsibilities shift without the remit being updated will generate holds, and a team that responds by widening the remit to silence alerts has quietly disabled the control. This is not a flaw unique to Adrian, but it is the failure mode most likely to appear in practice.
The third constraint is coverage. The documented SDKs are Python for LangChain and Anthropic, plus TypeScript. If your agents are built on a framework outside that list, the README does not describe an integration path, and the auto-instrumentation does not apply. The Claude Code plugin covers terminal tool calls, which is a different surface from a deployed agent service.
How this differs from a gateway or a prompt filter
The obvious alternative is a policy gateway sitting in front of tool calls: an allowlist and denylist over tool names and arguments, plus input filtering on prompts. That approach is deterministic, cheap, and easy to reason about in an audit. It also cannot express the case Adrian is built for. A denylist that blocks password resets would stop the e-commerce agent, but it would also stop the legitimate account-recovery flow unless you scope it by agent identity and session context, which is most of the work Adrian is doing.
The second alternative is the classifier route the README argues against: a model trained on prompt-injection and jailbreak datasets, applied to inputs. It catches known attack shapes well and runs offline. Its blind spot is the out-of-remit action that no training set contains. The difference in approach is not accuracy on a shared benchmark, it is what each system treats as its reference. A classifier compares input to attack patterns. Adrian compares action and reasoning to a stated remit. That makes Adrian better suited to agents with a narrow, describable job, and worse suited to general-purpose assistants whose remit is effectively everything.
Licence, self-hosting, and the upgrade surface
Adrian is Apache-2.0. The README describes it as open source and free forever, with a managed dashboard as the quickest route. Apache-2.0 permits commercial use, modification, and redistribution, and includes a patent grant; it also requires that you keep the licence and notices. If you fork the SDK and ship it inside a product, those obligations travel with the code. This is a summary, not legal advice, and the LICENSE file in the repository is the controlling text.
The self-hosting path is mentioned in the README as an alternative to the dashboard, with a pointer to a Self-hosting section that is cut off in the material available here. The repository layout shows sdk/python, sdk/typescript, and integrations/claude-code directories. Whether self-hosting means running the classification engine locally, or running a control plane that still reaches Secure Agentics infrastructure, is not determinable from what is available. Anyone who needs the engine to stay inside their network should confirm that before building on it.
The upgrade cost sits mostly in version pinning. The README pins a verified set of LangChain packages and states a supported range, and notes the verification date. LangChain's 1.x line moves, and the SDK's auto-instrumentation hooks into it, so a minor bump outside the tested combination is the realistic breakage point. No release history was retrieved, so there is no way to judge cadence from this material.
Editorial conclusion
Adopt Adrian if you already run a LangChain, LangGraph, Anthropic or TypeScript agent in production and you want a session-level check on actions rather than a static prompt filter. Do not adopt it if your agent stack is outside the supported SDK list, or if you cannot feed it a written remit, since the remit is the thing every judgement is measured against. Before you commit, verify three items yourself: that the pinned versions in the README match your lockfile, that audit mode produces a clean baseline on your own traffic before you switch to block mode, and that the self-hosting path in the repository actually covers your deployment target rather than pointing you back at the managed dashboard.
Community notes