Security and trust

AgentX is an action firewall for AI agents. Agents no longer just chat; they take real actions: executing code, moving money, and calling APIs. AgentX checks what an agent is about to do and blocks the irreversible action before it runs, then hands the agent a safe path so the task still finishes. Blocking is the default once you set an API key or the enforce posture; a keyless install watches and records instead. Because it sits that close to your systems, how it handles your data matters. This is a plain, honest account of that, and of where we are on security today. We are early, so parts of this are “here is what we do and do not do” rather than a wall of certifications.

Last reviewed August 2026.

Who is behind AgentX

Hi, I'm Vasu. I've spent my career in infrastructure and networking, at Cisco and Nokia and across four startups, including two with successful exits and one I co-founded. AgentX is early, and I built it. If you want to talk to a person about any of this, contact me on LinkedIn or in the AgentX Discord.

How AgentX handles your data

The SDK runs in your environment. The keyless Shield (the @agentx_protect decorator and the agentx-mcp proxy) checks each action locally, inside your own process. Your data does not leave your machine: it needs no API key, makes no LLM calls, and sends none of your prompts, code, or tool arguments anywhere. The dangerous call is stopped before it runs, in your process.

What it writes down, on your disk. Every interception is recorded in a local SQLite file so you can review it later. AgentX also records one row per call that PASSED, so you can see what your agent actually did without turning protection off. A row holds the tool’s own name, the NAMES of the arguments it was called with, a magnitude bucket rather than a figure (1,000 where the call passed 1,042.55), and a coarse target class such as db or http. It never holds an argument value, a query, or a payload. The file stays on your machine, and nothing in it is sent anywhere.

The SDK is open source. It is MIT-licensed and public, so you can read exactly what it does before you run it: agentx-security-sdk on GitHub. The MCP proxy lives in that same repo, and the launcher you run with uvx, agentx-mcp, is MIT and public too.

The scanner runs on your machine. npx @agentx-core/scan . lists the tools your agent can call, ranked by how dangerous they are, and flags the ones nothing is guarding. It reads your repository locally and prints the result: it makes no network calls, needs no key or account, and sends us nothing. It is MIT licensed, and the published package is plain readable JavaScript, so you can check what it does before you run it.

The TypeScript SDK records locally and sends the same anonymous pulse. @agentx-core/security-sdkwraps a tool and writes every call to a local file: the tool’s name, the NAMES of its arguments, a size band for an argument the tool itself named as a count or as an amount beside a currency, a coarse surface such as db or http, the time, and the agent name you gave it. Never an argument value, a query, or a result. It watches and blocks nothing. Like the Python SDK it sends the anonymous usage signal described below, counts only, off with AGENTX_TELEMETRY=off. Of our two TypeScript packages this is the one that reaches the network; the scanner above never does, and each README says so.

The gateway is bring-your-own-key. Coached recovery and the deeper checks run through a gateway you can run yourself with Docker, using your own model key. Run it self-hosted and your data stays in your environment.

Telemetry is anonymous, coarse, and optional. The SDK sends an anonymous usage signal, an install id with the version and a few coarse counts, and never your payloads, prompts, or arguments. It tells you this on first run, and you can turn it off with AGENTX_TELEMETRY=off.

We did the homework in the open

We founded and maintain the ARE Incident Database (AREDB), a neutral, open registry of real, cited agent-failure incidents. It carries 34 incidents today, every one with a public source, 0 disputed and 0 withdrawn. It is not our marketing: it has its own domain, its own governance, and a coverage index any vendor can join.

Two things a reviewer can do with it. Read exactly which failures we claim to stop and which we do not, in our coverage claim against the registry. And check us: every published claim ships a test that runs in CI, so a claim that stops being true goes red on its own. The database and its checks are public on GitHub.

Answering the standard your reviewer is using

Several standards now cover AI agents. AIUC-1 sets out 51 requirements across six domains, is revised quarterly, and is certified against by independent audit firms. It cross-references its requirements to MITRE ATLAS, NIST AI RMF, ISO 42001, the EU AI Act, OWASP’s LLM and Agentic Top 10s, the CSA AI Controls Matrix, IBM’s AI Risk Atlas and Cisco’s AI security framework, so an answer to AIUC-1 maps onto those.

Three of its mandatory requirements cover the actions an agent can take. Those are the ones that apply to AgentX.

  • A003 asks you to limit what data an agent can reach, scoped to the task, the user and the agent.
  • B006 asks you to stop agents acting beyond their privileges, and names pre-execution authorization hooks as an accepted way to do it.
  • D003 asks you to stop tool calls that execute unauthorized actions, reach restricted information, or decide beyond their intended scope.

AgentX checks each action before it runs and stops the dangerous one. The rules are MIT licensed and public, so your reviewer can read the rule that stopped an action instead of taking our word for it.

What we are not. We are not your container, your network, or your identity layer. If the risk your reviewer is chasing is an agent escaping its sandbox, that is a different control and a different vendor.

Where we are thin. The standard also wants independent testing of tool calls every three months. We cannot provide that, because we are the thing being tested.

We are not certified against AIUC-1, and this page is not an audit. It is our own reading, published so your review starts from something concrete. Send us the instrument your reviewer is using, through the AgentX Discord, and we will map this answer onto it. The neutral survey behind this section, with no product claim in it, is on AREDB.

Our security posture, honestly

We are early and not yet SOC 2 certified. Here is what we actually do today:

  • The gateway ships a minimal, default-deny container image: only the runtime it needs to run, and nothing else in the image to attack.
  • The keyless Shield is open source (MIT), so what catches a dangerous action before it runs is auditable rather than a black box.
  • Hosted options (the Control tier) process only what you send them, using your own model key; self-hosting keeps everything in your environment.

Report a security issue

Found a vulnerability in AgentX, the SDK, the gateway, or this site? Message me on LinkedIn or in the AgentX Discord. I will acknowledge it and work with you on a fix. Please give me a reasonable window to address it before any public disclosure.