DEV Community

Mike Anderson
Mike Anderson

Posted on

Shodan for Red and Blue Teams: External Attack-Surface Intelligence with an AI Analysis Harness

#cybersecurity #kali #security #ai

Educational purpose only for Red team and Blue team cyber operations. Do not use for any destructive purpose and this blog will neither be responsible nor supporting for any destructive activities.

This notice applies to every procedure, example, architecture, and code sample in this article.

All targets shown below use documentation/example domains or RFC 5737 documentation address space unless explicitly stated otherwise. Replace them only with infrastructure you own or are formally authorized to assess.

Authorization rule: Shodan search is generally passive from the analyst's point of view because the analyst is querying Shodan's collected dataset rather than directly probing the target. Shodan also provides active, on-demand scanning capabilities. Treat those as a separate class of action requiring explicit authorization and approval.

Why Shodan matters to a security team

Shodan is best understood as an external service-intelligence and attack-surface observation platform.

Its core value is not simply "finding vulnerable devices." Shodan collects service banners and associated metadata from Internet-facing services and makes that data searchable through its web interface, CLI, APIs, Monitor capabilities, and data feeds.

For a security team, the useful question is:

What does the Internet appear to expose, and does that match what we intended to expose?

That question is valuable to both sides of an authorized security operation.

A blue team can compare Shodan observations against authoritative cloud inventory, CMDB records, Cloudflare configuration, firewall policy, Kubernetes ingress configuration, and vulnerability-management data.

A red team can use previously collected Internet observations to reduce unnecessary active scanning, establish attack-surface hypotheses, and prioritize authorized validation.

The important distinction is:

Shodan observation
        ≠
confirmed vulnerability
        ≠
current exposure
        ≠
proof of exploitability
Enter fullscreen mode Exit fullscreen mode

Shodan is evidence. It is not, by itself, final proof.

Operational rules before using Shodan

These five rules eliminate a large percentage of bad Shodan analysis:

Shodan observation        ≠ current exposure
Shodan CVE association    ≠ confirmed vulnerability
Internet visibility       ≠ asset ownership
LLM classification        ≠ authorization
Passive Shodan query      ≠ active Shodan scan
Enter fullscreen mode Exit fullscreen mode

Why this matters:

  • Shodan data is collected asynchronously, so an observed service may have changed since collection.
  • Banner and vulnerability metadata can generate strong hypotheses, but authenticated inventory or safe validation is still required.
  • An IP that appears related to your organization may belong to a cloud provider, CDN, vendor, or previous tenant.
  • An AI model must never be allowed to decide its own target scope.
  • Shodan's on-demand scanning capability causes Shodan infrastructure to actively scan the submitted target and therefore belongs behind an explicit approval gate.

Installing Shodan on Kali Linux

Why modern Kali prefers APT or pipx

Current Kali protects its system Python environment using the PEP 668 externally-managed environment model.

In practical terms, this means Kali tries to prevent direct pip installations from overwriting Python packages that are managed by APT.

That protection matters on Kali because many security tools depend on shared Python packages. Mixing APT-managed and system-level pip packages can produce dependency drift where APT believes one version is installed while Python actually imports another.

Think of the unsafe model as:

Kali / APT
   │
   ├── python3
   ├── requests
   ├── urllib3
   ├── cryptography
   ├── Tool A
   ├── Tool B
   └── Tool C
          ▲
          │
     sudo pip install ...
          │
     may replace shared
     Python dependencies
Enter fullscreen mode Exit fullscreen mode

The safer model is:

Kali system Python
│
├── APT-managed dependencies
└── Kali tools

Separate pipx environment
│
├── Shodan
├── Shodan dependencies
└── isolated from Kali's system packages
Enter fullscreen mode Exit fullscreen mode

Preferred installation path: Kali package

Kali tracks the python-shodan source package and provides the python3-shodan binary package.

Install it with:

sudo apt update
sudo apt install -y python3-shodan
Enter fullscreen mode Exit fullscreen mode

Validate both the CLI and Python library:

command -v shodan
shodan --help
python3 -c "import shodan; print(shodan.__file__)"
Enter fullscreen mode Exit fullscreen mode

A successful installation should give you:

  • a resolvable shodan command;
  • Shodan CLI help output;
  • a Python import path without an exception.

Alternative: install the application with pipx

