Content-inspection engine

The content-inspection engine is the part of the gateway that actually reads an agent's payload and decides how risky it is. It is payload-aware: rather than matching on the tool name alone, it inspects the arguments and content flowing through the action.

Signal families

Each detector contributes one or more signals. Signals are grouped into families:

• Secrets: API keys, tokens, private keys, and other credentials that should never leave a trusted boundary.
• PII: emails, phone numbers, government IDs, and similar personal data.
• Destructive: operations that delete, drop, overwrite, or otherwise cause irreversible change.
• Injection: prompt-injection and instruction-override attempts embedded in content the agent is processing.
• Malware: dangerous-execution indicators such as reverse shells, encoded PowerShell, download-and-run pipes, and credential dumping. Denied by default.
• Financial: crypto and financial identifiers such as wallet addresses, IBANs, and SWIFT codes. Seed phrases and private keys are redacted like secrets.
• Egress: risky movement of data out of a trusted boundary, such as unbounded SELECT *, bulk export or dump queries, exfiltration hosts, and oversized field values.

From signals to a verdict

Detected signals roll up into a risk score. The score, combined with the policy that applies to this agent and tool, produces the verdict:

Write-time redaction

When a payload contains sensitive content but the action is otherwise legitimate, the engine can redact at write time, replacing secrets or PII with placeholders so the action can proceed without leaking the underlying data. The original spans never reach the downstream tool.

Tool-output inspection

Inspecting arguments stops an agent from sending something dangerous. It does not stop an agent from reading something dangerous. Indirect prompt injection, the dominant real-world attack on agents, hides instructions inside the content a tool returns: a fetched web page, a document, an email, or an API response. When the model reads that output, the injected instructions can hijack the run.

AxioRank can inspect what a tool returns, not just the arguments it was called with. Result inspection adds output-specific detectors under the injection family:

• instruction overrides aimed at the agent ("ignore previous instructions", "your new task is...")
• hidden or bidirectional unicode used to smuggle invisible instructions
• data-exfiltration markdown links and images that carry your context in a URL
• embedded directives telling the agent to call another tool
• forged role or chat markers, and suspicious encoded blobs

The secret, PII, and destructive detectors run on outputs too, so a tool that returns a credential or personal data is caught the same way.

Enabling it

Result inspection is opt-in and monitor-first: turning it on surfaces signals in your logs and alerts without changing any verdicts. Blocking a poisoned output still needs a policy that denies on the matched signal, so you can roll it out in monitor mode and tighten later.

• MCP servers: enable inspect_results on the server in the gateway. A poisoned result is replaced with a refusal before it reaches the agent, on both the remote proxy and the local stdio shim.
• SDK and framework adapters: turn on Tool-output inspection in workspace settings, then either call inspectResult directly or pass inspectResults: true to a framework adapter so untrusted-source tool outputs are inspected automatically.

const page = await fetchUrl(url);
const { decision } = await axio.inspectResult({ tool: "web.fetch", resultText: page });
if (decision === "deny") {
  // drop or replace the untrusted content before the model sees it
}

Auditing

Every decision is stored with the signals that produced it. When you need to answer "why was this blocked?" weeks later, the trail is already there.