ToolGuard Models - Runlayer

Industry-Leading AI Security for MCP Ecosystems

Runlayer ToolGuard is an industry-leading suite of specialized machine learning models that protect your MCP environment from tool poisoning, prompt injection, and output manipulation attacks. With fast 50-100ms inference times, ToolGuard delivers real-time threat detection without compromising performance.

Currently featuring four specialized threat classification models, with additional models in active development to address emerging attack vectors.

The Models

Tool List Guard

Scans tool definitions at registration to detect risky descriptions, prompt injection attempts, and hidden instructions before tools are made available to your environment.

Tool Call Guard

Scans tool execution outputs in real-time to detect risky responses, data exfiltration attempts, and prompt injection before they reach your LLMs.

Tool Intent Guard

Detects tool intent drift from prompt injections that lead to data exfiltration, privilege escalation, credential theft, and infrastructure damage. Unlike the Tool Call Guard which evaluates individual responses, Tool Intent Guard analyzes tool inputs and outputs together to detect semantic misalignment — catching cases where a tool’s actual behavior diverges from what was requested.

Prompt Guard

Prompt Guard is rolling out gradually. If you don’t see it under Settings → Security Scanners, it isn’t enabled for your workspace yet.

Scans the run’s prompt in Runlayer agents and prompts typed in clients with Runlayer hooks, together with the system prompt when one is available, for jailbreaks, prompt injection, and other attacks before the agent acts on it. A flagged prompt is labeled with the same threat categories as other ToolGuard findings. Prompt Guard runs on:

Runlayer agents — the run’s input is scanned with the agent’s instructions as the system prompt. A blocked prompt fails the run before the agent starts, and the requester sees that Runlayer blocked it.
Client hooks — prompts submitted in clients with Runlayer hooks installed. Claude Code stops a blocked prompt before the model sees it; other clients record the finding as an alert.
Hooks SDK — bots built on the SDK call beforePrompt / before_prompt, which throws on a blocked prompt so the bot can refuse before calling its model.

Set its action under Settings → Security Scanners (default Alert). In Monitor mode a block is recorded but never enforced. If the scan errors or exceeds its time budget, the prompt goes through unscanned. A prompt over the workspace’s payload budget follows that budget’s action: skipped, truncated, or blocked. Client hooks send at most 5 MB, so a longer prompt is scanned only up to that size. Findings appear in Sessions: hover the shield next to a prompt to see the verdict, score, and attack categories. Blocks and alerts also open incidents.

Skill File Scanning

ToolGuard can also scan skill files uploaded to the platform. Each file’s content is analyzed using the same threat classification models. Repeat scans of unchanged content are served from cache, and large files are handled automatically. Skill file scanning runs when skills are uploaded via the CLI (skills push), imported from a GitHub URL, or created/updated via the API, producing per-file risk scores and an overall skill-level classification.

Skill Risk Policy

Admins can configure how the platform responds when a skill scan detects elevated risk. Navigate to Settings → Security Scanners to set the action for each risk tier:

Risk tier	Default action	Options
High	Block	Block, Alert, Allow
Medium	Alert	Block, Alert, Allow

Block — the skill import is rejected
Alert — the skill is imported with a warning badge visible in the UI; acceptance is logged to the Audit Log
Allow — the skill is imported without restriction

Low and Minimal risk skills are always allowed. These settings apply globally to all skill imports (CLI, API, web UI, and web import from GitHub).

Threat Categorization

Flagged tools are automatically classified into specific attack categories. The full taxonomy includes:

Prompt Injection
Data Exfiltration
Privilege Escalation
Destructive Action
Unauthorized Communication
Resource Abuse
Shadow Persistence
Context Poisoning
Guardrail Bypass
Supply Chain Compromise

Categories are not mutually exclusive — a single tool can match multiple categories. These labels appear in security violation details and audit logs, replacing generic “risky tool” messages with actionable context so you know what kind of threat was detected.