If your Kali image does not provide the CLI as expected, or you need a separately managed upstream application environment, use pipx instead of sudo pip:

sudo apt update
sudo apt install -y pipx
pipx ensurepath
pipx install shodan
Enter fullscreen mode Exit fullscreen mode

Depending on your shell, start a new shell session after pipx ensurepath.

Then validate:

command -v shodan
shodan --help
pipx list
Enter fullscreen mode Exit fullscreen mode

What not to use as the normal Kali installation path

Avoid making this your standard installation procedure:

sudo pip install shodan --break-system-packages
Enter fullscreen mode Exit fullscreen mode

The flag bypasses the externally-managed protection and accepts the risk of modifying the system Python environment.

Also do not delete Kali's EXTERNALLY-MANAGED marker to make pip behave like an older distribution.

For project-specific Python development, use a virtual environment instead:

sudo apt install -y python3-venv
python3 -m venv ~/venvs/shodan-lab
source ~/venvs/shodan-lab/bin/activate
python -m pip install --upgrade pip
python -m pip install shodan
Enter fullscreen mode Exit fullscreen mode

The practical rule is:

Requirement Recommended Kali approach
Kali-packaged application/library APT
Standalone Python application not installed through APT pipx
Python dependencies for your own project venv
Modify Kali system Python with sudo pip Avoid

Configure the Shodan CLI safely

The Shodan CLI requires an API key for API-backed operations.

Avoid hard-coding API keys into scripts, Git repositories, container images, or shell history.

For an analyst workstation, a temporary environment variable is one simple option:

read -rsp "Shodan API key: " SHODAN_API_KEY
echo
export SHODAN_API_KEY
shodan init "$SHODAN_API_KEY"
unset SHODAN_API_KEY
Enter fullscreen mode Exit fullscreen mode

Then verify the account context:

shodan info
Enter fullscreen mode Exit fullscreen mode

The features, monitoring capacity, query credits, scan credits, and API access available to you depend on the Shodan account/subscription in use.

For enterprise automation, use your normal secret-management platform rather than workstation environment variables—for example AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Vault, or a Kubernetes external-secrets workflow.

What Shodan actually collects

Shodan's fundamental unit of searchable data is a service banner.

A banner may contain information such as:

  • IP address;
  • service port;
  • transport protocol;
  • service/product metadata;
  • service version where available;
  • hostname information;
  • autonomous system / network ownership context;
  • TLS/certificate metadata;
  • collection timestamp;
  • protocol-specific data;
  • vulnerability metadata where Shodan has associated it with the observation.

A host lookup returns information Shodan has collected about services associated with that IP.

That data is valuable, but the collection timestamp matters.

For example:

Observed by Shodan:
  IP:          203.0.113.25
  Port:        22/tcp
  Product:     OpenSSH
  Last seen:   earlier collection cycle

Cloud inventory:
  Asset:       production-origin-01
  Expected:    443/tcp only
Enter fullscreen mode Exit fullscreen mode

The correct conclusion is:

Investigate possible exposure drift.

The incorrect conclusion is:

Production is definitely exposing SSH right now.

You need a current authoritative or approved validation source before making that claim.

Core Shodan CLI capabilities

Useful CLI operations include:

shodan host <IP>
shodan search '<query>'
shodan count '<query>'
shodan stats '<query>'
shodan download <filename> '<query>'
shodan parse <file.json.gz>
shodan alert list
shodan alert stats port vuln.verified vuln
Enter fullscreen mode Exit fullscreen mode

The search command is useful for validating a query and returning a limited result set.

For larger datasets, Shodan documents download as the appropriate path because it pages through search results and stores them in compressed JSON for later parsing.

Syntax-only host lookup using documentation address space

The following uses an RFC 5737 documentation IP. Do not expect it to return a real Internet host:

shodan host 203.0.113.10
Enter fullscreen mode Exit fullscreen mode

For a real engagement, replace the IP only with an address that is in the approved assessment scope.

Search an approved domain

A conceptual owned-domain query is:

shodan search 'hostname:example.com'
Enter fullscreen mode Exit fullscreen mode

For automation, avoid letting an LLM invent arbitrary query filters. Build the approved target boundary into the tool wrapper or query builder.

How to interpret Shodan output like an analyst

A common weakness in Shodan tutorials is showing commands without explaining the resulting evidence.

