DEV Community: gaurav sharma

AI Threat Awareness Program

gaurav sharma — Tue, 15 Sep 2026 12:17:07 +0000

AI Threat Overview

Six threats make up the current taxonomy. Four are vectors, how exposure is created. Two are impacts, what it costs when a vector succeeds.

ID	Threat	Type	What it is
AI-01	Shadow AI	Vector	Unsanctioned LLMs and agents used outside governance
AI-02	Rogue Agent	Vector	A sanctioned agent given more autonomy than its task needs
AI-03	Prompt Injection	Vector	Hidden instructions override the model's intended behavior
AI-04	Model & Data Supply Chain	Vector	Unvetted models, training data, or plugins carrying hidden risk
AI-05	Data Exfiltration	Impact (from AI-01/02/03)	Sensitive data leaves company control
AI-06	Hallucination	Impact (from AI-04 & over-reliance)	Confident but false output acted on unverified

Technical Deep-Dive

Each threat below follows the same structure: what it is, how it typically plays out end to end, what to watch for, and what closes the gap.

AI-01 · Shadow AI

Employees use unsanctioned LLMs, agents, or local models outside IT and InfoSec governance. These tools inherit the user's personal-level access with no DLP coverage and no audit trail.

Exploit chain

An employee uses a personal AI account for a work task.
The vendor's consumer terms of service apply, not a corporate agreement.
Prompts and data are logged or used for training outside company control.
The data is later exposed through a vendor breach or reproduced in model output.

Indicators
• Outbound traffic to AI service domains from non-corporate accounts
• DLP alerts flagging AI-related data egress
• Unapproved browser extensions or local model runners on endpoints

Remediation
• Stand up a formal AI intake and sanctioning process
• Block or allowlist AI domains at the proxy
• Provide a sanctioned enterprise AI alternative
• Apply DLP monitoring with no exemptions, sanctioned tools included

AI-02 · Rogue Agent

A sanctioned AI agent is granted more tools, data access, or autonomy than its task requires, and acts on faulty output without a human check.

Exploit chain

An agent is provisioned with broad API or database credentials.
A bad input, hallucination, or injected instruction triggers an unplanned tool call.
No human approval gate exists for that action.
The action executes, and is only logged, if at all, after the fact.

Indicators
• The agent invokes tools or APIs outside its expected scope
• An irreversible action is taken with no approval step
• A service account holds write or delete access where read-only would do

Remediation
• Grant least-privilege, per-user scoped credentials, not shared high-privilege accounts
• Require human approval before high-impact or irreversible actions
• Enforce authorization on the backend system, never trust the model's own judgment
• Log all agent activity and rate-limit sensitive operations

AI-03 · Prompt Injection

Instructions hidden in user input, or in content the model reads, such as a document, email, or web page, override the system's intended instructions.
Exploit chain

An attacker embeds a hidden instruction inside external content.
An agent ingests that content as part of a routine task.
The model follows the injected instruction instead of the user's intent.
The result is a data leak or an unauthorized action.

Indicators
• Output tone or content shifts unexpectedly mid-task
• The agent references instructions the user never gave it
• An unusual tool call follows immediately after reading external content
Remediation
• Treat all ingested or retrieved content as untrusted data, never as instructions
• Apply runtime guardrails to every agent, with no exceptions for trusted-looking sources
• Keep the system prompt's privilege segregated from user- and content-supplied text
• Red-team live prompts and agents on a recurring schedule

AI-04 · Model & Data Supply Chain

Pretrained models, fine-tuning datasets, or plugins sourced from unvetted third parties can carry backdoors, poisoned data, or undisclosed license and IP exposure.

Exploit chain

A team pulls a model or dataset from a public source without vetting it.
A backdoor or biased pattern is embedded during training and goes unnoticed.
The model is deployed into production.
A specific trigger input later activates the malicious or skewed behavior at scale. Indicators • No documented provenance for a model currently in use • No entry for the model in an AI or model inventory • Behavior drift after what the vendor called a minor update Remediation • Maintain a signed model and AI inventory (an AI bill of materials) • Vet provenance and attestation before adopting any model or dataset • Red-team new models before deployment • Secure contractual audit rights with model and data vendors

AI-05 · Data Exfiltration

Regulated or sensitive data leaves the organization's control through a prompt, an agent's tool call, or a vendor's retention or training policy. This is a common outcome of Shadow AI, Prompt Injection, and Rogue Agent behavior.

Exploit chain

Sensitive data enters a prompt or an agent's working context.
No content-level DLP inspects that data before it leaves.
The data reaches an external model or an over-permissioned tool.
It is retained, logged, or acted upon outside company control.

