AI-Interceptorby Prak Knit
← → to navigate · F fullscreen · Ctrl+P to save as PDF
AI Infrastructure Security Scanner
AI-Interceptor
Nessus and Qualys do not understand LangChain, prompt injection, agent tool permissions or a RAG pipeline. This does.
Find the AI you didn't know you had. Then find what it can reach.
Your scanner has never heard of any of this.
Traditional vulnerability scanners were built for hosts, ports and CVEs. An AI stack barely resembles that shape — and every element below is invisible to them.
A port scan finds an open 8000. It cannot tell you that behind it sits an agent with shell access and no human approval step.
The question no one can answer:
where is AI running in your organisation?
Developers add openai, langchain, anthropic or crewai to a service without telling anyone. Shadow AI is the norm, not the exception.
6
discovery sources, ranked by reliability
25+
framework fingerprints
12
IDE configs scanned for MCP servers
10
inference port patterns
Kubernetes control-plane first, network sweep last — because a stable service DNS name survives a restart and an IP does not.
Discovery, in priority order
Each source is more reliable than the one below it. The scanner prefers asking the control plane over guessing from the network.
01 · Kubernetes control planeServices, Deployments and Jobs via ServiceAccount or kubeconfig. Framework read from annotation, then label, then image, then port.
02 · AWS computeECS task definitions, Lambda function URLs — flagging any with auth set to NONE — and App Runner images.
03 · Managed cloud AISageMaker endpoints, Bedrock access, Azure OpenAI deployments, Vertex AI and Gemini.
04 · Model registriesHuggingFace at org and model level: gated models, unsafe tensor formats, model-card gaps.
05 · Developer workstationsMCP stdio configs across 12 IDEs, plus explicit filesystem paths for model files and stray .env secrets.
06 · Network sweep — last resortOff unless enabled. IDS-safe: bounded concurrency with jitter, TLS verification on, and a logged warning whenever it runs.
Six phases. One chain.
Each phase triggers the next, and every phase produces findings against a specific AI asset rather than a hostname.
Phase 1DiscoveryFind AI assets across Kubernetes, AWS, cloud, registries, filesystem and network
Phase 2Vulnerability scanCVE matching, framework version fingerprint, pickle and ONNX deserialization, supply chain
Phase 3RAG probePrompt injection surface, vector DB tenant isolation, context window abuse
Phase 4RuntimeBehaviour baseline, tool-call anomalies, resource profiling
Phase 5Agentic remediationGenerates the exact patch — YAML, HCL, NetworkPolicy, IAM JSON — under a 3-tier safety model
Phase 6ComplianceOWASP LLM Top 10, MITRE ATLAS, NIST AI RMF, EU AI Act scoring
An agent is not risky because it exists.
It's risky because of what it can reach.
So the analysis does not stop at "found an agent". It walks four layers to work out the blast radius.
L1 · InventoryFramework, host, port, auth status, risk score
L2 · PermissionsTools it can invoke, and the IAM role it actually runs as — Kubernetes RoleBindings, ECS task roles, Lambda execution roles resolved to real statements
L3 · Data contextInput sources, output sinks, PII in the flow, context-window risk
L4 · BehaviourSeven live HTTP probes against the running agent
The finding that matters: this agent's IAM role grants more than its declared tool list implies.
The data bridge — how exfiltration actually happens
Prompt injection is only dangerous when untrusted input can reach a trusted sink. The scanner looks for exactly that path.
Untrusted inWeb · user prompt · retrieved documentsContent an attacker can influence
ContextSystem prompt · tool descriptions · memoryWhere injected instructions land
Trusted outEmail · database write · webhook · code repositoryWhere the damage lands
An agent that reads the open web and can also send email is one instruction away from being an exfiltration channel. That pairing is the finding — not either half on its own.
Seven probes. No API key required.
Behavioural testing runs as plain HTTP against the agent's own endpoint, with request builders per framework — LangServe, Flowise, AutoGen, Dify, Haystack or generic.
Instruction overrideCan injected text displace the system prompt?
Scope boundaryWill it act outside its declared purpose?
Prompt leakageCan the system prompt be extracted?
JailbreakClassic DAN and role-play bypasses.
Autonomy escalationUnauthorised tool chaining or self-replication.
Harmful refusalDoes it still refuse what it should?
Output consistencySame question twice — same answer?
PII rules that know which country you're in
A pattern set written for the US misses Aadhaar and PAN entirely. The policy engine is database-driven and per-tenant, not a hardcoded list.
Generic baseline
GDPR · EU
HIPAA · US
DPDP · India
PCI-DSS · global
Custom patterns
40+
seeded patterns across five jurisdictions
5
India-specific: Aadhaar, PAN, Voter ID, UPI, GST
Per-tenant
enable, disable or override at runtime
Cross-border data flow is its own finding: PII leaving the jurisdiction it was collected in.
It proposes the fix. It does not quietly apply it.
Remediation is generated as a concrete artifact, then held behind a safety tier. Nothing touching production executes on its own.
Tier 1 · AnalysisAn informational note. No infrastructure change, no model call. Written up as documentation.
Tier 2 · ProposalThe exact artifact — YAML patch, Terraform, NetworkPolicy, IAM restriction. Requires a human to approve. Never auto-executes.
Tier 3 · Manual guideStep-by-step instructions for secret rotation, IAM admin changes, production restarts. Cannot be approved through the API at all — the route refuses.
The tier is decided by what the fix touches, not by how confident the model is.
Mapped to the frameworks your auditor already asks about
Findings carry their framework references, so an AI finding lands in the same compliance conversation as everything else.
OWASP LLM Top 10 (2025)LLM01 through LLM10 mapped across the rule set.
MITRE ATLASAdversarial ML techniques AML.T0040–T0054.
NIST AI RMFGovern, Map, Measure and Manage.
EU AI ActHigh-risk system controls, Articles 9–15.
It doesn't sit in a corner on its own
AI-Interceptor is a standalone service with its own database and queue, and it pushes findings into Klair Vu — so AI risk lands in the same risk picture as everything else you run.
Runs besideYour infrastructureKubernetes, AWS, managed cloud AI, developer workstations
Scans asAI-InterceptorRead-only discovery. Kubernetes access is get and list only.
Reports intoKlair VuFindings join the risk funnel, mapped to applications and business units
Separate databases, no shared tables and no cross-system foreign keys — the scanner cannot reach into your risk data, and vice versa.
Start where the blind spot is largest
Most organisations do not need a year-long programme. They need to know what AI is running and which agents can reach something they shouldn't.
Week 1 · DiscoverPoint it at one Kubernetes cluster or one AWS account. Get the inventory you don't currently have.
Week 2 · AssessAuth posture, TLS, exposed model endpoints, known CVEs in AI frameworks, unsafe model formats.
Week 3 · ReachResolve what each agent can actually do — tools plus the IAM role behind them.
Week 4 · ReportCompliance posture against OWASP LLM, ATLAS, NIST AI RMF and the EU AI Act.