A simplified, representative host object might conceptually contain:

{
  "ip_str": "203.0.113.25",
  "org": "Example Hosting",
  "hostnames": ["api.example.com"],
  "ports": [22, 443],
  "last_update": "2026-08-12T04:15:00",
  "data": [
    {
      "port": 22,
      "transport": "tcp",
      "product": "OpenSSH",
      "version": "example-version",
      "timestamp": "2026-08-12T04:12:00"
    },
    {
      "port": 443,
      "transport": "tcp",
      "product": "nginx",
      "timestamp": "2026-08-12T04:15:00"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

This is a representative teaching example, not a live Shodan response.

A blue-team interpretation might be:

443/tcp
  Expected externally
  → baseline compliant

22/tcp
  Not present in approved exposure policy
  → exposure-drift candidate

Collection timestamp
  Not real-time
  → require current validation

Product/version
  Useful prioritization context
  → not proof of vulnerability
Enter fullscreen mode Exit fullscreen mode

A red-team interpretation of the same evidence might be:

22/tcp
  Candidate management interface
  → verify asset ownership
  → confirm engagement scope
  → prioritize for approved validation

443/tcp
  Expected public application surface
  → correlate hostname, certificate and application scope
Enter fullscreen mode Exit fullscreen mode

The two teams use the same evidence for different operational questions.

Blue-team operations

1. External attack-surface drift

This is one of the strongest blue-team Shodan use cases.

Start with authoritative intent:

Expected Internet exposure
--------------------------
api.example.com       443/tcp
portal.example.com    443/tcp
vpn.example.com       approved VPN port
Enter fullscreen mode Exit fullscreen mode

Then compare it with external observations:

Observed externally
-------------------
api.example.com       443/tcp
portal.example.com    443/tcp
origin-01             22/tcp, 443/tcp
Enter fullscreen mode Exit fullscreen mode

The new 22/tcp observation becomes an investigation.

It is not automatically an incident because you still need to establish:

  1. Is the IP actually ours?
  2. Is the observation fresh?
  3. Was SSH intentionally exposed under an exception?
  4. Is access restricted upstream even though the service is visible?
  5. Is the asset behind a CDN/WAF but the origin reachable directly?

Monitoring owned networks

For address space you own:

shodan alert create "Owned Production Range" 203.0.113.0/24
shodan alert list
Enter fullscreen mode Exit fullscreen mode

Use the returned alert ID to enable a change-oriented trigger:

shodan alert enable "$ALERT_ID" new_service
Enter fullscreen mode Exit fullscreen mode

Shodan documents new_service as a trigger for a newly observed service/port on monitored infrastructure.

For dynamic cloud-backed services, domain monitoring may be more practical:

shodan alert domain example.com
Enter fullscreen mode Exit fullscreen mode

Domain-based monitoring can track the IPs associated with the specified domain/hostname as DNS changes.

Treat monitor creation/modification as a control-plane mutation in an AI harness. It is not the same as scanning the target, but an AI agent should still not alter monitoring configuration without policy approval.

2. Validate cloud and network changes from the outside

After a change to:

  • AWS ALB/NLB exposure;
  • AWS Security Groups;
  • Azure NSGs;
  • GCP firewall policy;
  • Cloudflare proxy/origin architecture;
  • Kubernetes ingress;
  • public load balancers;
  • firewall/NAT policy;

Shodan can provide an external observation layer.

The workflow should look like:

Infrastructure change
        ↓
Authoritative config validation
        ↓
Immediate direct validation if approved
        ↓
Shodan observation on a later collection cycle
        ↓
Compare expected vs observed
Enter fullscreen mode Exit fullscreen mode

Do not use Shodan as the sole immediate post-change control because its dataset is asynchronous.

3. Cloudflare origin-exposure validation

A useful production pattern is comparing Cloudflare and cloud inventory with Shodan.

Example expected state:

Internet
   │
   ▼
Cloudflare
   │
   ▼
AWS ALB
   │
   ▼
Application

Origin direct access: NOT expected
Public service:        443 through Cloudflare
Administrative ports: NOT Internet exposed
Enter fullscreen mode Exit fullscreen mode

Now imagine the evidence normalizer produces:

{
  "asset": "api.example.com",
  "origin_ip": "203.0.113.25",
  "cloudflare_proxied": true,
  "expected_public_ports": [443],
  "shodan_observed_ports": [22, 443],
  "direct_origin_access_expected": false,
  "shodan_last_update": "2026-08-12T04:15:00"
}
Enter fullscreen mode Exit fullscreen mode

A deterministic rule can generate:

Classification:
EXTERNAL_EXPOSURE_DRIFT_CANDIDATE

Reason:
Observed port 22 is not present in expected-public-port policy.

Required validation:
- confirm current origin ownership;
- verify security-group/firewall policy;
- verify whether the origin can be reached directly;
- check Cloudflare/origin ACL enforcement;
- validate timestamp/freshness.
Enter fullscreen mode Exit fullscreen mode

This is a far better use of AI than asking:

"Is this IP vulnerable?"

4. Vulnerability triage

Shodan vulnerability metadata can help prioritize investigation.

The safe interpretation is:

Internet-visible service
        +
Shodan vulnerability association
        +
asset criticality
        +
freshness
        ↓
validation priority
Enter fullscreen mode Exit fullscreen mode

Not:

Shodan says CVE
        ↓
confirmed vulnerability
Enter fullscreen mode Exit fullscreen mode

Shodan documents vuln.verified separately from broader vulnerability associations.

For monitored networks, useful statistics include:

shodan alert stats port vuln.verified vuln
Enter fullscreen mode Exit fullscreen mode

A finding should then be validated using appropriate evidence such as:

  • authenticated vulnerability scanning;
  • package/SBOM inventory;
  • cloud image inventory;
  • endpoint telemetry;
  • vendor version mapping;
  • an approved manual check.

5. SIEM and detection enrichment

A practical architecture is:

Shodan Monitor
      │
      ▼
Webhook / stream consumer
      │
      ▼
Normalizer
      │
      ├── asset ownership lookup
      ├── expected exposure lookup
      ├── CMDB / cloud tags
      └── vulnerability context
      │
      ▼
SIEM / Security Lake
      │
      ▼
AI-assisted triage
      │
      ▼
Deterministic ticket/alert policy
Enter fullscreen mode Exit fullscreen mode

Important design rule:

Do not let the LLM decide whether an IP belongs to your organization.

Ownership should come from an authoritative inventory source or a deterministic allowlist.

Red-team operations

Use Shodan before sending unnecessary packets

For an authorized red-team engagement, Shodan is useful during the passive-reconnaissance phase.

A disciplined workflow looks like:

Rules of Engagement
        ↓
Approved domains / CIDRs
        ↓
Scope validator
        ↓
Passive Shodan enrichment
        ↓
Certificate / hostname correlation
        ↓
Service clustering
        ↓
Asset ownership confirmation
        ↓
Candidate attack surface
        ↓
Human review
        ↓
Authorized active validation
Enter fullscreen mode Exit fullscreen mode

The purpose is to reduce unnecessary scanning and improve target prioritization, not to create an indiscriminate Internet target list.

Example

Rules of engagement:

Approved domain:
example.com

Approved CIDR:
203.0.113.0/24

Objective:
Identify unexpected externally visible administrative services.
Enter fullscreen mode Exit fullscreen mode

Pre-collected Shodan evidence:

203.0.113.25
  443/tcp   expected web service
  22/tcp    unexpected management candidate

203.0.113.40
  443/tcp   expected web service
  8443/tcp  administrative-interface candidate
Enter fullscreen mode Exit fullscreen mode

The red-team conclusion should be:

Candidate 1:
203.0.113.25:22
Reason: unexpected management service

Candidate 2:
203.0.113.40:8443
Reason: non-baseline web management port

Next action:
Human confirms ownership and scope before any active validation.
Enter fullscreen mode Exit fullscreen mode

An AI red agent may rank these existing observations.

It should not:

  • add unrelated organizations;
  • expand the CIDR;
  • submit arbitrary Internet-wide searches;
  • launch active scans autonomously;
  • convert a banner into an exploitation decision.

When to use Shodan — and when not to

Scenario Use Shodan? Operational reason
External exposure baseline Yes Provides a third-party view of Internet-visible services.
Unexpected public-service drift Yes Monitor/change detection is directly aligned.
Passive authorized red-team reconnaissance Yes Reduces unnecessary active probing.
Cloudflare origin-exposure investigation Yes Useful external observation source when correlated with authoritative config.
Prove a CVE is exploitable No, not alone Banner/version association is not exploitation proof.
Internal-only asset discovery Usually no Shodan primarily observes Internet-facing services.
Immediate post-change confirmation With caution Shodan data is asynchronous and may be stale.
Asset ownership determination No, not alone Hosting/CDN/cloud attribution can be ambiguous.
Emergency real-time port verification No, not alone Use an authorized real-time validation source.

Working with larger datasets

The Shodan CLI documents search as useful for quickly checking a query.

For larger result sets, use download:

shodan download owned-web 'hostname:example.com'
Enter fullscreen mode Exit fullscreen mode

This produces a compressed Shodan data file.

Extract selected fields:

shodan parse --fields ip_str,port,product owned-web.json.gz
Enter fullscreen mode Exit fullscreen mode

Example CSV-style extraction:

shodan parse \
  --fields ip_str,port,product \
  --separator , \
  owned-web.json.gz
Enter fullscreen mode Exit fullscreen mode

This is useful for a controlled pipeline because you can retain the raw evidence file separately while giving the AI model only a minimized, normalized subset.

AI-assisted Red and Blue operations

The strongest AI pattern is:

LLM for evidence reasoning; deterministic controls for authorization and execution.

Do not build:

LLM
 ↓
shell
 ↓
shodan <model-generated command>
Enter fullscreen mode Exit fullscreen mode

Build:

LLM
 ↓
typed tool request
 ↓
authorization policy
 ↓
scope validator
 ↓
Shodan adapter
 ↓
normalized evidence
 ↓
LLM analysis
 ↓
schema validation
 ↓
deterministic action policy
Enter fullscreen mode Exit fullscreen mode

Shodan AI workflow

Blue AI workflow 

1. Receive Shodan Monitor event
2. Resolve asset ownership deterministically
3. Look up expected exposure policy
4. Normalize Shodan evidence
5. Remove unnecessary raw banner content/secrets
6. Ask model to classify the discrepancy
7. Validate model output against a schema
8. Apply deterministic severity/ticket policy
9. Preserve evidence provenance and audit log
Enter fullscreen mode Exit fullscreen mode

Example minimized model input:

{
  "asset_id": "prod-api-origin-01",
  "owner": "payments-platform",
  "environment": "production",
  "expected_public_ports": [443],
  "observed": {
    "ip": "203.0.113.25",
    "ports": [22, 443],
    "last_update": "2026-08-12T04:15:00"
  },
  "controls": {
    "cloudflare_proxied": true,
    "direct_origin_access_expected": false
  }
}
Enter fullscreen mode Exit fullscreen mode

A useful model output contract is:

{
  "classification": "external_exposure_drift_candidate",
  "risk_rationale": [
    "Port 22 is not in the expected public-service baseline",
    "Direct origin exposure is not expected for this asset"
  ],
  "required_validation": [
    "Confirm current IP ownership",
    "Check current firewall/security-group state",
    "Verify whether direct origin connectivity is possible"
  ],
  "recommended_owner": "payments-platform"
}
Enter fullscreen mode Exit fullscreen mode

Notice what the model is not allowed to decide:

  • whether it may scan the host;
  • whether the host is in scope;
  • whether to disable a firewall;
  • whether to change Cloudflare;
  • whether to exploit the service.

Those are policy decisions.

Red AI workflow

A controlled red AI can operate over evidence already collected from approved targets.

Example task:

Objective:
Prioritize externally visible administrative services within the approved engagement scope.

Allowed evidence:
- Shodan observations
- approved asset inventory
- engagement scope
- certificate/hostname metadata

Forbidden:
- expanding scope
- launching scans
- generating shell commands for arbitrary execution
- autonomous exploitation
Enter fullscreen mode Exit fullscreen mode

The model can produce:

{
  "priority_candidates": [
    {
      "asset": "203.0.113.40",
      "port": 8443,
      "reason": "Non-baseline HTTPS service that may represent an administrative interface"
    },
    {
      "asset": "203.0.113.25",
      "port": 22,
      "reason": "Unexpected SSH exposure relative to the engagement baseline"
    }
  ],
  "next_step": "Human scope validation before active testing"
}
Enter fullscreen mode Exit fullscreen mode

This makes AI useful without turning it into the authorization system.

The harness configuration is NOT Shodan syntax

The following YAML is an example policy contract for a custom AI security harness.

It is not a Shodan configuration file and the operation names such as host_lookup are wrapper functions defined by your harness.

engagement:
  authorization_ref: "RT-2026-042"
  allow_targets:
    - "example.com"
    - "203.0.113.0/24"

tool:
  name: shodan
  adapter: typed_python_wrapper
  default_mode: passive_query

  allowed_operations:
    - host_lookup
    - scoped_search
    - monitor_read
    - parse_saved_data

  approval_required:
    - monitor_create
    - monitor_modify
    - on_demand_scan

  forbidden:
    - arbitrary_shell
    - unscoped_search
    - model_defined_target_expansion

model:
  provider: openai
  name: gpt-5.6-terra
  structured_output: true

privacy:
  send_api_key_to_model: false
  send_full_raw_banner_by_default: false
  minimize_evidence_before_model: true

audit:
  record_tool_version: true
  hash_raw_evidence: true
  record_scope_decision: true
  log_tool_arguments: true
  log_approvals: true
  log_final_action: true
Enter fullscreen mode Exit fullscreen mode

The most important architectural choice is:

typed function
    instead of
arbitrary command string
Enter fullscreen mode Exit fullscreen mode

Minimal typed Shodan adapter

The following example demonstrates the control pattern.

It intentionally exposes only a read-oriented host_lookup() operation and checks the IP against approved CIDRs before calling Shodan.

import ipaddress
import os
from typing import Any

import shodan


APPROVED_NETWORKS = [
    ipaddress.ip_network("203.0.113.0/24"),
]


def is_approved_ip(value: str) -> bool:
    ip = ipaddress.ip_address(value)
    return any(ip in network for network in APPROVED_NETWORKS)


class ScopeViolation(RuntimeError):
    pass


class ShodanAdapter:
    def __init__(self) -> None:
        api_key = os.environ["SHODAN_API_KEY"]
        self.api = shodan.Shodan(api_key)

    def host_lookup(self, ip: str) -> dict[str, Any]:
        if not is_approved_ip(ip):
            raise ScopeViolation(f"Target outside approved scope: {ip}")

        result = self.api.host(ip)

        services = []
        for banner in result.get("data", []):
            services.append(
                {
                    "port": banner.get("port"),
                    "transport": banner.get("transport"),
                    "product": banner.get("product"),
                    "version": banner.get("version"),
                    "timestamp": banner.get("timestamp"),
                    "vulns": banner.get("vulns"),
                }
            )

        return {
            "ip": result.get("ip_str"),
            "hostnames": result.get("hostnames", []),
            "org": result.get("org"),
            "ports": result.get("ports", []),
            "last_update": result.get("last_update"),
            "services": services,
        }
Enter fullscreen mode Exit fullscreen mode

Why this is safer than shell access:

Model request
   │
   ▼
host_lookup("203.0.113.25")
   │
   ├── parse IP
   ├── enforce approved CIDR
   ├── perform one defined API operation
   ├── minimize returned evidence
   └── log the transaction
Enter fullscreen mode Exit fullscreen mode

A banner containing malicious or prompt-injection text cannot turn itself into:

rm -rf ...
Enter fullscreen mode Exit fullscreen mode

because the model never receives a generic shell tool.

MCP integration

MCP can be useful for exposing the typed Shodan adapter to an AI host, but MCP is not the authorization boundary.

A good pattern is:

AI model / agent
      │
      ▼
MCP host
      │
      ▼
Shodan MCP server / adapter
      │
      ▼
Authorization + scope policy
      │
      ▼
Shodan API
Enter fullscreen mode Exit fullscreen mode

Expose narrow tools such as:

shodan_host_lookup(ip)
shodan_scoped_search(query_id, parameters)
shodan_monitor_read(alert_id)
Enter fullscreen mode Exit fullscreen mode

Avoid exposing:

run_shell(command)
execute_shodan_cli(raw_string)
scan_any_target(target)
Enter fullscreen mode Exit fullscreen mode

The policy service should evaluate every request before the adapter executes it.

For high-impact operations, the flow should be:

Model proposes action
       ↓
Policy classifies as approval-required
       ↓
Human approval
       ↓
Adapter executes defined operation
       ↓
Evidence and approval are logged
Enter fullscreen mode Exit fullscreen mode

Kubernetes deployment: when it actually helps

You do not need Kubernetes merely to use Shodan.

A single analyst workstation or hardened automation VM may be simpler.

Kubernetes becomes useful when the AI-security workflow is already operating as a service with components such as:

Kubernetes
│
├── shodan-adapter
├── AI orchestrator
├── policy service
├── evidence normalizer
├── work queue
└── audit exporter
Enter fullscreen mode Exit fullscreen mode

This gives you independent identities, scaling boundaries, logging, network policy, deployment controls, and secret integration.

Example pod hardening 

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL
Enter fullscreen mode Exit fullscreen mode

Also consider:

  • dedicated Kubernetes ServiceAccount;
  • no unnecessary Kubernetes API permissions;
  • automountServiceAccountToken: false where the workload does not need the Kubernetes API;
  • secret injection from an external secret manager;
  • read-only root filesystem;
  • resource limits;
  • admission policy;
  • signed images;
  • runtime telemetry;
  • restricted egress.

Egress control nuance

A standard Kubernetes NetworkPolicy is IP/CIDR-oriented and should not be described as a universal FQDN allowlist.

A production design is often:

Shodan adapter pod
       │
       ▼
approved egress proxy / gateway
       │
       ├── destination policy
       ├── TLS policy
       ├── logging
       └── rate controls
       │
       ▼
Shodan API
Enter fullscreen mode Exit fullscreen mode

If your networking stack supports DNS/FQDN-aware egress policy, you may enforce the destination there. Otherwise, use an egress gateway/proxy rather than pretending a basic NetworkPolicy provides hostname-level authorization.

Model selection for AI Red/Blue operations

The security architecture should remain model-independent.

As of 13 August 2026, current examples include:

Workload Example model choice Reason
Deep correlation, ambiguous evidence, final analyst reasoning GPT-5.6 Sol or Claude Sonnet 5 Stronger reasoning for cross-source security analysis.
Routine constrained triage and structured classification GPT-5.6 Terra Balance of capability and cost for policy-bounded workflows.
High-volume low-complexity labeling/routing GPT-5.6 Luna Cost-sensitive repetitive processing.
Sensitive/offline evidence Locally approved tool-capable model through Ollama or equivalent Keep evidence within the approved environment.

For local models, verify the actual installed model and its capabilities:

ollama list
Enter fullscreen mode Exit fullscreen mode

Do not assume every local model supports tool calling, structured output, large contexts, or reliable instruction following.

More importantly:

Authorization
    >
scope enforcement
    >
tool design
    >
evidence quality
    >
output validation
    >
auditability
    >
model choice
Enter fullscreen mode Exit fullscreen mode

The model is replaceable.

Your security controls should not be.

Minimum production harness controls

A production-grade AI security harness should enforce these outside the LLM:

  • explicit authorization or engagement reference;
  • target allowlist and denylist;
  • scope validation before every tool invocation;
  • least-privilege tool identity;
  • short-lived or centrally managed credentials;
  • passive/read-only defaults;
  • explicit approval gates for mutating or active operations;
  • no arbitrary shell where typed tools can do the job;
  • secret and PII minimization before model submission;
  • structured model output validated against a schema;
  • evidence provenance;
  • tool/version recording;
  • raw-evidence hashing;
  • immutable or tamper-resistant audit logging;
  • model/tool timeout handling;
  • rate limits;
  • fail-closed behavior when scope or authorization is ambiguous.

For red-team use, also preserve:

engagement ID
operator
target
scope decision
evidence source
tool invocation
approval
timestamp
result hash
next action
Enter fullscreen mode Exit fullscreen mode

This gives the purple team something reproducible to review rather than an opaque "AI decided this was interesting."

What purple team should replay

The purpose of purple-team replay is not simply to repeat the same Shodan query.

The useful replay unit is the detection/control decision.

Example:

Initial observation:
Shodan sees 22/tcp on an origin IP.

Blue response:
Security Group updated.
Origin ACL corrected.
Cloudflare-only ingress control applied.

Purple replay:
1. Re-evaluate authoritative cloud policy.
2. Re-run approved current connectivity validation.
3. Observe a later Shodan collection cycle.
4. Confirm expected-vs-observed convergence.
5. Validate that future new-service events produce the intended alert.
Enter fullscreen mode Exit fullscreen mode

The replay therefore proves whether the approved control changed the security outcome.

Common failure modes

Treating Shodan as real-time truth

Shodan is an observation dataset, not a synchronous port scanner.

Always preserve the collection timestamp.

Treating CVE metadata as vulnerability proof

Use Shodan to prioritize validation, not replace it.

Letting AI determine scope

Scope must be supplied by authorization data and enforced before tool execution.

Sending full banners to a public model by default

Banners may contain organization-specific strings, hostnames, certificate data, headers, and other evidence you do not need for the reasoning task.

Minimize first.

Confusing a harness operation with a Shodan command

host_lookup, scoped_search, and monitor_read in the YAML above are custom adapter functions.

They are not Shodan CLI syntax.

Giving the model shell access

A model does not need:

bash(command)
Enter fullscreen mode Exit fullscreen mode

when the actual requirement is:

shodan_host_lookup(ip)
Enter fullscreen mode Exit fullscreen mode

Assuming an IP belongs to you

Cloud hosting, CDNs, shared infrastructure, reassignment, and stale DNS make this unsafe.

Resolve ownership authoritatively.

Treating monitor changes and active scans as ordinary read operations

Separate:

Read:
host lookup
search
parse stored evidence
read monitor state

Mutating:
create/modify/delete monitoring

Active:
on-demand target scan
Enter fullscreen mode Exit fullscreen mode

Apply different authorization policies to each class.

A practical end-to-end example

Situation

Your approved architecture says:

Public hostname:
api.example.com

Expected path:
Client → Cloudflare → AWS ALB → Kubernetes ingress

Expected Internet service:
443/tcp

Direct origin exposure:
Not permitted
Enter fullscreen mode Exit fullscreen mode

Shodan observation

Your external-intelligence pipeline finds:

{
  "origin_ip": "203.0.113.25",
  "ports": [22, 443],
  "last_update": "2026-08-12T04:15:00"
}
Enter fullscreen mode Exit fullscreen mode

Deterministic enrichment

AWS inventory says:

{
  "asset_id": "prod-api-origin-01",
  "account": "production",
  "owner": "platform",
  "expected_public_ports": [443],
  "direct_origin_access_expected": false
}
Enter fullscreen mode Exit fullscreen mode

Cloudflare inventory says:

{
  "hostname": "api.example.com",
  "proxied": true
}
Enter fullscreen mode Exit fullscreen mode

AI analysis

The model receives the minimized evidence and responds:

{
  "classification": "external_exposure_drift_candidate",
  "risk_rationale": [
    "SSH is not part of the approved Internet exposure baseline",
    "The architecture requires Cloudflare-mediated public access"
  ],
  "validation_steps": [
    "Confirm that 203.0.113.25 is the current production origin",
    "Review current AWS Security Group and NACL state",
    "Verify whether port 22 is reachable from an approved external validation point",
    "Verify origin restrictions for Cloudflare traffic"
  ]
}
Enter fullscreen mode Exit fullscreen mode

Blue-team action

Blue validates the current configuration and determines whether the observation is stale, intentional, or a real control failure.

Red-team action

If the engagement permits it, Red receives the validated candidate and performs only the approved next-step testing.

Purple-team action

Purple verifies that the remediation:

  • removed or constrained the exposure;
  • updated expected-state policy if the exposure was intentional;
  • created an alert for future recurrence;
  • produced auditable evidence.

That is a practical AI-assisted Shodan workflow.

Final takeaways

Shodan is most powerful when it is treated as an external source of evidence, not an oracle.

For Blue Team:

Shodan
  +
authoritative inventory
  +
expected exposure policy
  +
SIEM/context
  =
external attack-surface drift detection
Enter fullscreen mode Exit fullscreen mode

For Red Team:

approved scope
  +
Shodan passive intelligence
  +
ownership validation
  =
better-targeted authorized testing
Enter fullscreen mode Exit fullscreen mode

For AI-assisted operations:

LLM reasoning
  +
typed tools
  +
deterministic authorization
  +
scope enforcement
  +
audit trail
  =
controlled AI security operations
Enter fullscreen mode Exit fullscreen mode

The model should reason over evidence.

The harness should decide what is allowed.

The human and organizational authorization should decide what may be tested.

Top comments (0)