LLM categorization requires the Bedrock integration to be enabled in your deployment. When disabled, violations retain the default ToolGuard reason.

MITRE ATLAS Mapping

Runlayer maps known runtime findings, ToolGuard risk categories, and deterministic skill-scanner rules to the MITRE ATLAS AI threat taxonomy. Backend API responses expose the mapping metadata:

Security audit event details use atlas_techniques.
Incident groups, security tool scores, and skill import findings use atlas.

Each entry includes the ATLAS object ID, name, URL, and associated tactics. Unmapped findings return an empty list. A mapping indicates taxonomy alignment; it does not mean Runlayer detects every manifestation of an ATLAS technique.

What a Finding Shows

Findings explain the reasoning behind a risk assessment, not just a score. Each Tool List Guard finding includes:

Confidence score and risk tier — the model’s 0.0–1.0 score, mapped to a tier (see Risk Tiers)
Threat categories — the attack categories assigned by Threat Categorization (above)
Areas of concern — the specific excerpt of the tool definition that triggered the detection, displayed under Area of concern on the connector detail page alongside the tool’s name and full description — so reviewers see exactly which text caused the flag.

Tool Call Guard works the same way for blocked outputs: the finding includes the specific portion of the tool output that triggered the block, not just the score.

Additional specialized models are in development to address new attack vectors as they emerge in the MCP ecosystem.

Why Industry-Leading?

Purpose-Built for MCP - Custom-trained threat classification models specifically designed for MCP ecosystem attacks. High Performance - Fast inference with typical scan times of 50-100ms. Continuously Evolving - Models are regularly refined based on emerging threat patterns. Battle-Tested - Deployed in production environments protecting real-world MCP deployments. Enterprise-Ready - Complete audit logging, flexible configuration, and Security Dashboard integration.

Configuration

Navigate to Settings → Security Scanners to enable Runlayer ToolGuard models.

Scanner coverage

Different scanners run at different points in the agent flow:

Surface	Scanner coverage
User prompts	Prompt Guard scans submitted prompts from Runlayer agents and hooked clients.
Tool definitions	Tool List Guard scans names, descriptions, and schemas when a connector is registered or re-scanned.
Tool inputs	PII, credential, invisible-character, and Tool Intent Guard checks can inspect tool arguments before execution.
Tool outputs	Tool Call Guard, PII, credential, invisible-character, and Tool Intent Guard checks can inspect results before they reach the model.
Skill files	Skill file scanning runs on uploaded skill content before import.
Session trajectory	AgentGuard evaluates multi-turn agent behavior across the session trajectory rather than on individual tool calls.

User prompts and model responses appear in Sessions when full session scanning is enabled. Prompt Guard scans each submitted prompt; the other per-call ToolGuard scanners focus on MCP and local tool traffic; AgentGuard is the session-level scanner for behavior drift across the conversation.

Sensitivity Levels

Each scanner phase (Tool List Guard, Tool Call Guard, Tool Intent Guard) has a configurable sensitivity that controls how aggressively it flags findings:

Level	Behavior
Strict	Lowest tolerance — flags more items, fewer false negatives
Balanced (default)	Recommended for most environments
Moderate	Highest tolerance — fewer flags, useful for noisy connectors

Sensitivity is set globally in Settings → Security Scanners and can be overridden per connector, or per client or local tool. Connectors without an explicit override inherit the global value.

Scanner tuning is global, per-connector, or per-client. For self-hosted deployments, Tool List Guard risk-tier thresholds can also be tuned with the environment variables listed under Risk Tiers.

Violation Actions

Each scanner has a configurable action that controls what happens when it detects a finding. The available actions depend on the scanner type:

Action	Behavior
Block	Reject the request — the tool call does not proceed
Block (Self-Approve)	Block the request but allow the caller to approve and retry (per-connector only, PII scanner)
Mask	Redact or strip the detected content, then let the request continue
Alert	Log the detection but take no blocking action — the request proceeds unchanged
Allow	Disable the scanner entirely

