Developer Security for AI Applications
Security checks where AI is built — across source code, tenant boundaries, and model I/O. Produce deterministic technical evidence developers can use in the IDE, CI pipeline, security review, and HAIEC assurance workflows.
Three Security Surfaces. Three Independent Checks.
AI applications have three distinct security surfaces. Each requires a different kind of check. These are independent tools — one does not perform the functions of another.
Layer by Layer
Each layer addresses a different security problem, runs in a different place, and produces different evidence.
AI AppSec
Security problem
AI applications and agents have source-code-level security risks: unsafe tool execution, secrets exposure, prompt injection in code paths, and RAG/model integration gaps. These must be caught before commit or merge.
What is checked
Audit AI application and agent source code before commit, push, merge, or deployment — with explicit coverage, reproducible findings, and tamper-evident security evidence. Uses Semgrep 1.173.0 as its execution engine with a bundled Public Core rulepack.
Where it runs
Semgrep 1.173.0 (external engine) with bundled Public Core rulepack. Static analysis only — does not execute target code.
Evidence / output produced
- •Scan Receipt (SHA-256 digests for finding set, concern families, coverage, evaluated checks)
- •Evidence Envelope (binds receipt to execution context, producer identity, target identity)
- •Proof-of-fix comparison (STILL_PRESENT, NEW, NOT_VERIFIABLE)
- •Coverage accounting (DISCOVERED, INTENTIONALLY_EXCLUDED, UNSUPPORTED, TARGETED, ENGINE_REPORTED_SCANNED, PARSE_FAILED, SUCCESSFULLY_ANALYZED)
Install
$ npm install -g ai-appsecAI IDE / MCP
MCP identifier: io.github.subodhkc/ai-appsec · Transport: stdio
{
"mcpServers": {
"ai-appsec": {
"command": "npx",
"args": ["-y", "ai-appsec"]
}
}
}Limitations
- •Static analysis only — no runtime behavioral evidence
- •No compliance certification or assessment
- •No tenant isolation checking (roadmap)
- •No LLM content verification (roadmap)
- + 4 more — see product page
MCP Tenant Isolation
Security problem
Multi-tenant SaaS and MCP servers can leak data across tenants when queries, cache keys, file access, API responses, or MCP tool visibility are not properly scoped to the authenticated tenant.
What is checked
Detect cross-tenant security gaps across queries, APIs, caches, files, credentials, sessions, vector stores, and MCP tools before they become production data leaks. 57 deterministic rules covering tenant isolation, tool visibility, cache key scoping, RLS, IDOR, and credential vault isolation.
Where it runs
Babel AST parser for TypeScript/JavaScript. Dedicated Prisma schema parser. SQL migration parser for RLS detection. MCP SDK import detection. IR and Flow Graph with intra-procedural taint tracking.
Evidence / output produced
- •Scan Receipt (SHA-256 hash, rulepack digest, timestamp)
- •Evidence Envelope for verifiable scan artifacts
- •v2 semantic fingerprints (stable under line movement)
- •Proof-of-fix tracking (STILL_PRESENT, NEW, NOT_VERIFIABLE)
Install
$ npm install -g mcp-tenant-isolationAI IDE / MCP
MCP identifier: io.github.subodhkc/mcp-tenant-isolation · Transport: stdio
{
"mcpServers": {
"tenant-isolation": {
"command": "npx",
"args": ["-y", "mcp-tenant-isolation", "mcp"]
}
}
}Limitations
- •Intra-procedural flow analysis only — does not trace across function calls, files, or middleware boundaries
- •No runtime verification — cannot verify database-level RLS enforcement or middleware execution
- •TypeScript and JavaScript only — Python, Go, Ruby not supported yet
- •False positives are possible — pattern-based detection with FP filtering
- + 1 more — see product page
LLMVerify
Security problem
LLMs hallucinate facts, leak PII in responses, follow prompt injections buried in user input, and drift in quality. You need a guardrail between the model output and your users.
What is checked
A safety layer that sits between your LLM and your users. Deterministic, pattern-based engines run locally — no model calls, no network on the free tier. Same input plus same rules equals same result. Every result carries an explicit limitations array stating what was and was not checked.
Where it runs
Deterministic, pattern-based engines running locally. No model calls, no network on free tier. Free tier limit: 500 verification calls/day (tracked locally).
Evidence / output produced
- •Risk level and findings per verification
- •Explicit limitations array per result
- •Hash-only audit log entries (SOC 2 / HIPAA / GDPR evidence)
- •Runtime monitoring metrics (latency, token drift, behavioral changes)
Install
$ npm install llmverifyLimitations
- •Cannot definitively prove hallucinations — signals are pattern-based, not ground-truth verification
- •Does not replace human review — use to triage, not to approve
- •PII detection is regex-based (~90% for standard formats, lower for variations)
- •Prompt-injection detection is pattern-based — novel or obfuscated injections can evade it
- + 2 more — see product page
Developer Security vs HAIEC Platform Validation
Developer Security tools check your code and model I/O. They do not provide complete AI assurance. HAIEC Platform Validation adds runtime adversarial testing, regulatory control evaluation, and assurance workflows.
Developer Security
- •Static source-code analysis (AI AppSec)
- •Tenant boundary isolation checks (MCP Tenant Isolation)
- •LLM I/O verification and guardrails (LLMVerify)
- •Runs in IDE, CI/CD, or local CLI
- •Produces deterministic, reproducible evidence
- •No HAIEC account required for the open-source packages
HAIEC Platform Validation
- •Runtime adversarial testing against live AI systems
- •Regulatory control evaluation (SOC 2, ISO 42001, EU AI Act, NYC LL144)
- •Audit Orchestrator combining static, runtime, and regulatory results
- •Tamper-evident, SHA-256 signed report generation
- •Compliance Twin for continuous compliance history
- •Assurance workflows for auditor review and sign-off
This is not complete AI assurance.
Developer Security tools find code-level and I/O-level risks. They do not test runtime behavior, evaluate regulatory controls, or produce compliance certifications. For assurance workflows, use HAIEC Platform Validation alongside these developer tools.
Also from HAIEC
Separate from Developer Security — for inventory, evidence, and compliance support.
AI Inventory
Discovery, cataloging, and monitoring of AI systems, provider usage, and model consumption. Includes @haiec/openai and @haiec/anthropic instrumentation packages.
ISAF Logger
Evidence generation for AI training lineage. Logs Layers 6-9 (Framework, Data, Objectives, Deployment) with SHA-256 hash chains. Not a security scanner — a lineage evidence utility.
Explore ISAF Logger