# Syntrox > Syntrox is an active-governance layer for autonomous AI agents. It sits between an organisation's agents and the model, judges what an agent is about to say or do before the agent acts on it, and can halt the whole fleet from one switch. It runs inside the customer's own network and adds no egress of its own: the judge, the switch and the evidence stay in the VPC, and the only traffic that leaves is the agent's own model call, which it was making anyway. Syntrox (website syntrox.io; the wordmark reads "Syntrox.ai") builds runtime safeguards for AI agents that take real actions: send email, call APIs, write to databases, move money. Observability tools record what an agent did. Syntrox intercepts it while the call is still in flight. Status, in one line: the Syntrox platform is in private beta with design partners; the Nucleus products inside it (Nucleus Judge and Nucleus ToolCall) are in private alpha. There is no public pricing and no self-serve sign-up; the way in is a call. Terms used below. Nucleus is the family name for Syntrox's small models: Nucleus Judge evaluates, Nucleus ToolCall routes. A span is one recorded step of an agent's run: a model call, a tool call, a retry or a guardrail check. **What it does.** - Intercepts in the call path. A one-hop LiteLLM proxy between the agent and the model provider. No agent code changes. The agent's own model calls go to the provider it already uses: Azure OpenAI, Amazon Bedrock or Anthropic. - Judges before the agent acts. Every model completion — the agent's reply, or the tool call it is about to make — passes through an independent small-model judge (Nucleus Judge) before it reaches the agent. The judge checks it against the organisation's own policy and returns a verdict (pass, fail or uncertain), a severity, a confidence and the exact span of text that caused it. Judging happens on the completion, before execution, not on a log afterwards. - Halts the fleet. A fleet-wide kill switch: one flag checked by every request before it goes anywhere. Stopping becomes a decision instead of a deploy. No redeploy, no rollback. - Keeps the evidence. Every run as a tree of spans with cost, latency and PII flags attached to the span that caused them, for audit and compliance. Every span and every verdict stays on the customer's side of the wall. - Stays inside your network. Deploys as a single-hop container in an AWS, Azure or GCP VPC or on an on-prem cluster. The judge and the switch run locally and need no outbound connection, which is what "air-gap capable" means here. - Fails open. If the judge goes offline, the agent fleet continues uninterrupted. Halting is a decision somebody makes, never a side effect of an outage. **The four situations it is built for.** 1. The leak. An agent reads a document that happens to contain live credentials and includes them in a reply to an external recipient. There is no error to catch, because nothing went wrong mechanically. Syntrox sits between the agent and the model, so the completion is checked before it goes anywhere, not reconstructed from a log afterwards. 2. The verdict. Every step was valid; the outcome was not. An independent judge reads the exchange and returns a verdict, a severity, and the line that caused it, quoted back, so a reviewer has something specific to argue with. 3. The stop. You need it to stop, now. One flag, checked by every request before it goes anywhere; fleet-wide by design rather than per service. 4. The evidence. Compliance wants to see what the agent did, under what rule, and what stopped it. The judge's verdicts are reproducible (temperature 0, fixed seed), so a compliance re-run months later gives the same verdict, on your machine. That is a property of the judge, not of the agent: Syntrox does not make the agent's own output deterministic; it makes the permitted-action boundary explicit and the record reconstructable. **Numbers, and what each one is.** Measured, and stated on the site as the figures the company stands behind today: 47 of 47 cases green on the stub engine, and 83.3% at n=12 on the industrial gold set (a labelled set of twelve industrial-domain cases). Recorded: the homepage demo replays five cases from that gold set (a credential leak, an interlock bypass, a fabricated rating, a correct refusal, a grounded answer), judged by a stock 4B-parameter model (Qwen3 4B via Ollama on an Apple M4 laptop, as the page states), at the latency each one actually took on that hardware: seconds, not milliseconds. The fine-tuned Nucleus Judge model is the private-alpha product; the demo shows the recorded run, not the alpha model. Design targets, labelled as such on the site and not published gold-set results: the GPU path for that judge targets sub-second latency and is not deployed yet. The Nucleus Judge architecture targets under 120 ms inline, a 94% hallucination catch rate on an AML/BSA rubric against 71% for GPT-4o reading a raw policy PDF, and 15x lower cost per judgement than that GPT-4o baseline; both columns of that comparison are part of the same target table. Nucleus ToolCall targets under 50 ms to route and 98% routing accuracy on 50 schemas against 82% for GPT-4o routing all 50 directly, 10x cheaper. The company says it will publish gold-set numbers as alpha pilots complete. The blog's articles describe the latency budgets of the architecture in their own words; where an article and this list differ, this list is the more conservative statement. **Who it is for.** Teams running autonomous agents with write authority in production (SQL mutations, external HTTP calls, shell commands, commercial transactions), and the security, platform and compliance people who have to sign off on them: platform engineers, enterprise architects, CISOs, heads of AI risk. **Status.** Private beta. Syntrox is taking a small number of design partners (cohort 2026 Q4, six in-VPC slots). You bring the agent runs that worried you; they show you what an independent in-VPC judge makes of them. ## Products - [Syntrox platform](https://www.syntrox.io/): the governance layer — proxy, judge, kill switch and span-level evidence, in your VPC. Private beta. - [Nucleus Judge](https://nucleus.syntrox.io/judge): a small language model fine-tuned for hallucination, faithfulness and safety evaluation, bound to your policy documents before it reads anything. Returns a verdict (pass, fail or uncertain), a severity, a confidence and the quoted span that caused it; temperature 0 and a fixed seed; tested against prompt-injection attacks hidden in the material it judges; fail-open. One HTTP call (POST /v1/judge with the output and its grounding context). Private alpha. - [Nucleus ToolCall](https://nucleus.syntrox.io/toolcall): a tool router for agents with large tool sets. It ranks tools on what actually happened the last thousand times each was called for your organisation and hands the model a shortlist of three, through an OpenAI-compatible endpoint (change the base URL, keep the agent code). Private alpha. ## Contact - [Book a call](https://cal.com/saipraneeth/sai-praneeth-x-syntrox-quick-connect): 20 minutes with the founding team. - [Email](mailto:sai.praneeth@syntrox.io): sai.praneeth@syntrox.io - [LinkedIn](https://www.linkedin.com/company/syntrox-ai): the company page. - [Blog](https://www.syntrox.io/blog): notes on safeguarding autonomous agents. - [RSS](https://www.syntrox.io/blog/rss.xml): the blog's feed. - [Sitemap](https://www.syntrox.io/sitemap.xml): every public page. ## Blog - [AI Red Teaming Is a Snapshot, Not a Control: What Agents Need Instead](https://www.syntrox.io/blog/ai-red-teaming-agents-a-snapshot-not-a-control): Why a one-off AI red team or safety audit stops describing your agent within weeks, and how to turn findings into release gates and runtime checks instead. - [Human-in-the-Loop Isn't a Control Until You Measure It: Approval Fatigue in AI Agents](https://www.syntrox.io/blog/human-in-the-loop-ai-agents-approval-fatigue): Why human-in-the-loop approval often fails as an AI agent control: automation bias, approval fatigue and hidden arguments, plus how to measure oversight. - [AI Agent Audit Trails Under EU AI Act Article 12: What to Log, and for How Long](https://www.syntrox.io/blog/ai-agent-audit-trail-eu-ai-act-article-12): What EU AI Act Article 12 requires of AI logs, how long Articles 19 and 26 say to keep them, the new 2027 deadline, and 8 things to log for every agent action. - [MCP Tool Poisoning: How a Tool Description Hijacks an AI Agent](https://www.syntrox.io/blog/mcp-tool-poisoning-how-a-tool-description-hijacks-an-agent): How MCP tool poisoning, rug pulls and tool shadowing hijack AI agents through tool descriptions, why it is a confused deputy problem, and how to stop it. - [Fail-Open vs Fail-Closed: What an AI Agent Guardrail Should Do When the Check Fails](https://www.syntrox.io/blog/fail-open-vs-fail-closed-ai-agent-guardrails): When an AI agent's guardrail times out or its judge is down, should the action proceed? Four rules for choosing fail-open or fail-closed, by action type. - [SLM-as-a-Judge vs LLM-as-a-Judge: Why the Judge in the Path Should Be Small](https://www.syntrox.io/blog/slm-as-a-judge-vs-llm-as-a-judge-why-the-judge-in-the-path-should-be-small): LLM-as-a-judge is fine for offline evals. For runtime checks on AI agent actions, a small hosted judge wins on data egress, cost, reproducibility and bias. - [Why AI Agents Stall Before Production — and It Isn't the Model](https://www.syntrox.io/blog/why-ai-agents-stall-before-production-and-it-isn-t-the-model): Why AI agents stall before production: the real blocker is accountability, not capability. The four sign-off questions a working agent can't answer, and what unblocks them. - [When Your AI Agent Talks to Customers, You Own What It Says](https://www.syntrox.io/blog/when-your-ai-agent-talks-to-customers-you-own-what-it-says): AI chatbot legal liability after Air Canada and the 2026 German rulings: the customer-facing agent failures that create it, and what has to sit between the agent and the customer. - [Autonomous Trading Agents: What SEBI and FINRA Already Require](https://www.syntrox.io/blog/autonomous-trading-agents-what-sebi-and-finra-already-require): Autonomous trading agent risk explained: the failure specific to multi-agent trading systems, what SEBI and FINRA already require, and why a dashboard satisfies none of it. - [AI Safety in Industrial Automation: Governing Agents the Way You Govern Operators](https://www.syntrox.io/blog/ai-safety-in-industrial-automation-governing-agents-the-way-you-govern-operators): AI safety for industrial automation: why IEC 62443 already governs a non-deterministic actor, how to bound and record AI agents the same way, and how to scope an edge pilot. - [Rogue AI Agent Containment: Isolating One Agent Without Stopping the Fleet](https://www.syntrox.io/blog/rogue-ai-agent-containment-isolating-one-agent-without-stopping-the-fleet): How to contain a rogue AI agent: hold the stop path outside the agent, isolate one agent without halting the fleet, and split automatic from human-triggered isolation. - [Agentic AI Risks and Controls: A Mapping for Security Teams Building Their First Framework](https://www.syntrox.io/blog/agentic-ai-risks-and-controls-a-mapping-for-security-teams-building-their-first-framework): A risk-to-control mapping for security teams writing a first agentic AI framework: seven risks, a control for each, and why independence belongs in the RFP. - [Prompt Injection Detection at the Proxy Layer: Why 20ms Latency Is the Real Constraint](https://www.syntrox.io/blog/prompt-injection-detection-at-the-proxy-layer-why-20ms-latency-is-the-real-constraint): The latency budget for prompt-injection detection at a proxy or LLM gateway: a sub-20ms inline tier on ingress, a ~145ms judgment tier, and what goes in each. - [Enterprise AI Guardrails That Actually Stop Agents, Not Just Filter Prompts](https://www.syntrox.io/blog/enterprise-ai-guardrails-that-actually-stop-agents-not-just-filter-prompts): Most AI guardrails filter text. An action-layer system judges an agent's action and can stop it before it runs. Four questions to tell which you're buying. - [What an AI Agent Governance Platform Must Prove Before Compliance Signs Off](https://www.syntrox.io/blog/what-an-ai-agent-governance-platform-must-prove-before-compliance-signs-off): A sign-off checklist for AI agents: eight things a governance platform must prove, why no EU AI Act certificate exists yet, and two questions for any vendor. - [LLM Hallucination Detection Isn't Enough — You Need a Judge, Not Just a Classifier](https://www.syntrox.io/blog/llm-hallucination-detection-isn-t-enough-you-need-a-judge-not-just-a-classifier): A risk committee asks whether an agent's action was permitted under policy. A hallucination detector can't answer that; a judge can, with the rule named. - [Agentic AI Security Risk: The Attack Surface Most Enterprises Haven't Modeled Yet](https://www.syntrox.io/blog/agentic-ai-security-risk-the-attack-surface-most-enterprises-haven-t-modeled-yet): A threat model for tool-calling AI agents that hold credentials: five attack patterns, and the control that addresses each. Why text filtering misses four. - [AI Agent Policy Enforcement: Inline Judging vs. Post-Hoc Review](https://www.syntrox.io/blog/ai-agent-policy-enforcement-inline-judging-vs-post-hoc-review): Enforce AI agent policy before an action executes, not by reviewing logs after it settles. Inline vs. post-hoc enforcement, compared for risk committees. - [Why Multi-Agent Observability Tools Miss the Failures That Matter](https://www.syntrox.io/blog/why-multi-agent-observability-tools-miss-the-failures-that-matter): Agent traces look fine, yet the agent took the wrong action. Why multi-agent observability misses the failures that cost money, and what has to run beside it. ## Optional - [Full text](https://www.syntrox.io/llms-full.txt): this file followed by the full text of every article.