Not every scanner supports every action. The table below shows which actions are available for each scanner:

Scanner	Allow	Alert	Mask	Block
PII detection	Yes	Yes	Yes (redact PII values)	Yes
Invisible character detection	Yes	Yes	Yes (strip hidden chars)	Yes
Credential detection	Yes	Yes	Yes (mask credentials)	Yes
ToolGuard ML scanners (Tool List Guard, Tool Call Guard, Tool Intent Guard)	Yes	Yes	—	Yes
Skill risk policy	Yes	Yes (warn on import)	—	Yes

Defaults: PII detection defaults to Alert. Invisible character detection and credential detection default to Mask. ToolGuard ML scanners default to Block. Actions are set globally in Settings → Security Scanners and can be overridden per connector or per client or local tool.

Per-Type Actions

PII detection, credential detection, and invisible character detection also take an action per detected type — each built-in PII type, each custom PII rule, each credential category, and each invisible-character category. Open the scanner’s rule list and pick an available action for that row; leaving it on Inherit follows the scanner’s own action. So a scanner set to Alert can still block Social Security numbers, mask email addresses, and ignore IP addresses entirely. Invisible character detection has six categories:

Category	What it matches	Incidents	Allow?
Hidden characters	Zero-width and bidirectional override characters, runs of zero-width spaces, SGR conceal and background colours, and OSC hyperlink or clipboard sequences	Yes	No
Control characters	NULL, BEL, backspace, DEL, cursor movement and erase sequences, and malformed or unclassified escape sequences	Yes	Yes; routine in raw terminal output, so allow it per connector rather than globally
ANSI colour codes	Escape sequences that only set text colour or style (`ESC[1m`, `ESC[38;2;…m`) — the terminal styling printed by colourised CLIs such as git, lefthook and pytest	When scanning is enabled	Yes; Allow is the default when no category rules have been saved
Encoded hidden text	Text smuggled through invisible Unicode encodings — tag characters, invisible math operators, interlinear annotation marks, misused bidirectional isolates, and dense runs of zero-width characters	When an action is set	Yes; Allow by default
Isolated zero-width characters	A single zero-width space, joiner or byte-order mark between ordinary characters (U+200B, U+200D, U+FEFF), plus soft hyphen (U+00AD), Mongolian vowel separator (U+180E), line and paragraph separators (U+2028, U+2029) and word joiner (U+2060). A joiner inside an emoji sequence is not matched	When an action is set	Yes; Allow by default
C1 control characters	The 8-bit control range U+0080 to U+009F, including the single-byte CSI (U+009B) that a terminal treats like `ESC[`	When an action is set	Yes; Allow by default

Wherever no category rules are in effect, ANSI colour codes, Isolated zero-width characters, C1 control characters and Encoded hidden text default to Allow. Ordinary colour output then produces no scanner event. An explicitly saved empty map instead makes every category inherit the scanner action; use Reset to default in the global rule dialog to restore the built-in ANSI allowance. Admins can set any category to Alert, Mask, or Block at any supported scope; detections then create incidents. Hidden characters is the one category that cannot be set to Allow individually. Setting the whole Invisible character detection scanner to Allow applies Allow to categories set to Inherit; any explicit per-category Alert, Mask, or Block action still runs. The last three categories are allowed by default, and saved category maps name them as Allow explicitly. Isolated zero-width characters is common in pasted text, so enable it per connector (a database, not a chat transcript) rather than globally. Encoded hidden text and C1 control characters are rarely legitimate; while they are allowed, Runlayer logs what they would have matched so the rate can be checked before enabling them. They follow the same scope rules as every other category. A narrower scope that overrides the scanner’s action without saving its own category rules stops using the broader scope’s rules; the built-in defaults apply there instead, so these three and ANSI colour codes stay allowed on that scope until you set an action on them. Allowing ANSI styling also allows foreground colours that may make text hard to see against a matching terminal background (for example, black text on a dark background). The scanner cannot infer the viewer’s terminal background from tool output, so it cannot check whether the text will be legible. The model still receives the text; this changes how it appears to a human viewing the terminal. Per-type actions follow the same scope rules as the scanner action: set them globally, then override them per connector, per client, per local-tool family, or per tool. Reset to global clears the overrides on that scope so its rows inherit again.