Indicators
• Sensitive terms surfacing in prompt or agent logs
• A vendor without a zero-retention or no-training clause
• Regulated data, PII, PHI, or source code, seen on an unmonitored AI channel
Remediation
• Apply content-aware DLP to every AI channel, sanctioned or not
• Tie data classification directly to what may enter a prompt
• Require zero-retention terms in every AI vendor contract
• Redact or tokenize sensitive fields before submission where feasible

AI-06 · Hallucination

The model produces confident but false or fabricated output, such as a citation, a figure, or a policy clause, and someone acts on it without verifying it. This is most common where training data quality is poor or where staff over-rely on AI output.

Exploit chain

The model generates a plausible-sounding but incorrect answer.
The output carries no indication of uncertainty.
A user or downstream system trusts it without verification.
A decision, filing, or communication is made based on false information.

Indicators
• Unverifiable citations, figures, or policy clauses
• Output that contradicts known source documents
• No human review step before the content is used externally
Remediation
• Require human review for any external or high-stakes output
• Require sourced, grounded answers over freeform generation where accuracy matters
• Train staff on automation bias and the habit of verifying before acting

Building a Continuous Threat Exposure Management (CTEM) Program — Open Source, Cloud-Agnostic, and Zero Hidden Cost

gaurav sharma — Wed, 02 Sep 2026 07:27:10 +0000

What the CTEM program does

Most security teams find out they're exposed the same way an attacker does — by scanning. The
difference is who gets there first. This CTEM program flips that timeline: instead of waiting for
a pentest, a bug bounty report, or an incident to reveal what's exposed, it runs the same
reconnaissance an attacker would run — continuously, against your own footprint — and turns the
output into tracked, owned remediation work before it becomes an incident.

The pipeline mirrors an actual attack chain, stage by stage:

Discover what exists (OSINT, subdomains, assets you may not even know are yours)
Confirm what's alive and what it's running
Assess what's vulnerable or misconfigured
Correlate exposure back to identity — because a vulnerable host is a problem, but a vulnerable host with a path to Domain Admin or a cloud admin role is an incident waiting to happen

Why cloud-agnostic and ephemeral matters (and why "hidden cost" is the real enemy)

Every major cloud provider now ships a native posture-management or "well-architected" tool —
and on paper, that's convenient. In practice, a lot of these tools quietly meter you into
consumption-based pricing for the AI/analysis layer underneath. AWS's Well-Architected Tool
review itself is free, but plug it into Bedrock-backed recommendations or continuous AI-assisted
analysis, and the bill scales with usage in a way that's hard to forecast and easy to lose track
of — a classic hidden-cost trap for a program that's supposed to be about reducing risk, not
opening a new unpredictable line item.

This toolchain takes the opposite approach on purpose:

Cloud-agnostic — none of these tools care whether your footprint is AWS, Azure, GCP, or on-prem. The same pipeline that maps your Azure attack paths (AzureHound) maps AWS ones (AWSHound) with the same BloodHound backend. You're not locked into a single vendor's visibility model.
Ephemeral by design — every tool here is a CLI binary or a short-lived container. Spin it up, run the scan, tear it down. No standing infrastructure, no idle compute burning budget between scan windows, no persistent SaaS subscription cost creeping upward as your asset count grows.
Open source, self-hosted — the cost is your compute time, not a per-asset or per-scan metered fee. A weekly CTEM run against a mid-size external footprint costs you a few dollars of transient VM time, full stop — no surprise invoice at the end of the month.

Tools in the pipeline

Tool	Category	Function
theHarvester	OSINT / Digital Footprint	Passive discovery of hosts, emails, and exposure tied to the domain
Amass / Subfinder	Attack Surface Management	Enumerate every subdomain forming the external asset inventory
Naabu	Attack Surface Management	Identify open ports on discovered hosts
httpx	Attack Surface Management	Confirm which hosts are live and fingerprint the tech running
Nuclei	Vulnerability Assessment	Detect known CVEs, misconfigurations, and exposed cloud resources via community + custom templates
TruffleHog	Secret / Credential Exposure	Find live API keys and credentials leaked in code repositories
ScoutSuite	Cloud Security Posture (CSPM)	Audit cloud account configuration against security best practice
BloodHound + AzureHound / AWSHound	Identity & Attack Path Analysis	Map privilege-escalation and lateral-movement paths across cloud identity graphs

A word of caution before you run any of this: verify what you trust

