Skip to main content
Glama
subodhkc

haiec-ai-agent-security-free-mcp

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-appsec

Or use via npx without global install:

npx ai-appsec doctor
npx ai-appsec setup

Prerelease channel: @next tracks 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 setup

Semgrep is NOT bundled with this package. It is an external engine installed separately. See THIRD_PARTY_NOTICES.md for details.

Limitations

  • Only scan_ai_security is implemented in v0.1

  • Static 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:

  1. Do not disclose it publicly before review.

  2. Report via GitHub private vulnerability reporting.

  3. 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.

  • LLMVerify — LLM content verification (independent product, separate repository)

  • Tenant Isolation — Cross-tenant boundary checks (independent product, separate repository)

Available Tools

1 tool
scan_ai_securityScan AI/LLM Source Code SecurityA
Read-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).

ParametersJSON Schema
NameRequiredDescriptionDefault
timeoutNoScan timeout in seconds. Default: 300.
targetPathYesAbsolute or relative path to the AI application source code to scan.
extendedScopeNoInclude tests/docs/examples in the scan. Default: false (production scope only).

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsYes
scanIdYes
receiptNo
summaryYes
verdictYes
versionsYes
truncationYes
limitationsYes
completenessYes
observationsYes
schemaVersionYes
evidenceEnvelopeNo
actionableFindingsYes
completenessReasonsYes
evaluatedDetectorIdsYes
securityConcernFamiliesYes
evaluatedSecurityCheckIdsYes

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.1.0
    • First observedscan_ai_security

TDQS

A4.4/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness3/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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