Custom Security Messaging

When a scanner blocks a call, Runlayer returns an explanation to the calling agent (and the user). By default this ends with generic guidance to contact your Runlayer administrator. Admins can replace that guidance with their own — for example, pointing users to a specific Slack channel or internal runbook instead of an inbox. Navigate to Settings → Security Scanners → Edit Security Messaging. Each message has a fixed prefix that is always shown (the violation details and audit-log link); your custom text replaces only the closing What to do guidance. A live preview shows exactly what agents will receive. The following messages can be customized:

Message	Shown when
Security block	A security scanner blocks a tool call
Self-approve	A block can be approved and retried by the caller
Policy denial	A policy denies a tool call or resource access
Connector disabled	Tools on a disabled connector are called
No access	Someone connects to a connector they have no access to

Messages support a small set of {{variable}} placeholders — such as {{server_name}}, {{tool_name}}, {{reason}}, and {{audit_log_link}} — that are filled in at runtime. The editor lists the variables available for each message. Leaving a message unset falls back to the built-in default.

PII Detection

PII scanning uses pattern-based detection with validators to identify sensitive data in MCP traffic. The following built-in PII types are detected:

Type	Description
SSN	US Social Security numbers and ITINs (never-issued ranges such as `000-00-0000` are ignored)
Credit Card	Card numbers (validated with Luhn check)
Phone	Phone numbers (with context validation)
Email	Email addresses
Passport	Passport numbers (with context validation)
Driver’s License	US driver’s license numbers
IBAN	International Bank Account Numbers
IP Address	Public IPv4 addresses (loopback, private, link-local, reserved, and documentation ranges are ignored)
Date of Birth	Dates of birth (with context validation)
MRN	Medical Record Numbers
VIN	Vehicle Identification Numbers (with checksum validation)
Bitcoin	Bitcoin wallet addresses
Ethereum	Ethereum wallet addresses

Admins can also add custom PII rules with regex patterns in Settings → Security Scanners. Custom rules run alongside built-in patterns and appear in audit logs with a CUSTOM label. Every built-in type and custom rule takes its own action — see Per-Type Actions. There is no PHI preset. MRN is the built-in health identifier, and it is label-anchored: it matches record numbers that appear next to an explicit identifying label, so an unlabelled bare number is not matched. Add custom PII rules for any other health identifiers your connectors carry, such as member or claim numbers, and for health identifiers that appear without a label.

Custom PII rule patterns use RE2 syntax (a linear-time engine, so a pathological pattern can’t slow down scanning) — see Regular Expression Syntax for the full set of supported features and the differences from Python re. A pattern RE2 cannot compile is rejected when you save the rule. If an older saved rule uses an unsupported construct, it is skipped — scanning continues with your other rules — and an audit event plus an admin alert flags the rule so you can update it (most lookarounds rewrite cleanly with anchors or \b).One quieter change to watch for: the shorthand classes \d, \w, \s and the word boundary \b are ASCII-only. A rule using them on non-ASCII text still saves and runs but matches differently — in both directions. \d/\w match less (non-Latin digits and accented letters no longer count), so a rule can silently miss PII. \b can also match more: an accented letter now counts as a word boundary, so \bSECRET\b matches inside éSECRETé where it previously didn’t — new masking, alerting, or blocking can fire. Neither shift is rejected or alerted, so review rules that touch non-ASCII text. Where you need Unicode-aware matching, spell it out with an explicit range or a Unicode property class (e.g. \p{L} for letters, \p{Nd} for decimal digits).