In March 2026, Aqua Security's Trivy — one of the most widely used open-source scanners in the cloud-native ecosystem — was itself compromised. A threat actor tracked as TeamPCP force-pushed malicious tags across the trivy, trivy-action, and setup-trivy GitHub repos and published tampered Docker Hub images, turning a trusted security tool into a credential-harvesting weapon inside thousands of CI/CD pipelines. It's a sharp reminder that a CTEM pipeline built entirely on open-source tooling is only as trustworthy as your verification discipline. Ten lessons worth carrying into how you run this stack:

A "security vendor" label is not a trust guarantee — even scanners get compromised
Version tags (@v1, @latest) are mutable and can be force-pushed by anyone with write access
Pin every GitHub Action and container image to an immutable full commit SHA or digest, never a tag
Credential rotation must be atomic — revoke first, then reissue; a staggered rotation window is an open door
Avoid pull_request_target in any workflow that touches forked PR code — it runs with base-repo secrets against untrusted input
Any CI/CD runner that executed a since-compromised action should have every exposed secret treated as burned, not just rotated
Don't trust an artifact because the filename or registry looks official — verify cryptographically, every time
Use short-lived OIDC tokens for cloud access instead of long-lived static credentials in CI/CD
Watch for anomalous tag movement or force-pushes on the dependencies you consume — it's a detectable signal, not just hindsight
Build a culture where your own tooling gets the same scrutiny you'd apply to a stranger's code — trust is earned per-run, not once
Verify before you run: cosign + SLSA provenance

Before any of the binaries or container images in this pipeline touch your infrastructure, verify both the signature and the build provenance:

# Verify the image was signed by the expected publisher via Sigstore/cosign keyless signing
cosign verify --certificate-identity-regexp "https://github.com/<org>/<repo>" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/<org>/<tool>:<version>

# Verify SLSA provenance attestation matches this exact artifact, not just any release
slsa-verifier verify-image ghcr.io/<org>/<tool>:<version> \
  --source-uri github.com/<org>/<repo> --source-tag v<version>

If either check fails, stop — don't run it "just this once." That two-command habit, run before every tool in this pipeline gets pulled, is the actual signature of a security engineer who double-checks everything rather than trusting the label on the box.

Deployment steps

Clone the repo

   git clone <your-repo-link-here>
   cd ctem-pipeline

(Repo link to be added — this is a placeholder for your actual GitHub URL.)

Install prerequisites
- Go 1.21+ (Amass, Subfinder, Naabu, httpx, Nuclei are Go-based)
- Python 3.10+ (theHarvester, TruffleHog wrapper scripts, ScoutSuite)
- Neo4j (for BloodHound's graph backend)
Set up the Python virtual environment (see caveat below before you skip this step)

   python3 -m venv ctem-venv
   source ctem-venv/bin/activate      # Windows: ctem-venv\Scripts\activate
   pip install -r requirements.txt

Install the Go-based tools

   go install -v github.com/owasp-amass/amass/v4/...@master
   go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
   go install -v github.com/projectdiscovery/naabu/v2/cmd/naabu@latest
   go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest
   go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

Run the pipeline (order matters — each stage feeds the next)

   ./run_ctem.sh -d yourdomain.com

This chains: theHarvester → Amass/Subfinder → Naabu → httpx → Nuclei, writing results into
a /results directory as structured JSON for downstream ingestion into your SIEM or a
watchlist/dashboard.

Run cloud posture and identity modules separately (these need cloud credentials scoped read-only, not the external-recon flow above)

   scout aws --profile readonly-audit
   azurehound list --tenant <tenant-id> -o azurehound-output.json

Import outputs into your BloodHound Neo4j instance to visualize attack paths.

Schedule it. A one-off scan tells you today's exposure. A scheduled scan (weekly cron or CI/CD pipeline trigger) is what makes it continuous — that's the difference between CTEM and a one-time pentest.

Important caveat: the Python virtual environment isn't optional

If you run pip install against your system Python directly, you will very likely hit dependency
conflicts — theHarvester, ScoutSuite, and TruffleHog's Python wrapper each pin different versions
of shared libraries (requests, boto3, PyYAML are common collision points). The symptom is
usually a cryptic ImportError or version-resolution failure that looks like it's about one tool,
but is actually a transitive dependency clash between two unrelated tools.

Fix: always use an isolated venv per the steps above, and if you still hit an error:

pip install --upgrade pip setuptools wheel
pip install -r requirements.txt --no-cache-dir

If a specific tool's install still fails, isolate it into its own venv rather than fighting
version pins in a shared environment — it costs a few extra seconds of setup and saves hours of
dependency debugging.

This pipeline is designed to be run by anyone with basic CLI familiarity — no dedicated
infrastructure, no recurring SaaS bill, and no cloud-vendor lock-in. The goal isn't a fancy
dashboard; it's finding what an attacker would find, before they do.