haiec-ai-agent-security-free-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@haiec-ai-agent-security-free-mcpRun tenant isolation check on the latest changes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI AppSec
Evidence-backed AppSec for AI applications and agents.
Powered by HAIEC.
Audit AI code for security risks before you commit, push, merge, or deploy.
What AI AppSec Does
AI AppSec produces deterministic, reproducible static security evidence for AI-agent and AI-application source code. It uses Semgrep 1.173.0 as its execution engine with a bundled Public Core rulepack (122 detectors, 79 security checks).
Key properties:
Static analysis only — does not execute target code
No network required for normal scans (Semgrep setup may require network)
No HAIEC account or API key required
Deterministic evidence — Scan Receipts with SHA-256 digests
Fail-closed digests — rulepack/manifest verified at runtime
Proof-of-fix — rescan comparison with check-evaluation safety
Related MCP server: Rigour MCP
Quick Start
# Install
npm install -g ai-appsec
# Check Semgrep status
ai-appsec doctor
# Install Semgrep engine (requires network)
ai-appsec setup
# Start MCP server (stdio transport)
ai-appsecOr use via npx without global install:
npx ai-appsec doctor
npx ai-appsec setupPrerelease channel:
@nexttracks upcoming prereleases (e.g.ai-appsec@next).
When to Use It
Use scan_ai_security when a developer asks to:
"check this for security issues"
"audit this task before I push"
"review this change for security problems"
"scan this AI agent" or "scan this AI app"
"check my LLM application"
"security review this PR"
"is this safe to merge"
"check this before deployment"
"audit this code for vulnerabilities"
"run a security scan"
"check for security risks before commit"
scan_ai_security
The MCP tool scan_ai_security is the only tool implemented in v0.1.
It scans AI/LLM/agent application source code for security risks including:
Unsafe AI-output execution
Secrets exposure
RAG/model integration risks
Insecure AI API usage
Control gaps
Prompt/input-related risk signals
What scan_ai_security Does NOT Do
Does not provide complete AI system assurance
Does not provide runtime behavioral assurance
Does not provide compliance certification
Does not guarantee zero false positives
Does not prove root causes for concern families
Does not execute target code, install dependencies, or run package managers
Does not perform compliance assessment (compliance requires additional HAIEC evidence)
Findings
Findings are classified by:
Finding kind: PRESENCE, RISK_SIGNAL, CONTROL_GAP, VULNERABILITY
Severity: CRITICAL, HIGH, MEDIUM, LOW, INFO
Disposition: INFORMATIONAL, REVIEW, BLOCK
Security Concern Families
Security Concern Families summarize semantically compatible finding instances for decision-quality presentation. A concern family is a deterministic grouping view — it is NOT necessarily one vulnerability, one material issue, or one root cause. Underlying finding instances remain auditable.
Concern family count is not a vulnerability count. Top 20 / Top 50 are presentation limits, not evidence limits.
COMPLETE / PARTIAL / ERROR
COMPLETE: All supported files in scope were successfully analyzed.
PARTIAL: Some supported files could not be analyzed (e.g., parser failures). PARTIAL scans cannot prove absence of findings. Missing evidence is never interpreted as PASS.
ERROR: The scan could not complete due to an engine error.
Coverage
AI AppSec provides explicit coverage accounting:
DISCOVERED: all files found beneath the target
INTENTIONALLY_EXCLUDED: files excluded by scope policy
UNSUPPORTED: files outside supported extensions (.py, .js, .jsx, .ts, .tsx)
TARGETED: supported files intended for analysis
ENGINE_REPORTED_SCANNED: files Semgrep reports as scanned
PARSE_FAILED: files with parse errors
SUCCESSFULLY_ANALYZED: scanned minus parse failures
Scan Receipt
Every scan produces a tamper-evident Scan Receipt with SHA-256 digests for:
Finding set
Concern family set
Coverage file sets
Evaluated security checks and detectors
Semantic receipt identity
COMPLETE scans produce reproducible receipts across processes and operating systems. PARTIAL scans preserve run-specific coverage differences.
Evidence Envelope
Each scan produces an Evidence Envelope that binds the receipt to the scan execution context, including:
Producer identity
Target identity (scan input digest, git commit, dirty state)
Execution status and completeness
Semantic receipt digest
Envelope digest
Proof-of-fix
Rescan a target after a fix to compare receipts. The proof-of-fix comparison is safe: it verifies that a specific security check's findings were resolved without requiring the entire scan to be identical.
Offline / Local Operation
Normal scanning operates fully offline after prerequisites are installed:
No HAIEC cloud access required
No account or API key required
No rule download during scanning
No telemetry emitted (Semgrep invoked with
--metrics off)
Semgrep setup (ai-appsec setup) may require network access to install the
engine. Once installed, all scanning is local.
Semgrep Prerequisite
scan_ai_security requires Semgrep 1.173.0 (exact version match).
# Check Semgrep status
ai-appsec doctor
# Install managed Semgrep (requires network)
ai-appsec setupSemgrep is NOT bundled with this package. It is an external engine installed separately. See THIRD_PARTY_NOTICES.md for details.
Limitations
Only
scan_ai_securityis implemented in v0.1Static analysis only — no runtime behavioral evidence
No compliance certification or assessment
No tenant isolation checking (roadmap)
No LLM content verification (roadmap)
No deploy security gating (roadmap)
License
MIT License
Copyright (c) 2026 HAIEC
See LICENSE for the full license text.
Security Reporting
If you believe you have found a security vulnerability:
Do not disclose it publicly before review.
Report via GitHub private vulnerability reporting.
For non-sensitive bugs, use GitHub Issues.
No bug bounty program exists at this time. This project is maintained by a small team. We appreciate responsible disclosure and patience.
Roadmap
Future HAIEC capabilities (not yet implemented in this package):
Tenant isolation checking (
scan_tenant_isolation)LLM/runtime content verification (
verify_llm_content)Deploy security gating (
check_deploy_security)Native deterministic dataflow analysis
Runtime evidence
Inventory evidence
Regulatory evidence
Compliance/assurance integration
Compliance Twin
These will remain independent products/engines. See the HAIEC architecture principle: one workflow, four independent checks.
HAIEC
AI AppSec is powered by HAIEC. HAIEC is the broader assurance platform that may combine ai-appsec evidence with runtime, inventory, regulatory, and external evidence for broader compliance and assurance in the future.
Founder-led development with HAIEC acting as the release gatekeeper for provenance, licensing, and publication.
Related Projects
LLMVerify — LLM content verification (independent product, separate repository)
Tenant Isolation — Cross-tenant boundary checks (independent product, separate repository)
Available Tools
1 toolscan_ai_securityScan AI/LLM Source Code SecurityARead-only
Audit AI applications and agents for security risks before commit, PR, merge, or deployment. Produces deterministic findings with explicit coverage, Security Concern Families, Scan Receipts, and Evidence Envelopes.
USE when a developer asks to:
"check this for security issues"
"audit this task before I push"
"review this change for security problems"
"scan this AI agent" or "scan this AI app"
"check my LLM application"
"security review this PR"
"is this safe to merge"
"check this before deployment"
"audit this code for vulnerabilities"
"run a security scan"
"check for security risks before commit"
"review this implementation before pushing"
Also use for:
reviewing AI/LLM/agent source code for security
validating AI code before merge
checking an agent before deployment
reviewing RAG or model integration security
looking for unsafe AI source-code patterns
checking AI-output-to-dangerous-action flows
checking AI source-code secrets/security controls
DO NOT use for:
actual LLM response/content verification (use verify_llm_content)
tenant/RLS/cross-customer isolation (use scan_tenant_isolation)
generic compliance questionnaires or compliance certification
generic non-AI source scanning where no AI check applies
This tool performs static analysis only. It does NOT execute target code, make network requests, or emit telemetry. BLOCK findings are advisory — deployment enforcement is handled by check_deploy_security (not yet implemented).
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | Scan timeout in seconds. Default: 300. | |
| targetPath | Yes | Absolute or relative path to the AI application source code to scan. | |
| extendedScope | No | Include tests/docs/examples in the scan. Default: false (production scope only). |
Output Schema
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| scanId | Yes | |
| receipt | No | |
| summary | Yes | |
| verdict | Yes | |
| versions | Yes | |
| truncation | Yes | |
| limitations | Yes | |
| completeness | Yes | |
| observations | Yes | |
| schemaVersion | Yes | |
| evidenceEnvelope | No | |
| actionableFindings | Yes | |
| completenessReasons | Yes | |
| evaluatedDetectorIds | Yes | |
| securityConcernFamilies | Yes | |
| evaluatedSecurityCheckIds | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint annotation: states it performs static analysis only, does not execute target code, does not make network requests, does not emit telemetry, and explicitly notes that BLOCK findings are advisory with deployment enforcement not yet implemented. This is strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose and then organized into use, non-use, and behavioral sections. The trigger phrase list is somewhat repetitive, but the structure is effective and the information density is high for an agent-facing tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It covers the tool's scope, safety characteristics, exclusions, alternatives, and advisory nature, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (targetPath, timeout, extendedScope) are already documented in the schema. The description does not add parameter-level detail, but with full schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Audit AI applications and agents for security risks before commit, PR, merge, or deployment.' It also distinguishes itself from related tools by naming alternatives in the DO NOT use section, such as verify_llm_content and scan_tenant_isolation, even though no siblings are listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an extensive USE when list of concrete developer intents, a separate 'Also use for' list of scenarios, and an explicit DO NOT use section that points to alternative tools. This gives an agent clear routing guidance and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
scan_ai_security
TDQS
Only one tool is exposed, so there is no possibility of confusing it with another tool. The description also explicitly lists out-of-scope use cases, which helps clarify the intended boundary.
The single tool name 'scan_ai_security' follows a clear snake_case verb_noun convention. With only one name, there are no conflicting patterns or inconsistent verb styles to penalize.
One tool is a minimal, thin surface for the stated security-audit workflow. It can handle the core scanning request, but the surface feels sparse given the referenced verify_llm_content, scan_tenant_isolation, and not-yet-implemented check_deploy_security operations.
The scan tool covers static analysis and returns structured findings, but the workflow has a clear dead end: BLOCK findings are advisory and deployment enforcement is explicitly not yet implemented. There is also no way to manage or act on findings beyond the initial scan.
Maintenance
Related MCP Connectors
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceProvides pre-deploy AI-assisted security and readiness checks for AI-built apps, including scanning for secrets, auth gaps, and payment safety.5MIT

Rigour MCPofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to self-govern by scanning code for hardcoded secrets, structural violations, and AI drift in real-time, providing fix packets for automatic remediation.26MIT
Draugrofficial
AlicenseNot gradedqualityAmaintenanceSecurity scanning for AI agents: SAST, SCA, secrets, IaC, DAST, ranked by real risk.4Apache 2.0- AlicenseAqualityDmaintenanceSecurity scanning, prompt injection detection, secret leak detection, and agent permission auditing for AI agent workflows.855MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/subodhkc/ai-appsec'
If you have feedback or need assistance with the MCP directory API, please join our Discord server