PII masking redacts matched values before the request continues.

PII Scan Direction

PII detection can be applied to tool inputs, outputs, or both. The direction controls which traffic the PII scanner inspects:

Direction	Behavior
Input (default; Outbound in the app)	Scans data sent to MCP tools
Output (Inbound in the app)	Scans data returned from MCP tools
Both	Scans in both directions

Set the direction globally in Settings → Security Scanners (the gear button on the PII detection row) and override it per connector or per client or local tool. Connectors without an override inherit the global value.

Per-connector overrides

A connector can have its own scanner actions, PII direction, per-type actions, and sensitivity. Anything left on inherit keeps following Settings → Security Scanners. Changing these settings requires the Manage security policies capability.

Open the connector's Security tab

Go to Settings → Manage connectors, click the connector, then open its Security tab.

Pick an action

Under Security Scanners, open the scanner’s dropdown and pick an action. PII, credential, and invisible character detection offer Allow, Alert, Mask, and Block; the ToolGuard rows offer Allow, Alert, and Block. The row then reads Override: followed by the action. Inherit Global Settings goes back to the global action.

Tune the details

Click the gear button next to the dropdown. For PII detection this opens Configure PII rules: set Scan direction (Outbound, Inbound, Both, or Inherit), give any row under Built in rules or Custom rules its own action, then click Save. Credential and invisible character detection open the same kind of rule list. ToolGuard rows open Detection sensitivity (Moderate, Balanced, or Strict).

Override one tool (optional)

Under Per-tool overrides, choose a tool in Select tool and set its call-time scanners. A tool override wins over the connector’s settings.

To undo, click Reset to global in a rules dialog and then Save, or click Reset All to Global at the top of the Security Scanners card to clear every connector-wide override. Per-tool overrides are kept until you reset them in Per-tool overrides.

Client and local tool overrides

Exceptions for one client (for example Claude Code, Cursor, or the browser extension) or one kind of local tool live at the bottom of Settings → Security Scanners, under Local Tools and Client Overrides.

Open Select local tool or client and choose a client, a local tool family (Terminal, Filesystem, or WebFetch), or a single tool under Individual tools.
Click Add override, choose a scanner, and pick its action. The gear button opens the same PII direction, per-type, and sensitivity settings as on a connector.
Reset clears one override; Reset all clears every override for that client or tool.

A single local tool inherits from its family first, then from the global settings.

Risk Tiers

Tool List Guard assigns a risk tier to each scanned tool based on its confidence score. The default thresholds are:

Tier	Score Range	Meaning
Minimal	< 0.6	Clean scan, no concern
Low	0.6 – 0.7	Low-confidence flag
Medium	0.7 – 0.9	Elevated risk, review recommended
High	≥ 0.9	High-confidence detection

Self-hosted deployments can tune these thresholds via environment variables:

RUNLAYER_TOOL_GUARD_LIST_RISK_THRESHOLD_LOW (default 0.6)
RUNLAYER_TOOL_GUARD_LIST_RISK_THRESHOLD_MEDIUM (default 0.7)
RUNLAYER_TOOL_GUARD_LIST_RISK_THRESHOLD_HIGH (default 0.9)

If you don’t see Runlayer ToolGuard options, you need to configure your Runlayer deployment to enable the GPU ToolGuard infrastructure. See deployment documentation for setup instructions.

Submitting Feedback

When a ToolGuard scan result is wrong — a benign tool flagged as risky (false positive) or a risky one that slipped through (false negative) — you can report it back to Runlayer. Feedback is used to improve future model accuracy. Submit feedback to the same API surface as the scoring endpoints, authenticated with an organization API key that has the Security Scan role (sent in the x-runlayer-api-key header):

curl -X POST "$RUNLAYER_BASE_URL/api/v1/security/feedback" \
  -H "x-runlayer-api-key: $RUNLAYER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "tool_call",
    "feedback_type": "false_positive",
    "human_label": "allow",
    "notes": "Internal reporting tool — the output is expected, not exfiltration.",
    "scan_context": {
      "tool_name": "generate_report",
      "score": 0.94,
      "decision": "block"
    }
  }'

Field	Required	Description
`endpoint`	Yes	Which score endpoint the feedback is about: `tool_list`, `tool_call`, `tool_guard_io`, or `skill`
`feedback_type`	Yes	`false_positive` (flagged but safe) or `false_negative` (missed a real risk)
`human_label`	Yes	The label you believe is correct. Canonical values are `block` / `allow`, but any short label is accepted
`notes`	No	Free-form context explaining the correction
`scan_context`	No	The scanned payload plus the score/decision you disagree with, echoed back for triage

A successful submission returns 201 with a submission_id. Feedback is retained per organization for model review.

Feedback submission isn’t available in certain self-hosted cloud environments. Where it’s unavailable, the endpoint returns 503.

Monitoring

Security Dashboard - View detection timelines, violation trends, and common threat types Connector Pages - Tool List Guard warnings appear directly on connector detail pages when potentially risky tools are detected Audit Logs - Full history of detections, blocks, and configuration changes with confidence scores Sessions - Review scanner outcomes in full AI session timelines AgentGuard - Session-level behavior monitoring across the agent trajectory

Best Practices

Use per-server overrides for high-risk external servers
Use per-client overrides when specific AI clients (e.g., IDE vs. browser) need different scanner behavior
Combine with MCP access policies for layered security
Review flagged tools with your security team before blocking

Staying Ahead

Runlayer ToolGuard models are continuously refined based on emerging threat patterns in the MCP ecosystem. Our commitment to continuous innovation ensures you have industry-leading defenses as new attack techniques emerge. Deployed model versions are tracked in the ToolGuard Model Versions changelog.

Model Attribution

The Runlayer ToolGuard suite utilizes GA Guard Lite for threat classification embeddings and model inputs. GA Guard Lite is licensed under Apache 2.0.

Security Best Practices

MCP security guidelines and recommendations

Audit Logs

View detailed activity and security logs

Sessions

Monitor scanner outcomes in AI session timelines

AgentGuard

Session-level behavior monitoring across the agent trajectory

Access Policies

Configure MCP access control policies

​Industry-Leading AI Security for MCP Ecosystems

​The Models

​Tool List Guard

​Tool Call Guard

​Tool Intent Guard

​Prompt Guard

​Skill File Scanning

​Skill Risk Policy

​Threat Categorization

​MITRE ATLAS Mapping

​What a Finding Shows

​Why Industry-Leading?

​Configuration

​Scanner coverage

​Sensitivity Levels

​Violation Actions

​Per-Type Actions

​Custom Security Messaging

​PII Detection

​PII Scan Direction

​Per-connector overrides

​Client and local tool overrides

​Risk Tiers

​Submitting Feedback

​Monitoring

​Best Practices

​Staying Ahead

​Model Attribution

​Related Resources

Security Best Practices

Audit Logs

Sessions

AgentGuard

Access Policies

Industry-Leading AI Security for MCP Ecosystems

The Models

Tool List Guard

Tool Call Guard

Tool Intent Guard

Prompt Guard

Skill File Scanning

Skill Risk Policy

Threat Categorization

MITRE ATLAS Mapping

What a Finding Shows

Why Industry-Leading?

Configuration

Scanner coverage

Sensitivity Levels

Violation Actions

Per-Type Actions

Custom Security Messaging

PII Detection

PII Scan Direction

Per-connector overrides

Client and local tool overrides

Risk Tiers

Submitting Feedback

Monitoring

Best Practices

Staying Ahead

Model Attribution

Related Resources